Pattern di design per sistemi multi-agente in produzione

Un sistema multi-agente è un'architettura AI dove due o più agenti LLM si coordinano per risolvere un task che un singolo agente gestisce male, dividendo i ruoli, lavorando in parallelo o passando lo stato attraverso un grafo esplicito. Il pattern funziona quando il problema è scomponibile, il valore della risposta copre il costo in token e il team ha un modo per debuggare i fallimenti tra agenti. Si rompe quando queste tre condizioni non sono soddisfatte.

La maggior parte dei team lo scopre nel modo costoso. La misura di Anthropic è che i sistemi multi-agente consumano circa 15 volte più token di una conversazione chat, con un miglioramento del 90,2% sulle valutazioni interne di ricerca. Quel rapporto ha senso solo per task ad alto valore dove la risposta vale la spesa. Per un chatbot che risponde a richieste di rimborso, è malpractice.

Perché i setup multi-agente ingenui falliscono in produzione

Il Berkeley Sky Computing Lab ha rilasciato MAST, una Multi-Agent Systems Failure Taxonomy, dopo aver analizzato oltre 1.600 trace su sette framework open source diffusi. Hanno trovato 14 modalità di fallimento distinte raggruppate in tre categorie: problemi di system design, disallineamento inter-agente e gap di verifica del task. Il numero principale: ChatDev, uno dei framework più citati nella letteratura accademica, ha ottenuto il 33,33% di correttezza sul suo stesso benchmark ProgramDev.

I dati di settore vanno nella stessa direzione. Circa il 40% dei pilot multi-agente fallisce entro sei mesi dal deploy in produzione, di solito perché il team ha scelto una forma di orchestrazione che non matchava il problema e l'ha scoperto solo dopo l'arrivo della fattura.

La modalità di fallimento ingenua è coerente. Un team legge un blog post sulla collaborazione tra agenti, sceglie CrewAI o LangGraph perché era in cima ai risultati di ricerca, avvolge quattro ruoli intorno allo stesso modello e lo chiama sistema multi-agente. Gli agenti poi spendono token discutendo tra loro, ripetono il lavoro l'uno dell'altro, perdono lo stato quando la conversazione cresce oltre la context window e falliscono in silenzio perché nessuno ha cablato l'observability nel grafo. Ogni singola fix sembra piccola. Il costo cumulato è il progetto.

Perché "aggiungere più agenti" peggiora le cose

L'istinto, quando un agente fatica, è quello di generare aiutanti. È sbagliato di default. Ogni nuovo agente moltiplica il costo di coordinamento, espande la superficie per il disallineamento inter-agente (categoria MAST 2) e aggiunge un altro candidato che l'orchestratore può gestire male. Ogni paper e ogni retrospettiva di produzione converge sullo stesso consiglio: parti con un singolo agente, aggiungi specializzazione solo quando un collo di bottiglia misurabile lo richiede, e non dividere mai un task che un agente potrebbe completare in un singolo pass.

L'altro istinto è il dibattito. Il multi-agent debate sembra elegante sulla carta e produce risposte migliori su certi benchmark di reasoning, ma in produzione consuma token linearmente per turno, spesso senza convergere. Riservalo per task in cui il guadagno marginale di accuratezza è auditabile e il budget di latenza è generoso.

I cinque pattern che sopravvivono in produzione

1. Orchestrator-Worker

Un agente lead scompone una query in subtask, li dispatcha ad agenti worker specializzati e assembla il risultato. Questa è la forma che usa la feature Research di Anthropic, con Claude Opus 4 come orchestratore e Claude Sonnet 4 come worker, ognuno con la propria context window e il proprio set di strumenti. Il pattern è corretto quando i subtask sono genuinamente indipendenti (cerca il subgrafo A mentre gira il subgrafo B), quando ogni worker ha un obiettivo chiaramente delimitato e quando l'orchestratore può descrivere il task in un prompt strutturato che nomina il formato di output.

Usalo per: sintesi di ricerca, raccolta dati in parallelo, generazione di codice su più moduli. Evitalo per: chat, flussi di rimborso, qualsiasi cosa sequenziale per natura. L'orchestratore delega gli strumenti attraverso un'interfaccia standard, ed è uno dei motivi per cui un server MCP di solito si ripaga nel momento in cui più di un agente condivide gli stessi strumenti.

2. Pipeline sequenziale

