Prima di disegnare il diagramma, fai il conto. La differenza fra un singolo agente ben istruito e una flotta coordinata non è quasi mai la qualità del disegno: è il rapporto fra il valore del compito e i token che brucia. La raccomandazione è netta — “Start with the simplest approach that works, and add complexity only when evidence supports it” — e arriva accompagnata da un’osservazione sul campo che vale più di molte architetture: “We’ve seen teams invest months building elaborate multi-agent architectures only to discover that improved prompting on a single agent achieved equivalent results.”

Che cosa fa davvero il coordinatore

Il pattern ha un nome preciso e una descrizione altrettanto precisa: “One agent acts as a team lead that plans work, delegates tasks, and synthesizes results.” Il sistema di ricerca di Anthropic è costruito esattamente così: “Our Research system uses a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.”

Sui Managed Agents l’isolamento non è una convenzione ma infrastruttura. Tutti gli agenti condividono sandbox, filesystem e credenziali del vault, ma “each agent runs in its own session thread, a context-isolated event stream with its own conversation history”. Il coordinatore riporta la propria attività nel primary thread; i thread aggiuntivi nascono a runtime quando delega. Due proprietà cambiano il modo di progettare: i thread sono persistenti — “the coordinator can send a follow-up to an agent it called earlier, and that agent retains everything from its previous turns” — e la configurazione non si propaga, perché “Tools, MCP servers, and context are not shared”.

Il roster si dichiara nel campo multiagent alla creazione del coordinatore, e accetta riferimenti per ID, riferimenti pinnati a una versione, copie di sé stesso e un advisor:

{
  "multiagent": {
    "type": "coordinator",
    "agents": [
      { "type": "agent", "id": "AGENT_ID" },
      { "type": "agent", "id": "AGENT_ID", "version": 3 },
      { "type": "self" }
    ]
  }
}

Il roster viene fotografato alla creazione: “Referenced agents stay pinned to the versions resolved at that time and do not automatically pick up later updates to their definitions.” Se aggiorni un worker e ti aspetti che il coordinatore lo usi, resti deluso finché non aggiorni anche il coordinatore.

Il conto in token

È qui che la decisione si fa. La misura riportata: “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.” Con stima più conservativa a parità di compito: “Multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks.” L’overhead nasce da contesto duplicato, messaggi di coordinamento e sintesi dei risultati.

Dall’altra parte del bilancio c’è il guadagno, non piccolo: “a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%.” Nota la composizione — lead più capace, worker più economici — perché è il modo in cui quel 15× diventa sostenibile.

Tre situazioni giustificano la complessità: protezione del contesto quando informazione irrilevante si accumula e degrada il ragionamento, parallelizzazione di percorsi indipendenti, e specializzazione quando domini diversi vogliono toolset o comportamenti in conflitto. Se il tuo caso non è uno di questi, stai pagando 15× per un riassunto.

Decomporre per contesto, non per fasi

L’errore ricorrente è tagliare il problema come lo racconteresti a un collega: fase uno, fase due, fase tre, un agente ciascuna. È il modo peggiore. La decomposizione va fatta per requisiti di contesto: spezzare fasi sequenziali dello stesso compito in agenti separati produce il gioco del telefono, con costo di coordinamento e perdita di informazione a ogni passaggio.

E la delega va scritta, non accennata. La lezione operativa del sistema di ricerca: “Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information.” Un coordinatore che dice «indaga sull’autenticazione» a tre worker ottiene tre volte la stessa indagine.

I modi in cui si rompe

Il fallimento strutturale del pattern è il coordinatore stesso, che diventa un collo di bottiglia informativo quando i subagent avrebbero bisogno di parlarsi fra loro. Se scopri che il lead passa il tempo a inoltrare messaggi fra worker, il pattern giusto non è più questo: valuta uno schema a stato condiviso, dove gli agenti leggono e scrivono su un database o un filesystem comune, sapendo però che lì “Agents may duplicate work” e i cicli reattivi possono bruciare token senza convergere.

Ci sono infine limiti duri da conoscere prima di disegnare gerarchie profonde. La delega è a un solo livello: “The coordinator can only delegate to one level of agents; referencing an agent that has its own multiagent.agents roster fails the create or update request with a validation error.” Il roster ammette al massimo 20 agenti unici, ma il coordinatore può chiamare più copie di ciascuno. La concorrenza è limitata a 25 thread. E il budget non è per agente: “A session budget is a single shared cap across all of a session’s threads. As the cap is reached, threads pause independently, and each thread’s cost is priced at the thread’s own served model.” Un worker vorace mette in pausa i colleghi.