Un agentic workflow è un sistema in cui un modello di linguaggio decide una parte di quello che succede dopo, invece di seguire un percorso che hai scritto in anticipo. Quasi tutti quelli che costruirai sono un assemblaggio di sette pattern con un nome: prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, l'autonomous tool loop e l'human-in-the-loop checkpoint. Anthropic, LangGraph e il Google Agent Development Kit documentano le stesse forme quasi con gli stessi nomi, quindi è vocabolario condiviso e non una tassonomia inventata da noi. È anche vocabolario caro: Anthropic riporta che gli agent usano circa 4x i token di un'interazione di chat e i sistemi multi-agent circa 15x. Ogni pattern qui sotto riceve un esempio, una regola esplicita per evitarlo e il guasto che lo colpisce per primo.
Parte di: Cos'e l'agentic engineering? La guida pilastro 2026
Come abbiamo scelto questi sette pattern
Non esiste una lista canonica degli agentic design pattern, quindi la cosa onesta è dire da dove viene la nostra. Abbiamo tenuto solo i pattern che compaiono con un nome stabile in più di una fonte primaria. Il post di engineering di Anthropic, Building Effective AI Agents, fornisce cinque workflow pattern più l'agent autonomo. La documentazione di LangGraph usa gli stessi cinque nomi per le stesse forme. Il Google Agent Development Kit ne rilascia tre come tipi di agent di prima classe. I quattro pattern molto citati di Andrew Ng si sovrappongono a tutto questo con etichette diverse, quindi dove un pattern ha due nomi comuni li diamo entrambi, perché la gente cerca entrambi. Il settimo, il checkpoint umano, è qui perché l'OpenAI Agents SDK e LangGraph lo rilasciano entrambi come primitiva documentata invece che come consiglio.
- Nominato in una fonte primaria: compare con quel nome negli scritti di engineering di un vendor o nella documentazione di un framework, non solo in una raccolta.
- Nominato due volte: se i praticanti lo chiamano in due modi, elenchiamo entrambi i nomi, perché entrambi finiscono digitati in una barra di ricerca.
- Costruibile oggi: esiste un'implementazione funzionante in un framework rilasciato, quindi puoi usare il pattern invece di ammirarlo.
- Ha un failure mode reale: possiamo dire cosa si rompe per primo, e questo è un test più duro di un pattern che dire in cosa è bravo.
- Ha una regola per evitarlo: esiste un caso concreto in cui una funzione semplice, una coda o un cron job fanno meglio, e lo diciamo.
- Componibile: si incastra negli altri sei invece di sostituirli.
- Costo visibile: possiamo dire in termini relativi cosa fa il pattern alla tua bolletta di token.
Ogni nome di pattern, ogni comportamento di framework citato e ogni moltiplicatore di costo qui è stato letto sulla fonte del vendor ad agosto 2026. Le API dei framework si muovono in fretta e i nomi degli argomenti andranno alla deriva. I nomi dei pattern sono stabili da quando Anthropic li ha pubblicati, ed è per questo che sono la parte che vale la pena memorizzare.
I sette pattern in sintesi
Di cosa sono fatti davvero gli agentic workflow? Di sette forme: una catena, uno smistamento, un fan-out, un manager con dei worker, un ciclo con un giudice, un ciclo con dei tool e un cancello con una persona dietro. Se stavi cercando un diagramma di agentic AI workflow, quella lista è quello che conterrebbe. Prendi la forma che corrisponde al lavoro che hai davanti, poi leggi la sua regola per evitarla prima di scrivere una riga di codice. Imparare a riconoscere prima la forma è gran parte di quello che insegniamo nel corso su automazione e sistemi agentici ad Agentic School.
- Prompt chaining: una sequenza fissa di chiamate al modello in cui ognuna lavora sull'output della precedente.
- Routing: un passo di classificazione economico che manda ogni input all'handler specializzato per il suo tipo.
- Parallelization: lo stesso lavoro distribuito su chiamate concorrenti, diviso in sezioni oppure messo ai voti.
- Orchestrator-workers: un modello lead inventa dei subtask a runtime, li delega e unisce i risultati.
- Evaluator-optimizer: un modello scrive la bozza, un altro la valuta contro una rubrica, e viene rivista finché non passa o finché il budget non finisce.
- L'autonomous tool loop: il modello sceglie da solo i suoi tool in un ciclo e decide quando ha finito.
- Human-in-the-loop checkpoint: il run si ferma prima di un'azione scelta e aspetta che una persona la approvi, la modifichi o la rifiuti.
Prompt chaining
Prompt chaining divide un compito in una sequenza fissa di chiamate al modello, ognuna delle quali prende l'output precedente come input. Anthropic lo mette per primo, LangGraph lo documenta con lo stesso nome, e il Google Agent Development Kit lo rilascia come Sequential Agent, che la sua documentazione definisce deterministico e prevedibile perché fissa l'ordine di esecuzione senza consultare un modello. Viene cercato anche come sequential workflow o LLM pipeline. Prendilo per primo perché l'ordine vive nel tuo codice: puoi infilare un controllo normalissimo fra due passi qualsiasi e interrompere prima di pagare la chiamata successiva, ed è il quality gate più economico di questa pagina. Paghi in latenza e in accumulo: tre chiamate concatenate sono tre round trip, e il passo tre eredita ogni errore del passo uno.
- Cos'è: una sequenza fissa, definita nel codice, di chiamate al modello, ognuna delle quali consuma l'output della precedente.
- Usalo quando: il compito si scompone in passi che puoi nominare in anticipo, per esempio scaletta, poi bozza, poi una riscrittura del tono.
- Evitalo quando: un solo prompt scritto bene supera già la tua valutazione. Dividerlo a quel punto ti compra latenza e nient'altro.
- Cosa si rompe per primo: l'accumulo silenzioso. Un passo uno sbagliato produce un passo tre sicuro di sé, ben formattato e falso, quindi valida fra un anello e l'altro, non solo alla fine.
Routing
Routing mette una chiamata di classificazione economica davanti a diversi handler specializzati e manda ogni input a quello giusto. Anthropic e LangGraph lo chiamano entrambi routing; l'OpenAI Agents SDK ne implementa una versione decentralizzata tramite gli handoff, che descrive come un meccanismo per coordinare e delegare il lavoro fra più agent. L'economia è tutto il richiamo: un prompt di classificazione breve su un modello piccolo manda la maggioranza facile del traffico su un percorso economico e riserva il modello costoso al resto. Il compromesso è che un errore di routing è silenzioso. L'handler specializzato risponde con sicurezza nella corsia sbagliata, e se non logghi la rotta scelta accanto al risultato non te ne accorgerai mai.
- Cos'è: un passo di classificazione che smista un input verso uno fra diversi prompt, modelli o tool specializzati a valle.
- Usalo quando: gli input cadono in categorie distinte che vanno gestite in modo diverso, e un unico prompt per tutte continua a regredire.
- Evitalo quando: la categoria si decide da dati strutturati. Un controllo su un campo o un'espressione regolare è gratis, immediato e non allucina mai una categoria.
- Cosa si rompe per primo: la classificazione sbagliata silenziosa. Logga la rotta insieme al risultato, e rilascia sempre un ramo di default per gli input che non corrispondono a niente.
Parallelization
Parallelization esegue diverse chiamate al modello in contemporanea e combina i risultati. Anthropic la divide in due varianti che conviene tenere separate: sectioning, dove subtask indipendenti girano in concorrenza, e voting, dove lo stesso compito gira più volte e tu prendi il consenso. LangGraph documenta entrambe sotto parallelization e il Google Agent Development Kit rilascia la forma come Parallel Agent. Sectioning ti compra tempo reale. Voting ti compra fiducia sulle valutazioni discrezionali dove un singolo campione non è affidabile, per esempio segnalare contenuti rischiosi. Nessuna delle due è gratis: paghi prezzo pieno per ogni ramo, quindi un voto a cinque costa circa cinque chiamate e restituisce una risposta.
- Cos'è: lo stesso lavoro distribuito su chiamate concorrenti, diviso in sezioni indipendenti oppure ripetuto per un voto.
- Usalo quando: i subtask davvero non dipendono uno dall'altro, oppure un singolo campione di una valutazione discrezionale non è abbastanza affidabile per agirci sopra.
- Evitalo quando: i passi dipendono uno dall'altro. Forzare una catena dipendente in rami paralleli produce contraddizioni che poi risolvi a mano.
- Cosa si rompe per primo: il conto e il merge. Il costo scala con il fan-out, e il passo che unisce rami in disaccordo è dove vivono la maggior parte dei bug veri.
Orchestrator-workers
Con orchestrator-workers un modello lead spezza un lavoro in subtask a runtime, li delega a dei worker e sintetizza i risultati. Si chiama anche planner-executor, supervisor, oppure lead agent e subagent, e i pattern planning e multi-agent collaboration di Andrew Ng atterrano entrambi qui. La differenza rispetto a parallelization è che nessuno decide i subtask in anticipo; l'orchestratore li inventa a partire dall'input. Anthropic ha usato esattamente questo per il suo sistema di ricerca multi-agent, con un lead agent che coordina mentre subagent specializzati lavorano in parallelo. È anche di gran lunga il pattern più caro qui: Anthropic riporta che i sistemi multi-agent usano circa 15x più token delle interazioni di chat, e dice chiaramente che hanno senso economicamente solo quando il compito vale abbastanza da pagarli. Anthropic nomina anche dove rende meno, e la risposta è istruttiva: domini in cui ogni agent ha bisogno dello stesso contesto o in cui i subtask hanno molte dipendenze, con il coding citato come esempio che ha meno subtask davvero parallelizzabili della ricerca.
- Cos'è: un modello lead scompone il compito a runtime, delega i pezzi ai worker e unisce quello che torna indietro.
- Usalo quando: i subtask sono imprevedibili, il lavoro si parallelizza davvero, e l'output vale grosso modo un ordine di grandezza di token in più.
- Evitalo quando: ogni worker ha bisogno dello stesso contesto, oppure i subtask dipendono uno dall'altro. Anthropic nomina entrambe come le condizioni in cui multi-agent rende meno.
- Cosa si rompe per primo: costo e coordinamento. A circa 15x i token di un turno di chat, fare debug di un orchestratore rotto è di per sé una voce di budget.
Evaluator-optimizer
Evaluator-optimizer mette un generatore e un critico in un ciclo: un modello scrive la bozza, un secondo la valuta contro una rubrica, e la bozza viene rivista finché non passa o finché il budget non finisce. Anthropic e LangGraph usano entrambi il nome evaluator-optimizer; la versione a modello singolo è quella che Andrew Ng chiama reflection, definita nella sua lettera DeepLearning.AI come il LLM che esamina il proprio lavoro per trovare modi di migliorarlo. Vale molto di più quando il valutatore non è affatto un modello. Una suite di test, un type checker o un validatore di schema restituiscono un passa o non passa netto invece di un'opinione plausibile, ed è per questo che questo pattern è la spina dorsale di un agentic coding workflow. Il guasto è famoso ed evitabile: senza un limite e con una rubrica vaga, la coppia riscrive lo stesso paragrafo quaranta volte, ogni versione diversa e nessuna migliore.
draft = generate(task)
for attempt in range(MAX_ROUNDS): # limitato, mai aperto
verdict = evaluate(draft) # una rubrica, un run di test, un type check
if verdict.passes:
break
draft = generate(task, feedback=verdict.notes)
return draft, attempt # logga il numero di giri: un trend in salita è il primo allarme- Cos'è: un ciclo di generazione, critica e revisione che gira finché non viene raggiunta una soglia di qualità esplicita o un limite di giri.
- Usalo quando: la qualità è misurabile e la prima bozza è regolarmente vicina ma non giusta, soprattutto quando il valutatore può essere un test invece di un modello.
- Evitalo quando: non riesci a scrivere la rubrica. Un valutatore senza criteri chiari produce agitazione che sembra progresso e costa come progresso.
- Cosa si rompe per primo: il ciclo che non termina mai. Limita i giri, pretendi che il punteggio migliori per guadagnarne un altro, e logga quanti giri ha richiesto ogni run.
L'autonomous tool loop
L'autonomous tool loop è quello che intende la maggior parte delle persone quando dice agent: il modello riceve dei tool e un obiettivo, sceglie quale tool chiamare, legge il risultato e decide da solo se chiamarne un altro o fermarsi. Si chiama anche ReAct, agent loop, o semplicemente tool use, che è il nome che gli dà Andrew Ng. Anthropic definisce gli agent come sistemi in cui il modello dirige dinamicamente i propri processi e il proprio uso dei tool, ed è esattamente la linea fra questo pattern e gli altri sei. È l'unico in cui non conosci il percorso in anticipo, e questo è insieme il punto e il prezzo: Anthropic riporta che gli agent usano circa 4x più token delle interazioni di chat e avverte che i sistemi agentici scambiano latenza e costo con la performance sul compito. Usalo dove non puoi prevedere la rotta ma puoi ancora verificare il risultato. Costruire questo ciclo a mano è trattato nella nostra guida su come costruire un AI agent da zero, quindi questa pagina resta su dove va usato.
- Cos'è: un modello con dei tool che gira in un ciclo, scegliendo da solo la prossima azione e il proprio punto di arresto.
- Usalo quando: il percorso non si può scrivere fisso perché dipende da quello che scoprono i passi precedenti, e il risultato finale resta verificabile.
- Evitalo quando: i passi sono noti in anticipo. Stai pagando circa 4x i token e aggiungendo non determinismo per riprodurre quello che una catena scriptata fa già correttamente.
- Cosa si rompe per primo: il guasto silenzioso di un tool. Un tool che in caso di errore restituisce una stringa lascia che il modello legga il fallimento come dato e vada avanti, quindi rendi i fallimenti tipizzati e rumorosi.
Human-in-the-loop checkpoint
L'human-in-the-loop checkpoint mette in pausa un run prima di un'azione scelta e aspetta che una persona la approvi, la modifichi o la rifiuti. È un pattern vero con primitive vere, non un disclaimer: l'OpenAI Agents SDK elenca human in the loop fra i suoi meccanismi integrati per coinvolgere le persone durante i run degli agent, e LangGraph lo implementa come interrupt, il cui uso documentato è la pausa prima di azioni critiche come chiamate API, modifiche al database e transazioni finanziarie, con la possibilità di modificare gli argomenti della tool call prima che venga eseguita. Quella capacità di modifica è la metà sottovalutata. Approvare una chiamata sbagliata è un testa o croce; correggere l'argomento e proseguire trasforma il checkpoint in un segnale che puoi riportare nel prompt. Il failure mode qui è umano: metti un cancello davanti a troppe azioni e il revisore inizia a timbrare senza leggere, il che è peggio di nessun cancello perché fabbrica l'apparenza del controllo.
- Cos'è: una pausa esplicita prima di un'azione selezionata, in cui una persona la approva, ne modifica gli argomenti, o la rifiuta.
- Usalo quando: l'azione è irreversibile, finanziaria, rivolta al cliente o difficile da rilevare quando è sbagliata. Adatta il cancello al costo di un errore.
- Evitalo quando: l'azione è economica, reversibile e ad alto volume. Un cancello lì non compra niente e allena il revisore a cliccare approva senza leggere.
- Cosa si rompe per primo: il timbro automatico. Metti un cancello davanti a poche azioni davvero pericolose, mostra gli argomenti esatti, e lascia che il revisore ripari la chiamata invece di limitarsi ad accettarla o rifiutarla.
Agentic workflow o automazione classica
Ecco il test, e richiede dieci secondi: se i passi sono noti in anticipo e gli input sono strutturati, non è un agentic workflow, e trasformarlo in uno costa soldi e aggiunge failure mode. Anthropic traccia la stessa linea, definendo i workflow come sistemi in cui modelli e tool sono orchestrati attraverso percorsi di codice predefiniti e gli agent come sistemi in cui il modello dirige dinamicamente il proprio processo. LangGraph lo formula quasi identico. Il Google Agent Development Kit definisce i suoi workflow agent di template deterministici e prevedibili proprio perché fissano la sequenza di esecuzione senza consultare un modello. Quindi la vera domanda non è mai se gli agent siano buoni. È se la decisione che stai consegnando a un modello sia davvero una decisione, o solo un ramo che non volevi scrivere. L'agentic AI workflow automation si guadagna il suo sovrapprezzo solo quando il passo successivo dipende da quello che un passo precedente ha trovato.
- Passi noti in anticipo, input strutturati: usa uno script, una coda o un tool di workflow automation. Nessun modello serve da nessuna parte lì dentro.
- Passi noti in anticipo, un passo richiede linguaggio o giudizio: usa un workflow semplice con una singola chiamata al modello dentro. Ancora non è un agentic workflow.
- I passi dipendono da quello che scoprono i passi precedenti, e il risultato è verificabile: è qui che un agentic workflow si guadagna il suo costo.
- Passi imprevedibili e risultato non verificabile: non automatizzarlo ancora. Un ciclo autonomo non verificabile genera solo output sicuro di sé che nessuno può controllare.
- Prima il controllo dei costi: Anthropic riporta gli agent a circa 4x i token di un'interazione di chat e i sistemi multi-agent a circa 15x. Moltiplica per il tuo volume prima di impegnarti.
I failure mode e il guardrail per ciascuno
Gli AI agentic workflow falliscono in cinque modi riconoscibili, e ognuno ha un guardrail con un nome, economico prima del lancio e caro da aggiungere dopo un incidente. Nota che nessuno di questi è un problema di qualità del modello. Un modello migliore fa arrivare ogni guasto più tardi e costare di più quando arriva, ed è per questo che i team che escono da un incidente facendo un upgrade tendono a ritrovarsene una versione più grossa un trimestre dopo. I guardrail oggi sono documentati invece che improvvisati: l'OpenAI Agents SDK rilascia guardrail di input e di output il cui tripwire scatta immediatamente e ferma il run, e i guardrail di input possono girare in modalità bloccante, così una richiesta cattiva viene rifiutata prima che venga speso un token. Trattiamo questa lista come il minimo indispensabile nella lezione human-in-the-loop ad Agentic School.
- Cicli che non terminano mai: limita ogni ciclo con un numero massimo di giri e pretendi un miglioramento misurabile per guadagnarne un altro. Un retry senza limite è la causa più comune di una bolletta a sorpresa.
- Guasti silenziosi dei tool: un tool che restituisce una stringa di errore lascia che il modello legga il fallimento come dato e prosegua. Restituisci fallimenti tipizzati e ferma il run su quelli da cui non può riprendersi.
- Esplosioni di costo sui retry: metti un tetto alla spesa per run, non solo al mese, e fai fail closed al tetto. La logica di retry moltiplicata per un profilo di token multi-agent a 15x è il modo in cui un singolo run di test supera un budget mensile.
- Nessun checkpoint umano: interrompi prima delle azioni irreversibili, cosa che LangGraph documenta specificamente per chiamate API, modifiche al database e transazioni finanziarie, e lascia che il revisore modifichi gli argomenti.
- Nessun modo di rigiocare quello che è successo: persisti il run. I checkpointer di LangGraph salvano lo stato del thread per il time travel e la tolleranza ai guasti, e l'OpenAI Agents SDK rilascia il tracing per visualizzare, fare debug e monitorare i workflow. Senza, ogni revisione di un incidente è tirare a indovinare.
I sette agentic design pattern a confronto
Questi sette si compongono, e la maggior parte degli agentic AI workflow in produzione sono tre di essi collegati insieme. Ogni riga qui sotto porta le stesse quattro cose nello stesso ordine: chi controlla il percorso, quanto costa rispetto a una chiamata singola, in cosa è il migliore, e cosa tenere d'occhio. Niente qui è nuovo; ogni fatto compare nella sezione sopra.
- Prompt chaining: percorso controllato dal tuo codice, una chiamata per passo, il migliore per compiti che puoi scomporre in anticipo, tieni d'occhio gli errori che si accumulano lungo la catena.
- Routing: percorso controllato da una chiamata di classificazione, una chiamata economica più un handler, il migliore per tipi di input misti, tieni d'occhio la classificazione sbagliata silenziosa.
- Parallelization: percorso controllato dal tuo codice, costo moltiplicato per il fan-out, il migliore per subtask indipendenti o voti di consenso, tieni d'occhio il passo di merge e il conto.
- Orchestrator-workers: percorso controllato da un modello lead a runtime, circa 15x un'interazione di chat secondo Anthropic, il migliore per lavoro di alto valore che si parallelizza, tieni d'occhio i compiti a contesto condiviso.
- Evaluator-optimizer: percorso controllato da una soglia di qualità, una chiamata per giro, il migliore quando la qualità è misurabile e idealmente testabile, tieni d'occhio i cicli di riscrittura senza limite.
- L'autonomous tool loop: percorso controllato dal modello, circa 4x un'interazione di chat secondo Anthropic, il migliore quando la rotta è imprevedibile ma il risultato è verificabile, tieni d'occhio i guasti silenziosi dei tool.
- Human-in-the-loop checkpoint: percorso controllato da una persona in un punto, quasi zero in token e reale in tempo trascorso, il migliore prima delle azioni irreversibili, tieni d'occhio il timbro automatico.
Quale agentic workflow pattern scegliere
Lo decidono tre cose, e nessuna di queste è quale pattern sia il più interessante. Primo, chi deve controllare il percorso: se riesci a nominare i passi, il tuo codice deve possederli e il modello deve solo riempire le parti che richiedono linguaggio. Secondo, se l'output è verificabile, perché un pattern che non puoi controllare è un pattern che non puoi automatizzare in sicurezza. Terzo, cosa fa il tuo volume al moltiplicatore di token, dato che un sovrapprezzo di 4x o 15x che è banale su dieci run a settimana diventa una voce di budget a diecimila.
Se sei un founder singolo che automatizza le proprie operazioni, parti con prompt chaining più un checkpoint umano su tutto ciò che tocca soldi o un cliente, e aggiungi routing solo quando puoi indicare i tipi di input che continuano a rompere un unico prompt. Se stai costruendo un agentic coding workflow, usa l'autonomous tool loop con la tua suite di test come valutatore invece di un secondo modello che dà voti alla prosa, e limita i giri. Se orchestrator-workers ti tenta, aspetta finché i subtask non sono davvero sconosciuti in anticipo, davvero paralleli e non valgono grosso modo quindici volte i token, perché tutto quello che sta sotto gira meglio e costa meno come catena.
I pattern qui sopra, i guardrail e i build da cui vengono sono insegnati dall'inizio alla fine nei corsi gratuiti di Agentic School.
