Subagents: quando dividere e quando no

Un team enterprise lascia in esecuzione, non supervisionata, una pipeline con 23 subagent. Tre giorni dopo riceve la fattura: 47.000 dollari. Un altro caso pubblico, più piccolo: 49 subagent in parallelo per due ore e mezza con uno slash command /typescript-checks partito un po' troppo allegro, conto tra 8.000 e 15.000 dollari in una singola sessione. Sono numeri documentati, non aneddoti da bar.

Eppure in giro continua a girare la stessa frase: "Apriamo un subagent per questo, uno per quello, tanto sono parallelizzabili." È diventato un riflesso, come se la divisione fosse gratis. Non lo è — e non solo in termini di token. Ogni subagent è un context window separato, un bootstrap di alcune migliaia di token prima ancora che faccia qualcosa, e un punto in cui il coordinamento può rompersi in modi sottili.

Il problema è che la community sta ancora imparando dove sta il limite. Il dibattito pubblico tra Anthropic — che ha pubblicato un post entusiasta sul proprio sistema multi-agent — e Cognition, che ha risposto con un secco "Don't Build Multi-Agents", non è una baruffa accademica. È la spia che i due campi stanno guardando due domini diversi, e in entrambi hanno ragione. Da come distingui i due domini dipende se i subagent ti fanno volare o ti svuotano l'API budget.

Cosa è davvero un subagent

Prima di parlare di quando usarli, è utile essere precisi su cosa sono. In Claude Code un subagent è un agent figlio invocato tramite il Task tool: riceve un prompt, ha un suo context window separato, può avere un proprio set di tool ammessi, e quando finisce ritorna al parent una risposta sintetica. Il parent non vede tutto quello che il subagent ha fatto — vede il riassunto.

Questo è il punto chiave operativo, ed è anche la fonte della maggior parte dei problemi: isolamento del contesto. Il subagent non sa cosa hai discusso col main, salvo quello che gli passi nel prompt. Il main non sa come ha ragionato il subagent, salvo quello che il subagent gli restituisce.

Cinque subagent built-in oggi in Claude Code: Explore, Plan, general-purpose, statusline-setup, Claude Code Guide. Si possono creare custom via UI /agents o con file Markdown e frontmatter YAML (scope, descrizione, lista tool, permission mode, prompt di sistema). Stessa logica nell'Agent SDK di Anthropic.

Il costo nudo: bootstrap di un subagent 5.000-15.000 token prima ancora di fare qualcosa, verifica tool access altri 2.000-8.000 token, mantenimento contesto 500-2.000 token al minuto per agent attivo. Sommato, un workflow subagent-heavy si ritrova con +200-500% di overhead rispetto allo stesso task fatto single-thread. Non è un dettaglio di bolletta: è un fattore moltiplicativo.

Il dibattito: Anthropic dice sì, Cognition dice no

Giugno 2025, Anthropic pubblica "How we built our multi-agent research system". Il numero che gira ovunque è +90,2% di performance del sistema multi-agent (Claude Opus 4 lead + Sonnet 4 subagents) contro Claude Opus 4 singolo, sulle valutazioni interne di task di ricerca. Insieme al numero arriva una dichiarazione che è stata letta come una benedizione generale: "token usage by itself explains 80% of the variance" nel successo dei task. Più token = più ricerca parallela = miglior risultato.

Lo stesso post, però, contiene una frase che chi lo cita di solito salta:

"Some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For example, most coding tasks involve fewer truly parallelizable tasks than research."

Pochi giorni dopo, Walden Yan di Cognition pubblica "Don't Build Multi-Agents". La tesi è opposta in apparenza, e forte: "Share context, and share full agent traces, not just individual messages." L'esempio canonico è il clone di Flappy Bird: un subagent costruisce uno sfondo stile Super Mario, un altro un uccello con asset visivi incompatibili. L'agente finale deve riconciliare due pezzi che non parlano la stessa lingua, e fallisce. "Actions carry implicit decisions, and conflicting decisions carry bad results."

Letto in superficie sembra una contraddizione. Letto bene non lo è: Anthropic parla di ricerca breadth-first, Cognition parla di coding agent. Sono due profili di task radicalmente diversi. La ricerca su fonti indipendenti è genuinamente parallelizzabile; il coding cross-file con stato condiviso non lo è quasi mai. Il +90,2% di Anthropic è reale per il loro caso d'uso. Il don't build di Cognition è reale per il loro. Hanno ragione entrambi sul proprio dominio.

