Ogni team che costruisce agenti AI si imbatte nello stesso ostacolo.
Si inizia con un prompt e pochi strumenti.
Funziona.
Poi i requisiti crescono. Più casi limite. Più team. Più rischi.
All'improvviso il tuo "agente" è un prompt di sistema da 3000 parole che cerca di fare cinque lavori contemporaneamente.
La soluzione non è altro prompt engineering.
È scegliere il pattern giusto.
Ecco i 15 pattern con cui è costruito ogni sistema agente in produzione — e quando usarli esattamente.
Prima di scegliere un pattern
Non ogni attività necessita di un agente.
Un'attività giustifica un agente quando:
→ Una singola chiamata del modello non può produrre un risultato affidabile
→ Il modello deve scegliere tra strumenti o fonti di dati in fase di esecuzione
→ L'attività richiede pianificazione, validazione o perfezionamento iterativo
→ Il flusso di lavoro ha una reale incertezza che non può essere codificata
Un'attività di solito non necessita di un agente quando il percorso input-output è prevedibile.
Riassunto. Classificazione. Estrazione semplice. Generazione basata su template.
Queste sono più veloci, più economiche e più affidabili come chiamate dirette al modello.
Avvolgerle in un agente aggiunge solo latenza e punti di fallimento per zero benefici.
PATTERN 1 — Agente Singolo
Il punto di partenza più semplice e comune.
Un modello. Un prompt di sistema. Un insieme limitato di strumenti.
Il modello decide quale strumento chiamare, osserva il risultato e continua finché non ha abbastanza per rispondere.
Esempio reale: Un agente di assistenza clienti che cerca lo stato dell'ordine, verifica la spedizione e crea un ticket se non riesce a risolvere il problema — il tutto con 2-3 strumenti e un unico compito chiaro.
Usalo quando: il compito è ben definito, il set di strumenti è piccolo e un singolo agente può mantenere l'intero contesto senza confondersi.
Si rompe quando: continui ad aggiungere strumenti e il prompt di sistema supera una pagina. Questo è il segnale che hai bisogno di un pattern diverso — non di un prompt più lungo.
PATTERN 2 — Multi-Agente Sequenziale
Agenti specializzati vengono eseguiti in un ordine fisso. L'output di ciascuno alimenta l'input del successivo.
Esempio reale: Una pipeline di revisione contrattuale — un agente estrae gli obblighi, il successivo identifica i rischi, un terzo redige il riepilogo per gli acquisti. La sequenza non cambia mai.
Usalo quando: il flusso di lavoro ha fasi chiare e ripetibili e ogni fase produce esattamente ciò di cui la successiva ha bisogno.
Si rompe quando: l'ordine deve effettivamente variare in base a ciò che viene scoperto a metà processo. Le pipeline sequenziali presuppongono che il percorso sia fisso — se non lo è, hai bisogno di qualcosa di più dinamico.
PATTERN 3 — Multi-Agente Parallelo
Sottoattività indipendenti vengono eseguite simultaneamente, poi combinate in un'unica visione.
Esempio reale: Un incidente di produzione alle 2 di notte. Tre agenti indagano su log, metriche e deployment recenti contemporaneamente — non uno dopo l'altro — perché ogni minuto conta durante un'interruzione.
Usalo quando: le sottoattività sono genuinamente indipendenti e la velocità è importante.
Si rompe quando: le attività dipendono effettivamente dai risultati l'una dell'altra. Forzare lavoro dipendente in esecuzione parallela crea solo race condition e contesto incompleto.
PATTERN 4 — Ciclo (Loop)
Ripeti una sequenza di passaggi finché non viene soddisfatta una condizione di uscita.
Esempio reale: Un agente di pulizia dati che analizza dati CSV disordinati, propone un piano di pulizia, verifica se supera gli standard di qualità e riprova in caso contrario — fino a un numero massimo di tentativi.
Usalo quando: l'attività richiede più tentativi e puoi definire una condizione di arresto chiara e verificabile.
Si rompe quando: non esiste una condizione di uscita affidabile. Senza, ottieni costi incontrollati e un sistema che potrebbe non terminare mai.
PATTERN 5 — Revisione e Critica
Un agente giudice esamina l'output di un altro agente, lo critica e fornisce feedback specifici e attuabili.
Esempio reale: Un report generato viene revisionato da un agente "critico" separato che segnala affermazioni deboli, prove mancanti o sezioni poco chiare prima che arrivi mai a un umano.
Usalo quando: la qualità è più importante della velocità e desideri una seconda opinione integrata nel sistema, non aggiunta in un secondo momento.
Si rompe quando: l'agente critico utilizza gli stessi punti ciechi del generatore. Un revisore addestrato su presupposti simili non noterà gli stessi errori.
PATTERN 6 — Perfezionamento Iterativo
Un ciclo di feedback con una soglia di punteggio di qualità. Il generatore continua a perfezionare finché non supera la soglia.
Esempio reale: Un generatore di testi di marketing che assegna un punteggio alla propria bozza rispetto alle linee guida del marchio e continua a riscrivere finché non raggiunge un punteggio di qualità minimo — non un semplice controllo passa/non passa, ma un miglioramento graduale.
Usalo quando: la qualità dell'output è genuinamente variabile e "abbastanza buono" ha una soglia misurabile.
Si rompe quando: la funzione di punteggio è vaga o manipolabile. Se il modello può gonfiare il proprio punteggio senza un reale miglioramento, il ciclo brucia solo token.
PATTERN 7 — Coordinatore
Un agente di routing centrale indirizza le richieste ad agenti specializzati in base a ciò che viene effettivamente chiesto.
Esempio reale: I ticket di assistenza vengono instradati a specialisti di fatturazione, tecnici, account, spedizione o frode — ciascuno con un contesto ristretto invece di un singolo agente che cerca di sapere tutto.
Usalo quando: hai tipi di richiesta genuinamente diversi che necessitano di contesto, strumenti o logiche decisionali diverse.
Si rompe quando: il routing stesso diventa ambiguo. Se le richieste non rientrano chiaramente in una categoria, il coordinatore diventa un nuovo collo di bottiglia e una fonte di instradamento errato.
PATTERN 8 — Scomposizione Gerarchica delle Attività
Un agente radice scompone un obiettivo complesso in sotto-obiettivi più piccoli, li delega a lavoratori specializzati, poi sintetizza il tutto in un'unica risposta.
Esempio reale: "In quali 3 paesi dovremmo espanderci il prossimo anno?" viene suddiviso in analisi competitiva, ricerca normativa, fattibilità logistica e dimensionamento del mercato — ciascuno gestito da uno specialista diverso, poi combinato.
Usalo quando: il problema è troppo ampio per un singolo passaggio di ragionamento ma si suddivide chiaramente in aree di competenza indipendenti.
Si rompe quando: i sotto-obiettivi non sono effettivamente indipendenti. Se i flussi di lavoro devono informarsi a vicenda in tempo reale, scomporli a monte perde quell'interazione.
PATTERN 9 — Sciame (Swarm)
Più agenti specializzati contribuiscono a una discussione condivisa, sfidano le ipotesi degli altri e un facilitatore sintetizza una raccomandazione finale.
Esempio reale: L'azienda dovrebbe lanciare un livello in abbonamento? Gli agenti di ricerca, ingegneria, finanza e supporto discutono ciascuno la propria prospettiva in più round prima che un facilitatore valuti i compromessi.
Usalo quando: non esiste una singola risposta "corretta" — hai bisogno di una decisione ben motivata, plasmata da punti di vista genuinamente contrastanti.
Si rompe quando: hai bisogno di una risposta veloce e deterministica. Gli sciami sono deliberatamente lenti ed esplorativi — strumento sbagliato se hai bisogno di velocità.
PATTERN 10 — ReAct (Ragiona e Agisci)
L'agente alterna tra ragionamento e azione: decide cosa investigare, chiama uno strumento, osserva il risultato, decide se ci sono abbastanza prove.
Esempio reale: "Il processore di code sembra bloccato" — l'agente cerca nei documenti, verifica lo stato del servizio, correla i risultati e solo allora suggerisce una soluzione. Il percorso di indagine non è predefinito; dipende da ciò che trova lungo il cammino.
Usalo quando: il percorso verso la risposta non può essere pianificato a priori — dipende da ciò che ogni passo rivela.
Si rompe quando: le indagini si protraggono senza convergere. Limita sempre il numero di cicli ragionamento-azione, altrimenti rischi un'esplorazione infinita.
PATTERN 11 — Uomo nel Ciclo (Human-in-the-Loop)
L'agente indaga e raccomanda, ma un essere umano prende la decisione finale su qualsiasi cosa rischiosa o ambigua.
Esempio reale: Approvazioni di rimborsi — i casi a basso rischio e chiari vengono automatizzati. Importi elevati, segnali di frode o eccezioni alle policy vengono messi in pausa per la revisione umana prima che qualsiasi cosa venga finalizzata.
Usalo quando: la decisione comporta un rischio finanziario, legale o di reputazione reale e la piena automazione non è ancora accettabile.
Si rompe quando: tratti questo come una semplice funzionalità dell'interfaccia utente invece che come una decisione architetturale. Hai bisogno di stato persistente, assegnazione del revisore, gestione dei timeout e percorsi di escalation — non solo un pulsante "pausa".
PATTERN 12 — Pianifica ed Esegui (Plan-and-Execute)
Un agente pianificatore crea un piano strutturato completo a monte — revisionabile e modificabile — prima che venga intrapresa qualsiasi azione. Poi un esecutore segue i passaggi.
Esempio reale: "Ridimensiona il parco macchine da 10 a 20 istanze, verifica che la coda si svuoti, aggiorna il runbook." Il piano completo è visibile prima dell'inizio dell'esecuzione, a differenza di ReAct dove il percorso emerge passo dopo passo.
Usalo quando: desideri che il piano sia revisionabile o approvabile prima di qualsiasi azione — importante per operazioni con conseguenze reali.
Si rompe quando: l'ambiente cambia più velocemente di quanto il piano possa essere eseguito. Un piano obsoleto eseguito ciecamente è peggio di nessun piano.
PATTERN 13 — Riflessione (Reflexion)
L'agente valuta i propri fallimenti, riflette su cosa è andato storto e porta quella memoria nel tentativo successivo.
Esempio reale: Un agente di generazione di codice scrive uno script, fallisce in fase di esecuzione, l'agente analizza l'errore effettivo, registra cosa correggere e riprova — diventando più intelligente ad ogni tentativo invece di ripetere lo stesso errore.
Usalo quando: i fallimenti sono informativi e l'autocorrezione migliora genuinamente il tentativo successivo.
Si rompe quando: le modalità di fallimento sono casuali o non correlate tra loro. La riflessione aiuta solo quando c'è un modello reale da cui imparare.
PATTERN 14 — Logica Personalizzata (Custom Logic)
Un ibrido: il codice deterministico gestisce le regole che non devono mai essere sbagliate, mentre il modello gestisce il giudizio, la stesura e la gestione delle eccezioni.
Esempio reale: Un flusso di lavoro per rimborsi in cui la verifica dell'acquisto e i controlli antifrode vengono eseguiti come rigide regole deterministiche — mai delegate al modello — mentre la stesura della risposta al cliente e le raccomandazioni di instradamento rimangono agentiche.
Usalo quando: il flusso di lavoro ha una reale logica di diramazione con conseguenze legali o finanziarie e devi essere preciso su ciò che è deterministico rispetto a ciò che è flessibile.
Si rompe quando: i team confondono i ruoli e lasciano che il modello prenda decisioni che dovrebbero essere regole codificate. Idoneità, permessi e movimenti di denaro non dovrebbero mai essere solo una decisione del modello.
PATTERN 15 — Agente Guidato dagli Eventi (Event-Driven Agent)
L'agente non aspetta di essere chiamato. Si iscrive a un flusso di eventi e agisce nel momento in cui una condizione viene attivata.
Esempio reale: Un agente di rilevamento frodi che reagisce nell'istante in cui viene attivato un evento di transazione sospetta — non quando un ticket di assistenza lo segnala eventualmente, momento in cui il danno è già fatto.
Usalo quando: la tempistica è più importante di qualsiasi altra cosa e aspettare una richiesta umana significa perdere la finestra per agire.
Si rompe quando: le condizioni di attivazione sono scarsamente definite. Un flusso di eventi rumoroso con trigger vaghi si trasforma in un sistema che urla costantemente al lupo — o peggio, che perde il vero segnale.
Selezione del pattern — abbina l'incertezza, non l'hype
Il pattern giusto corrisponde alla forma dell'incertezza nel tuo lavoro:
→ Incertezza su quale strumento usare → Agente Singolo o ReAct
→ Incertezza su dove instradare → Coordinatore
→ Incertezza sulla qualità → Revisione e Critica o Perfezionamento Iterativo
→ Incertezza sul percorso di esecuzione → Pianifica ed Esegui o ReAct
→ Incertezza su come autocorreggersi → Riflessione o Ciclo
→ Incertezza sul rischio aziendale → Uomo nel Ciclo o Logica Personalizzata
→ Incertezza sulla struttura del problema → Scomposizione Gerarchica o Sciame
→ Non puoi aspettare una richiesta → Agente Guidato dagli Eventi
Uno sciame non è più avanzato di un agente singolo se l'attività necessita solo di una chiamata affidabile a uno strumento.
Pianifica ed Esegui non è un aggiornamento rispetto a ReAct se il tuo piano diventa obsoleto al terzo passaggio.
I sistemi di produzione più affidabili non sono quelli più autonomi.
Mettono l'autonomia esattamente dove crea valore — e la vincolano ovunque altro.
10 regole per sistemi agentici in produzione
- Inizia con il pattern più piccolo che funziona. Un agente singolo con contratti di strumento puliti batte un sistema multi-agente con contratti deboli.
- Scrivi le descrizioni degli strumenti come contratti. Il modello sa cosa fa lo strumento solo dalla descrizione — non dalla tua intenzione.
- Limita le iterazioni, le chiamate agli strumenti e la spesa per richiesta. Un agente senza limiti di budget è una passività che aspetta solo di apparire in una fattura.
- Registra la traccia completa delle azioni. Chiamate agli strumenti, argomenti, output, decisione finale. Senza questo, l'indagine sugli incidenti è un'ipotesi.
- Mantieni le azioni irreversibili dietro controlli deterministici o approvazione umana. Non lasciare mai che un modello sia l'unico gatekeeper prima di un movimento di denaro o di una modifica in produzione.
- Valuta con casi di fallimento reali, non solo percorsi felici. La correttezza sul percorso felice è un prototipo. La correttezza sui casi limite è un prodotto.
- Separa i prompt per responsabilità prima che il prompt di sistema diventi illeggibile. "Ma non fare X quando Y" che si insinua nel tuo prompt significa che l'agente sta facendo due lavori.
- Tratta i sistemi multi-agente come sistemi distribuiti. Fallimento parziale, timeout, tentativi e osservabilità non sono opzionali.
- La revisione del modello non sostituisce la validazione deterministica. Usa i giudici per migliorare la qualità. Usa test e controlli dei permessi per garantire la correttezza.
- Preferisci il pattern più semplice — non perché semplice sia sempre meglio, ma perché il budget di complessità che risparmi può essere speso per strumenti migliori, prompt migliori, valutazione migliore.
Questi sono tutti i 15.
La maggior parte dei team non fallisce perché ha scelto il pattern sbagliato.
Falliscono perché non si sono mai chiesti quale incertezza stavano effettivamente risolvendo.
Scegli il pattern. Abbina la forma del problema. Non aggiungere autonomia dove non si guadagna il suo posto.
Se questo è stato utile:
→ Ripostalo per condividerlo con ogni ingegnere che costruisce agenti nel tuo team
→ Segui @sairahul1 per altre analisi come questa
→ Aggiungilo ai preferiti — ci tornerai ogni volta che inizi un nuovo progetto di agente
Scrivo di AI, costruzione di prodotti e sistemi che funzionano senza di te.