Gli agenti girano in un ordine fisso. L'output dello step N è l'input dello step N+1. La forma è noiosa, prevedibile e copre la maggior parte dei workload di agenti che vanno in produzione. Le pipeline hanno senso quando il task ha una progressione naturale (extract, transform, validate, write) e quando lo schema di output di ogni step è abbastanza stabile per fare type-check al boundary.

La trappola è usare una pipeline quando il task è in realtà un grafo. Se lo step 3 a volte deve tornare allo step 1, non hai una pipeline. Hai una state machine, ed è quello che LangGraph modella bene.

3. Fan-out e fan-in in parallelo

Un orchestratore dispatcha la stessa variazione di task su N worker, poi aggrega. Questo pattern è ciò che dà ai sistemi multi-agente il loro vantaggio misurato in velocità. Conviene solo quando il lavoro è genuinamente parallelo, quando lo step di aggregazione non è banale (altrimenti stai pagando N volte per una sola risposta) e quando il budget di token lo permette. Il numero del 90,2% di performance di Anthropic vive qui.

4. Coreografia invece di orchestrazione (quando i fallimenti sono tollerabili)

I sistemi coreografati lasciano che gli agenti dichiarino le proprie capacità e un router li tira dentro quando servono. CrewAI usa di default questa forma. La coreografia sopravvive al fallimento di un singolo agente meglio dell'orchestrazione, perché non c'è un coordinatore singolo da far crashare. Il trade-off è la debuggabilità: quando qualcosa va storto in una run coreografata, il trace sembra un albero telefonico e passi ore a ricostruire l'intento.

Scegli la coreografia per workload critici sulla resilienza dove una risposta degradata del 10% è meglio di una risposta mancante. Scegli l'orchestrazione per tutto ciò dove devi spiegare a un cliente perché una risposta è sbagliata.

5. Model tiering

Usa un modello economico (Haiku, Sonnet) per triage, classificazione e routing. Riserva il modello costoso (Opus, classe GPT-4) per il reasoning vero e la sintesi finale. I team in produzione riportano riduzioni di costo dal 40 al 60% da questa singola decisione, di solito sufficiente a rendere difendibile il moltiplicatore di token 15x del multi-agente. Il tiering non è tecnicamente un pattern multi-agente nel senso dell'orchestrazione, ma nessun sistema multi-agente in produzione sopravvive senza di esso.

Come si presenta in un caso reale

Un setup recente che abbiamo costruito ha sostituito un agente di ricerca a singolo prompt con una forma orchestrator-worker per competitive intelligence su aziende private. La versione a singolo prompt faceva una sola chiamata a Claude, restituiva un paragrafo e mancava circa la metà del segnale rilevante. La versione multi-agente usa un orchestratore (Sonnet 4) che scompone una query azienda in quattro tracce di ricerca parallele (funding, prodotto, leadership, hiring). Ogni traccia è un worker (Sonnet 4) con il proprio strumento di ricerca e uno schema di output rigido. L'orchestratore cuce i quattro artefatti in un brief.

Il prima e dopo: la profondità di ricerca è circa triplicata, la latenza è passata da 6 secondi a 22 secondi, il costo in token è salito di 11 volte. Per un sales team che prima spendeva 40 minuti per azienda in ricerca manuale, lo scambio era facile. Per un chatbot consumer sarebbe stato rovinoso. Il pattern funziona solo quando i conti tornano.

Scegli il framework dopo aver scelto il pattern

La maggior parte dei team inverte l'ordine. Sceglie LangGraph o CrewAI prima, poi piega il problema per matcharlo. L'ordine onesto è: nomina il pattern (orchestrator-worker, pipeline, fan-out, coreografia, tiering), poi scegli il framework che esprime quel pattern con la minor cerimonia.

Per state machine a forma di grafo con cicli espliciti, branching e requisiti di observability di produzione, LangGraph resta la scelta più battle-tested nel 2026. Per crew basate su ruoli con flusso lineare e budget da prototipo in un giorno, la modalità Flows di CrewAI è ora accettabile in produzione. AutoGen è di fatto in maintenance mode mentre Microsoft consolida attorno al suo Agent Framework più ampio, quindi prendilo solo se il dibattito conversazionale è genuinamente la tua primitiva.

Il pattern che sopravvive in produzione è quello che matcha il problema. Il framework viene dopo quella decisione, mai prima.