Il problema nasce quando uno dei due framing viene applicato senza pensare al dominio dell'altro. È così che si arrivano a spawnare 49 subagent per un check TypeScript.

Quando aiutano davvero

I tre casi in cui un subagent paga il proprio costo sono identificabili in modo abbastanza netto. Almeno una di queste tre condizioni deve esistere — se non ne vale nemmeno una, single agent.

Ricerca parallela su fonti indipendenti. Cinque query diverse su cinque fonti diverse, zero stato condiviso. Il context principale resta pulito; i subagent ritornano sintesi compatte. È il caso d'uso canonico del post Anthropic e funziona perché il task è naturalmente breadth-first. Connesso al pattern del MoE: attivi pochi esperti su pochi pezzi, non tutti su tutto.

Code review multi-prospettiva con isolamento di tool. Un subagent style-checker con permessi read + grep, uno security-scanner read-only, uno test-coverage con bash limitato. Girano in parallelo perché analizzano lo stesso codice da angoli diversi senza scriverlo. Niente conflitti di scrittura, niente decisioni implicite contraddittorie. È l'esempio classico della doc Agent SDK.

Esplorazione di codebase grande prima di un cambio. Un subagent Explore che inghiotte cinquanta file e ritorna una mappa, mentre il main resta libero per pianificare. Senza subagent il main si riempirebbe di output che non userà più — context inquinato, attenzione diluita. Qui il valore è l'isolamento del contesto, non la parallelizzazione.

C'è un quarto caso che vale la pena nominare separatamente: task con permission boundary. Un subagent read-only su dati sensibili, uno con scrittura limitata a /tmp. L'isolamento dei permessi ha valore in sé, indipendentemente dal parallelismo.

Quando sono overhead

Speculare ai casi sopra, ce ne sono altrettanti in cui il subagent è una pessima idea — e sono i casi che bruciano i budget.

Refactor incrementale cross-file con stato condiviso. Cambi una signature di funzione, devi propagare in dodici file con dipendenze. Spawnare un subagent per file significa avere dodici context separati che non sanno cosa hanno deciso gli altri. È lo scenario Flappy Bird scalato: ogni subagent prende decisioni implicite (rinomina un parametro, inferisce un tipo, modifica un import) che gli altri non vedono. Il merge finale è uno spaghetto. Single agent, sequenziale, con un buon piano.

Task piccoli, sotto i 10k token di lavoro reale. Il bootstrap del subagent (5-15k) costa più del beneficio. Regola pratica spiccia: se il task entra comodamente nel context principale e l'output ti servirà ancora dopo, non spawnarlo.

Pipeline con feedback loop continuo. Se il passo N ha bisogno di vedere come ha ragionato il passo N-1 — non solo il suo risultato — la traccia condivisa batte l'isolamento. È il punto di Cognition sul coding. Connesso a quello che Wiener scriveva nel 1948: senza feedback non c'è controllo. Multi-agent senza shared trace rompe il loop.

Coordinamento come problema centrale. Se la parte difficile è "decidere chi fa cosa e in che ordine", aggiungere agent peggiora. È meta-lavoro: stai dedicando token a coordinare invece che a risolvere. Anthropic stessa, nel proprio post, lista tra gli errori dei loro early agent: spawn di 50 subagent per una query semplice, ricerche infinite per fonti che non esistevano, duplicazione del lavoro (subagent diversi che fanno la stessa identica ricerca).

Caso reale: la pipeline editoriale di questo blog

Per concretizzare. Agent Coding Italia ha una pipeline editoriale che gira più volte a settimana. I passi sono, in ordine:

Research: cerca fonti, verifica URL, raccoglie citazioni in un file _research/<slug>.md.
Writing: scrive l'articolo a partire dal research file.
Cover image: genera la cover via script Python (OpenAI gpt-image-1 o ComfyUI).
Fact-check finale: rilegge l'articolo contro il research, segnala incoerenze.
Social copy: genera post LinkedIn/X dall'articolo finito.
Deploy e pubblicazione.

Quali di questi traggono beneficio da un subagent dedicato? 1, 4 e 5. Il research è classico parallelismo su fonti indipendenti, e produce un volume di output che non voglio nel context del main (link, snippet, pagine intere). Il fact-check è una lettura a freddo, da una prospettiva diversa, idealmente con permessi read-only — isolamento sia di contesto sia di tool. Il social copy è indipendente dal fact-check e parallelizzabile con esso: due subagent che lavorano sullo stesso input ma producono output indipendenti.

Quali invece non devono essere subagent? 2 e 3. Il writing è single-thread per definizione: un articolo coerente nasce da un filo continuo, non da pezzi cuciti. Spawnare un subagent per ogni sezione è il modo migliore per produrre articoli che cambiano tono ogni due paragrafi. La cover è una call a uno script, non un agent task — non c'è ragionamento da delegare, è una funzione.

Se spawnassi cinque subagent per ogni articolo "perché tanto sono parallelizzabili" otterrei l'esperienza tipica del multi-agent overkill: cover che non c'entra col contenuto, social che parla di un'angolazione diversa dall'articolo, fact-check di una versione vecchia perché il main aveva nel frattempo riscritto l'intro. Esattamente il caso Flappy Bird, in salsa editoriale.

La regola pratica

Distillata dai casi visti, dalla doc ufficiale, e dalle storie horror della community, la regola operativa è breve. Usa un subagent se e solo se vale almeno una di queste tre condizioni:

Il context del main verrebbe inquinato da output che non ti servirà più (search dump, log, contenuto di file letti per scoprire qualcosa).
I sotto-task sono genuinamente indipendenti e parallelizzabili — zero stato condiviso, zero decisioni implicite che entrano in conflitto.
Ti serve isolamento di permessi o di tool (read-only, sandbox, scope ristretto).

Se nessuna delle tre vale, single agent. Sempre. Nove volte su dieci un prompt migliore e un set di tool migliore risolvono il problema senza il costo del coordinamento. La domanda diagnostica più efficace è anche la più brutale: "se questi subagent dovessero coordinarsi tanto, perché li sto dividendo?" Se la risposta è "per andare più veloce", probabilmente stai per pagare la velocità con l'incoerenza. Se la risposta è "perché lavorano su pezzi che non si parlano", allora sì, dividili.

C'è un parallelo con un altro pezzo che ho scritto qui sul blog, sulla fine del più grande è meglio: più subagent non è meglio, esattamente come più parametri non è meglio. Il vincolo è il fit col problema, non la scala. La cibernetica di Wiener lo aveva già detto in altri termini quasi ottant'anni fa: la varietà del controllore deve essere adeguata alla varietà del sistema controllato — non superiore. Sovradimensionare costa.

Subagent come strumento, non come pattern di default

Il pattern "spawno per default, parallelizzo tutto" nasce dal mix di hype e di un'idea seducente: "se 1 agent funziona, N agent funzioneranno N volte meglio". Non è così, e i 47.000 dollari in tre giorni di un team enterprise lo dimostrano in modo abbastanza eloquente. Il numero +90,2% di Anthropic è reale, ma vale per ricerca breadth-first con fonti indipendenti — non per refactor cross-file, non per coding agent, non per qualunque task di default. Cognition ha ragione sul coding tanto quanto Anthropic ha ragione sulla ricerca.

Per chi sviluppa oggi, due take operativi. Primo: prima di trasformare un workflow in multi-agent, prova a riscrivere il prompt e a dare al main agent tool migliori. Nel 90% dei casi è la soluzione, e costa zero. Secondo: se decidi che il subagent serve davvero, scrivi esplicitamente nel suo prompt cosa deve restituire al main e in che formato, e tieni piccolo il numero (due o tre, non cinquanta). Il bottleneck dei sistemi multi-agent ben fatti non è la potenza dei subagent — è la qualità del contratto tra loro.

Il subagent è uno strumento. Buono per certi task, pessimo per altri, costoso sempre. Trattarlo come un riflesso ("apriamo un subagent per...") è la versione moderna del premature optimization: introduci complessità per risolvere un problema che spesso non hai. Trattarlo come una scelta — fatta caso per caso, con la regola delle tre condizioni in mente — è il modo per estrarne il valore vero senza pagare il conto sbagliato.

Fonti: