Multi-agent batte single-agent: il dogma del 2026 regge?

C'è un modo preciso di dire "multi-agent" in una riunione tecnica. Lo dici e cambia l'aria. Suona da architetto, non da idraulico. Dici "ho un agente che lavora bene" e sembri uno che si arrangia; dici "ho un'orchestrazione multi-agente" e sembri uno che ha capito dove va il futuro. La parola fa status. Ed è proprio questo il problema.

Perché il dogma del 2026 — "i sistemi multi-agente superano il single-agent, sono più sofisticati, sono il futuro" — è vero a metà. Ed è la metà sbagliata ad aver vinto la narrazione. Il multi-agent vince in modo netto e documentato in un dominio: la ricerca. Nel coding, dove le sottoparti si coordinano di continuo attraverso scritture condivise, quasi tutto il guadagno reale viene ancora da un singolo agente ben orchestrato.

La domanda giusta non è "quanti agenti". È "dove serve davvero la parallelizzazione, e dove è solo costo e coordinamento fragile". Vediamo i numeri, perché qui i numeri ci sono e parlano chiaro.

Da dove viene il dogma

Tre forze alimentano il dogma. Nessuna delle tre è "il multi-agent scrive codice migliore".

La prima è lo status. "Multi-agent orchestration" è vocabolario che segnala competenza. La narrazione 2026 tratta il passaggio da single a multi come un "genuine architectural change", e il framing stesso suggerisce un progresso lineare: più agenti, più avanti. È seducente perché premia chi lo adotta con un'aura di sofisticazione, prima ancora di qualsiasi risultato misurato.

La seconda è l'incentivo di mercato. I framework di orchestrazione — LangGraph, CrewAI, AutoGen — vendono esattamente lo swarm di agenti. È il loro prodotto. Lo "standard 2026" viene raccontato come convergenza di protocolli (MCP, agent-to-agent, AGENTS.md), un ecosistema che ha un interesse strutturale a normalizzare il multi-agent come default. Non è complotto, è economia: chi vende orchestrazione racconta il mondo come un posto che ha bisogno di orchestrazione.

La terza, la più insidiosa, è la confusione tra ricerca e coding. Il dato che ha lanciato il dogma è il famoso +90,2% di Anthropic: un sistema multi-agente che batte il single-agent di novanta punti. Quel numero viene citato ovunque come prova generale di superiorità. Solo che è un risultato su research eval — task di ricerca — non di coding. E la fonte stessa, Anthropic, dice il contrario quando si parla di scrivere codice.

L'evidenza che lo smonta (a partire da Anthropic)

Partiamo dalla fonte primaria del +90,2%, il post di ingegneria di Anthropic sul loro sistema di ricerca multi-agente. È lì che nasce il numero, ed è lì che si trova il disclaimer che quasi nessuno cita.

Nello stesso documento Anthropic scrive nero su bianco:

"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"

La maggior parte dei task di coding ha meno parti davvero parallelizzabili della ricerca, e gli agenti non sono ancora bravi a coordinarsi in tempo reale. Il +90,2% non è un argomento per il multi-agent nel coding. È un argomento per il multi-agent nella ricerca, con un avvertimento esplicito che il coding è un altro mestiere.

Due numeri dallo stesso documento aiutano a capire il prezzo. Il primo: i sistemi multi-agente usano circa 15 volte più token di una chat normale. Il secondo, ancora più rivelatore: "token usage by itself explains 80% of the variance" — l'uso di token, da solo, spiega l'80% della varianza nei risultati. Tradotto: gran parte del vantaggio multi-agente non è "più intelligenza", è "più token spesi a esplorare in parallelo". Funziona quando il task è esplorazione parallela. Quando non lo è, hai pagato 15× per niente.

Ed è qui che arriva il dato perno, quello che taglia il dogma a metà. Confronti su famiglie di task diverse mostrano che il guadagno del multi-agent non è una costante: cambia segno a seconda della natura del task.

Tipo di task	Effetto del multi-agent
Parallelizzabile (sottoparti indipendenti)	+81% vs single-agent
Sequenziale (sottoparti dipendenti)	fino a -70% di degradazione

Non "multi-agent è meglio". "Multi-agent è meglio solo se il task è genuinamente parallelo". E l'editing coordinato di codice — più file con dipendenze, una decisione di design che si propaga, un refactor che attraversa moduli — è prevalentemente sequenziale. Cade nel caso peggiore della tabella, non nel migliore.

(Una nota di onestà: i confronti per tipo di task vengono da benchmark comunitari, non da uno studio peer-reviewed unico, e i nomi esatti dei benchmark vanno presi con cautela. Il pattern direzionale, però, è coerente con tutto il resto — Anthropic e Cognition incluse.)

Il giro completo di Cognition

Se Anthropic dà il numero, Cognition dà la storia. Ed è una storia che vale la pena seguire perché è un'inversione a U pubblica, fatta da chi costruisce agenti di coding per mestiere.

