Multi-agent è di moda. Ogni paper nuovo aggiunge un ruolo: un planner, un critic, un reviewer, un retrieval-er. La tentazione di mettere insieme cinque agenti per un task è altissima. Quasi sempre è sbagliata.
Provo a raccontare i quattro pattern multi-agent che usiamo in produzione, quando li abbiamo accesi e quando li abbiamo spenti.
Quando NON serve multi-agent
Prima la regola del pollice: per task lineari, con output ben definito e dimensioni di prompt sotto i 30-50k token in input, un singolo modello con un prompt curato batte ogni multi-agent setup, costa meno, è più facile da debuggare. La maggior parte dei task di automazione PMI sta lì.
Multi-agent diventa utile quando: l’output ha più stadi naturali che richiedono "perdita di stato controllata", oppure ti serve esplicitamente un punto di vista esterno (critique), oppure i tool e i context window non stanno in un singolo modello.
Pattern 1: Pipeline (a cascata)
Il più semplice. Agente A produce output, agente B legge l’output di A e lo trasforma, agente C legge l’output di B. Ogni agente ha un compito ristretto e ben specificato.
Quando lo usiamo. Redazione documenti complessi: l’agente RICERCA prima trova la giurisprudenza rilevante, l’agente REDAZIONE poi scrive la bozza usando solo quanto ha trovato A, l’agente REVISIONE infine fa il fact-check e segnala incoerenze.
Perché funziona. Ogni agente vede solo il contesto che gli serve. Niente "ragiona su 30 mila token a ogni passo". I prompt restano nitidi.
Tradeoff. Latenza somma. Se A impiega 8 secondi, B 10, C 12, sei a 30 secondi di tempo di risposta. Per task batch va bene, per UX live a volte non lo vuoi.
Trappola. "Errore amplificato". Se A produce qualcosa di leggermente sbagliato, B non se ne accorge e ci costruisce sopra. Mitigation: insegnare a B a contestare A quando l’input puzza. È un patch, non una cura.
Pattern 2: Supervisor + Workers
Un agente "orchestratore" decide cosa fare, e a runtime istanzia agenti specializzati per pezzi specifici del task. È il pattern di tool use elevato a sistema.
Quando lo usiamo. Task aperti, dove non sai a priori i passi. Per esempio: "produci un report sull’andamento Q1 di questo cliente". L’orchestratore decide di chiamare prima un agente SQL per estrarre i dati, poi un agente VISUAL per fare grafici, poi un agente NARRATIVO per scrivere la prosa, poi un agente FACT-CHECK per validare i numeri.
Perché funziona. Adattabile. Lo stesso orchestratore gestisce centinaia di varianti di task senza pre-programmazione esplicita.
Tradeoff. Complessità. Devi mettere logging molto buono, altrimenti debug è impossibile. E il modello orchestratore deve essere robusto: noi tipicamente ci mettiamo un Claude Opus o GPT-4o, mai modelli piccoli, anche se costa più caro.
Trappola. "Sopra-orchestrazione". L’orchestratore decide di chiamare 8 agenti quando ne sarebbero bastati 2. Bruci budget. Mitigation: budget hard nel system prompt ("massimo 5 chiamate a sub-agent, oltre devi fermarti").
Pattern 3: Debate (due agenti che si contestano)
Due agenti (o due istanze dello stesso modello con prompt diversi) producono ognuno la sua soluzione al problema. Un terzo agente "giudice" sceglie quella migliore, o un quarto round chiede ai due di rivedersi a vicenda.
Quando lo usiamo. Decisioni complesse dove non esiste ground truth e ti serve robustezza. Per esempio: review di una clausola contrattuale ambigua — l’agente PRO la difende, l’agente CONTRO la attacca, il GIUDICE legge entrambi e produce la nota finale al partner.
Perché funziona. Pattern noto da Anthropic, OpenAI, DeepMind: il debate riduce le allucinazioni perché chi mente ha più probabilità di essere smascherato da un altro modello che cerca buchi.
Tradeoff. Costo. Sei in 3x. E latenza alta.
Trappola. "Echo chamber". Se i due "debaters" sono entrambi LLM con la stessa policy, tendono a essere d’accordo. Diversificare: temperature diverse, prompt diversi che assegnano ruoli, idealmente provider diversi (Claude vs GPT).
Pattern 4: Reflection (agente che si rivede)
Un singolo agente, due passi: produzione → critica → revisione. Stesso modello, contesto crescente. È una versione light di debate dove il "giudice" è lo stesso che ha prodotto.
Quando lo usiamo. Output che hanno bisogno di rifinitura: riassunti di documenti lunghi, traduzioni delicate, copywriting per pubblicità.
Perché funziona. Quasi gratis (un round in più, stesso modello). Migliora il polish del 15-25% in media nei nostri test.
Tradeoff. Diminishing returns dopo il primo passaggio di critica. Tre, quattro round non aiutano più di uno o due.
Trappola. "Over-refinement". Su task semplici la critica trova problemi inesistenti e il modello li aggiusta peggiorando l’output. Mitigation: insegnare al modello che "se non trovi problemi sostanziali, lascia il primo draft come è".
La metrica che usiamo per decidere
Per scegliere se un task vada con singolo prompt, pipeline, supervisor, debate o reflection:
- ◆Singolo prompt quando: output prevedibile, contesto sotto 30k token, latenza importante.
- ◆Pipeline quando: output ha stadi chiari, latenza non critica, vuoi cap sul costo.
- ◆Supervisor quando: task aperto, percorso non pre-determinato, ok a spendere.
- ◆Debate quando: decisione di valore alto, no ground truth, ok a pagare 3x.
- ◆Reflection quando: vuoi più polish con piccolo aumento di costo.
Quasi mai metti più di un pattern insieme. Multi-agent + reflection + debate = budget bruciato e debug impossibile.
Cosa abbiamo smontato
Tre setup multi-agent che ci sembravano furbi e abbiamo poi disinstallato:
- ◆"Orchestratore + 4 specialisti" per un task che si scopri rispondibile con un singolo prompt curato di 3000 token. Avevamo aumentato la complessità per modore, non per necessità.
- ◆"Debate" su risposte tier-1 di customer service. Era 3x più caro per zero miglioramento misurabile. Tornati a singolo prompt.
- ◆"Reflection" infinita su generazione di codice. Più giri, più il codice diventava difensivo e overengineered. Capped a un solo round.
La regola
Aggiungi un agente al sistema solo quando un test A/B rispetto al pattern precedente dimostra che vale la spesa e la latenza. Mai per ragioni estetiche. Niente è più costoso e fragile di un’architettura multi-agent costruita perché "sembra giusta".