Il multi-agente è la decisione architetturale più facile da vendere e più difficile da giustificare. Chi la propone deve saper dire, con numeri, che cosa compra e a che prezzo — perché il prezzo è documentato e non è piccolo.

Le tre ragioni buone per aggiungere un secondo agente

La documentazione ne riconosce tre. La prima è la protezione del contesto: «When an agent’s context accumulates information from one subtask that is irrelevant to subsequent subtasks, context pollution occurs.» La seconda è la parallelizzazione: «Running multiple agents in parallel allows you to explore a larger search space than a single agent can cover.» La terza è la specializzazione, cioè strumenti, prompt di sistema o competenze di dominio che sommati sovraccaricherebbero un generalista.

Il sistema di ricerca multi-agente di Anthropic aggiunge il profilo di compito che ne trae vantaggio: «Multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools.» E indica il rovescio con altrettanta chiarezza: «Most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.»

Il conto che va messo sul tavolo

Due fonti danno due numeri, con due basi di confronto diverse: vanno citati separatamente, non sommati. Il primo confronta multi-agente e agente singolo: «Multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks.» Il secondo prende come base la chat: «Agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.»

Al costo in token si aggiunge quello in affidabilità: «multi-agent systems introduce overhead. Every additional agent represents another potential point of failure, another set of prompts to maintain, and another source of unexpected behavior.» Per questo la raccomandazione è partire dall’agente singolo e salire solo quando una delle tre ragioni sopra si presenta davvero.

Come si taglia il lavoro

Qui sta l’errore più comune, e la documentazione lo nomina: dividere per tipo di attività (uno che pianifica, uno che testa, uno che rivede) invece che per confine di contesto. Il criterio corretto è l’opposto: «Dividing by context boundaries means an agent handling a feature should also handle its tests, because it already possesses the necessary context.» Si raggruppa il lavoro per il contesto che richiede, non per il mestiere che rappresenta.

L’eccezione utile è proprio quella verifica che sembrerebbe un ruolo: lo schema multi-agente più costantemente efficace è «a dedicated agent whose sole responsibility is testing or validating the main agent’s work», perché un valutatore che non ha scritto la soluzione non ne eredita gli assunti.

Cinque schemi di coordinamento e i loro modi di rompersi

generator-verifier   un generatore produce, un verificatore valuta e rimanda indietro
orchestrator-subagent un agente pianifica, delega e sintetizza i risultati
agent teams          un coordinatore avvia processi indipendenti e persistenti
message bus          gli agenti pubblicano e si iscrivono a topic, un router smista
shared state         gli agenti leggono e scrivono su un archivio condiviso

Ogni schema porta il proprio guasto tipico. Il generator-verifier degenera nel timbro automatico quando i criteri non sono espliciti, e nel ciclo infinito senza un limite di convergenza. L’orchestrator-subagent crea un collo di bottiglia informativo: i dettagli critici si perdono nei passaggi di consegna. Nelle squadre di agenti «agents may duplicate work or pursue contradictory approaches». Il message bus produce guasti silenziosi quando un evento viene instradato male, e il debug è difficile perché si propaga lungo cascate di eventi. Lo stato condiviso genera cicli reattivi che bruciano token senza convergere, e richiede condizioni di terminazione esplicite.

Che cosa la piattaforma dà già, e i suoi vincoli

Sulla Managed Agents API l’orchestrazione è un servizio: tutti gli agenti condividono sandbox, filesystem e credenziali del vault, ma ognuno gira in un proprio session thread, un flusso di eventi con isolamento di contesto e storia propria; «Tools, MCP servers, and context are not shared». I thread sono persistenti, quindi il coordinatore può tornare su un agente già interpellato. Il vincolo operativo da conoscere è dichiarato: «A maximum of 25 concurrent threads is supported.»

Su Claude Code, la distinzione fra subagent e agent team è una scelta di architettura, non di comodità: i subagent riportano un risultato al chiamante e costano meno perché il risultato torna riassunto; i teammate si messaggiano fra loro e costano di più perché ognuno è un’istanza separata. La documentazione avverte che «Agent teams add coordination overhead and use significantly more tokens than a single session», e per compiti sequenziali, modifiche allo stesso file o lavoro con molte dipendenze indica che «a single session or subagents are more effective». Due vincoli vanno detti prima di disegnarci sopra un’architettura: le agent team sono «experimental and disabled by default», e non sono annidabili — i teammate non possono avviare propri teammate, solo il lead gestisce la squadra.