A dicembre 2025, Walden Yan (co-founder di Cognition) pubblica un post dal titolo che è già una tesi: "Don't Build Multi-Agents". L'esempio che usa è diventato un piccolo classico. Due sub-agenti devono clonare Flappy Bird in parallelo, senza condividere il contesto pieno. Uno produce uno sfondo in stile Super Mario, l'altro un'animazione del personaggio incompatibile con quello sfondo. L'agente finale si ritrova a dover riconciliare una "miscommunication" che non esisterebbe se un solo agente avesse tenuto in testa l'intera decisione visiva.

I due principi di Yan:

"Share context, and share full agent traces, not just individual messages."
"Actions carry implicit decisions, and conflicting decisions carry bad results."

Ogni azione porta con sé decisioni implicite, e decisioni in conflitto producono risultati rotti. La conclusione del post è secca: far girare più agenti in collaborazione produce solo sistemi fragili, perché il decision-making finisce per essere troppo disperso.

Ad aprile 2026 Cognition torna sul tema con "Multi-Agents: What's Actually Working". Non una ritrattazione: una precisazione. Il multi-agent funziona — ma in una forma molto diversa dallo swarm del dogma. Le scritture restano single-threaded: un solo agente scrive. Gli agenti aggiuntivi contribuiscono intelligenza, non azioni. E la maggior parte dei setup in produzione si riduce a subagent read-only — web search, code search, lettura della codebase — che funzionano come una tool call, non come scrittori paralleli.

Il giro completo di Cognition è la sintesi migliore della tesi: non "il multi-agent non serve", ma "il multi-agent serve a portare giudizio nel loop, non a far scrivere lo stesso file a più mani".

Il caso che sembra contraddire (e invece conferma)

C'è un risultato che a prima vista sembra rilanciare il dogma, e che invece, letto bene, lo inchioda. È un paper di dicembre 2025 (arXiv 2511.16708) sulla verifica multi-agente del codice.

Il numero è grosso: una verifica parallela e indipendente porta l'accuratezza su SWE-Bench da 32,8% a 72,4% — quasi quaranta punti di guadagno. Sembra la prova definitiva che "più agenti = più bravi a fare codice".

Ma guarda cosa fanno gli agenti. Non scrivono in parallelo. Verificano in parallelo. Più verificatori indipendenti esaminano lo stesso candidato di soluzione e, mettendo insieme i loro giudizi indipendenti, separano molto meglio le soluzioni buone da quelle rotte. È review concorrente, non scrittura concorrente.

È esattamente la tesi, dichiarata in un altro modo: gli agenti aggiuntivi contribuiscono giudizio, non azioni. La parallelizzazione vince dove le sottoparti sono indipendenti per natura — e due verifiche dello stesso codice sono indipendenti, mentre due scritture dello stesso file no. Lo stesso paper che sembra il trofeo del multi-agent è, a leggerlo, il manifesto del read-only.

Il pattern che funziona: write single-threaded + advisory

Mettendo insieme Anthropic e Cognition, il pattern operativo del 2026 converge su una forma sola. Vale la pena enunciarla esplicitamente perché è semplice e robusta.

Un solo agente scrive. Gli altri contribuiscono intelligenza. È l'orchestrator-worker con scritture single-threaded. Il main tiene lo stato, prende le decisioni di design, edita i file. I sub-agenti gli portano contesto e giudizio.

I sub-agenti sono read-only / advisory. Cercano sul web, scandagliano la codebase, leggono documentazione, fanno review. Non toccano il filesystem condiviso. Funzionano come strumenti del main, non come colleghi che scrivono nello stesso branch.

E tornano sintesi, non transcript. Questo è un dettaglio che pesa più di quanto sembri: se un sub-agente ti restituisce l'intero suo transcript, inquini il context window dell'orchestratore e bruci token a ogni chiamata successiva. La sintesi tiene il main lucido. Il transcript lo annega — ed è proprio sulla gestione del contesto delle run lunghe che si gioca buona parte dell'autonomia, come ho argomentato in Memoria degli agenti: stato dell'arte.

Del quando dividere e quando no — con i conti, i casi limite, i costi di un loop multi-agente lasciato correre — ho scritto in dettaglio in Subagents: quando dividere e quando no. Qui il punto è più affilato: non quando dividere, ma perché il dogma di superiorità è mal posto. La forma che regge non è lo swarm. È un main che scrive, con satelliti che osservano.

git worktree: il parallelismo vero (di processo, non di swarm)

Qui c'è una distinzione che il dogma fa sparire, e che invece è il cuore della questione pratica.

C'è un modo reale di parallelizzare il coding, e si usa tutti i giorni: git worktree. Apri più worktree dallo stesso repo, ciascuno su un branch separato, e fai girare un'istanza di Claude Code per worktree. Ogni istanza ha il suo filesystem, il suo contesto, il suo task. Zero interferenza. Anthropic ha aggiunto supporto nativo (--worktree, isolation: worktree nel frontmatter del subagent) proprio per questo.

Ma attenzione a cosa è e cosa non è. Il git worktree non è il multi-agent del dogma. È parallelismo a livello di processo, su task indipendenti. Tre agenti che lavorano su tre feature scollegate, ognuno nel proprio mondo, sono tre processi paralleli — non uno swarm coordinato che si scambia messaggi per scrivere lo stesso output.

La differenza è tutta nel coordinamento. I worktree funzionano perché non si coordinano: ognuno fa la sua cosa e si rivedono al merge. Lo swarm fallisce perché deve coordinarsi di continuo per scrivere insieme. E il limite onesto del worktree lo conferma per contrasto: se due worktree toccano lo stesso file, il conflitto torna — e torna esattamente dove va gestito, al merge, con gli strumenti di sempre. Non è magia di orchestrazione. È git che fa il suo lavoro.

Quando senti dire "parallelizzo con gli agenti", chiedi quale dei due. Worktree su task indipendenti: ottimo. Swarm che si coordina per editare lo stesso codice: è lì che nasce Flappy Bird.

Quando il multi-agent è giusto (per davvero)

Smontare il dogma non significa cadere nel cinismo opposto. Il multi-agent non è teatro vuoto: è un pattern potente, applicato spesso fuori dal suo dominio. Ci sono tre casi in cui vince in modo documentato, e vale la pena nominarli con precisione.

Task genuinamente paralleli e indipendenti. Ricerca multi-fonte, scansione di codebase ampie, generazione di varianti da confrontare. È il dominio del +90,2% di Anthropic e del +81% sui task parallelizzabili. Quando le sottoparti non si devono parlare, dividerle è puro guadagno.

Isolamento del contesto. Un sub-agente "sporco" che esplora, cerca, prova strade — senza inquinare il context del main con tutto il rumore della ricerca. Il beneficio è doppio: gestisci più contesto totale, e il main resta lucido. È il caso d'uso più sottovalutato e più solido.

Review e verifica adversariale. È il caso del paper sulla verifica (da 32,8% a 72,4%), ed è anche il caso del red teaming. Un agente che attacca il codice di un altro è multi-agent legittimo per definizione: contribuisce intelligenza adversariale, non scritture concorrenti. Ne ho scritto in Red teaming dell'agentic coding — l'attaccante è un agente separato proprio perché deve avere un obiettivo opposto, non perché deve "fare più cose insieme".

Il filo comune dei tre casi: l'agente aggiuntivo porta giudizio o esplorazione indipendente, mai scrittura condivisa coordinata. Tieni questo filo e capisci al volo se un'architettura multi-agente ha senso o è status.

Cosa farsene oggi

Tradotto in pratica per chi lavora con Claude Code, sono cinque regole.

Default: un main che scrive. Parti single-agent ben orchestrato. Aggiungi agenti solo quando puoi indicare un task parallelo davvero indipendente. Il multi-agent non è il punto di partenza, è un'ottimizzazione che ti devi guadagnare.

Sub-agent advisory, mai write-paralleli. Usali per ricerca, code search, review. Falli tornare con sintesi, non con transcript. Il sub-agente è uno strumento del main, non un secondo paio di mani sullo stesso file.

Per parallelismo vero, git worktree. claude --worktree o isolation: worktree, un'istanza per task indipendente su branch separati. È il modo onesto di andare in parallelo nel coding, e non chiede nessuna orchestrazione fragile.

Conta il costo prima di spawnare. Multi-agent significa più token (fino a ~15× nella ricerca), più latenza di coordinamento, debug più difficile. Spawni solo se il valore del task supera questo costo. La domanda non è "posso dividerlo", è "mi conviene dividerlo".

La regola d'oro, da appendere al muro: se due agenti devono coordinarsi tanto per scrivere lo stesso output, non dividerli. Il coordinamento per scritture condivise è precisamente il punto dove nasce la fragilità. Lì il single-agent non è un ripiego: è la scelta giusta.

La riga finale

Il multi-agent non è hype e non è truffa. È un pattern eccellente, preso da un dominio in cui funziona — la ricerca, l'esplorazione, la verifica — e spalmato su un dominio in cui spesso non funziona: l'editing coordinato del codice. Il dogma ha vinto perché suona avanzato, perché qualcuno lo vende, e perché un numero della ricerca è finito a far da bandiera al coding.

I numeri, letti dove vanno letti, dicono una cosa sola: più agenti non significa più intelligenza. Significa più token e più coordinamento — che pagano quando il task è parallelo, e ti puniscono fino a -70% quando non lo è. Ieri ho stress-testato il report Anthropic che incorona il multi-agent come trend dominante; questa è la stessa lama, affilata sul dogma di superiorità.

La prossima volta che ti viene da dire "multi-agent", fermati un secondo. Chiediti se il task è davvero parallelo, o se stai solo cercando di sembrare un architetto. La risposta onesta, sul coding, quasi sempre è: un agente che scrive bene, con qualche satellite che lo aiuta a vedere. Non è meno sofisticato. È solo vero.

Fonti: