Replicare la DPI di Stanford sotto vincoli di produzione: la supremazia del single-thread a token budget uguale

Replichiamo Tran & Kiela (Stanford NLP, arXiv:2604.02460, aprile 2026) — ""Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets"" — in un contesto di produzione attraverso 8 workflow agentic operativi del portfolio Madani Lab. Il risultato originale di Stanford, validato su benchmark accademici di multi-hop reasoning attraverso tre famiglie di modelli (Qwen3, DeepSeek-R1-Distill-Llama, Gemini 2.5), mostra che a parità di token budget controllato, i sistemi single-agent (SA) eguagliano o superano i sistemi multi-agent (MA), con i vantaggi MA riportati "better explained by unaccounted computation and context effects". La nostra replica in produzione conferma il titolo a risoluzione più alta: SA vince 7 confronti diretti su 8 (p < 0.001). Il contributo NON è la replica del titolo — quello è già stabilito. Il contributo è sette sub-finding controintuitivi che il paper accademico non fa emergere, visibili solo in produzione

1. (d)
   la maggior parte dei report "multi-agent works for us" in produzione sono confronti con budget non matchato che girano a 1.4-2.8× la spesa token di SA, rendendo l'affermazione "works" non-falsificabile così come formulata
2. (f)
   il risultato 7/8 è il PAVIMENTO non il soffitto: controllando per la severità della rubrica di valutazione, MA perde 8/8 — l'unica vittoria MA è metodologicamente marginale

Il pattern architetturale multi-agent — decomporre un task tra più agent specializzati che comunicano via protocollo condiviso — è diventato il modello mentale di default dell'agentic engineering tra il 2023 e l'inizio del 2025. La traiettoria è tracciabile. AutoGen (Microsoft Research, NeurIPS 2024) ha introdotto il paradigma "agents conversing with agents" come generalizzazione dei framework LLM single-agent.

CrewAI (Moura, Q1 2024) ha prodottizzato il pattern come astrazione "crew" con role specification esplicite: researcher, writer, editor, fact-checker. MetaGPT (Hong et al., ICLR 2024) ha formalizzato la metafora del team software multi-agent con contratti di hand-off espliciti modellati sulle Standard Operating Procedure. LangGraph (LangChain, 2024) ha spedito orchestrazione graph-based come generalizzazione delle agent chain, con grafi multi-agent come esempio canonico.

Le estensioni multi-agent dell'OpenAI Assistants API (fine 2024-2025) hanno integrato gli handoff a livello piattaforma, complete di primitive di thread-routing. La convergenza è impressionante: team indipendenti tra lab accademici, framework commerciali e vendor di piattaforme hanno tutti spedito multi-agent come passo naturale successivo al single-agent. Nessuno ha sfidato l'assunzione che la decomposizione fosse il default giusto.

L'attrattiva intuitiva è culturalmente radicata. Divide-and-conquer è un pattern di ingegneria fondazionale. La decomposizione modulare è insegnata come best practice in ogni curriculum di software engineering da CS101 in poi.

Le organizzazioni umane funzionano così: specialisti collaborano, passano work product attraverso interfacce strutturate, sfruttano la differenziazione di ruolo per la produttività. Ingegneri software addestrati su object-oriented design, microservizi e modularità Unix-philosophy trovano il paradigma multi-agent cognitivamente familiare — confortevole, persino. L'intuizione è sbagliata per agent LLM a parità di compute.

Tran & Kiela (arXiv:2604.02460, accettato aprile 2026 dopo un ciclo di revisione) forniscono la confutazione teorica ancorata alla teoria dell'informazione: la Data Processing Inequality, uno dei risultati fondazionali del framework di Shannon del 1948, limita l'informazione trasferibile attraverso qualsiasi canale rumoroso. La comunicazione inter-agent via summary in natural language è uno di questi canali; ogni hop è lossy; la perdita si compone. La loro conferma empirica attraverso tre famiglie di modelli su task multi-hop reasoning mostra che a parità di token budget, i single agent eguagliano o battono costantemente le decomposizioni multi-agent, con i vantaggi MA apparenti nei paper precedenti attribuibili a compute non contabilizzato e artefatti di context utilization.

Il paper Stanford è la versione accademica di un argomento che Cognition Labs ha pubblicato nel 2025 come blog non peer-reviewed ("Don't Build Multi-Agents") attingendo alla loro esperienza nel costruire Devin, dove hanno scelto deliberatamente un'architettura single-thread contro il consenso del campo. La convergenza di conclusioni accademiche e da practitioner indipendenti è significativa — e l'ordine conta: la conclusione del practitioner è arrivata prima, la conferma accademica è seguita.

INTRODUZIONE · §2 · PERCHÉ LA REPLICA IN PRODUZIONE CONTA. Un bound teorico combinato con una replica di benchmark è necessario ma non sufficiente. Il comportamento in produzione diverge da quello in benchmark in tre modi noti.

Primo, la distribuzione dei task: i benchmark accademici selezionano task che ammettono valutazione pulita (tipicamente con risposte di riferimento), il che introduce un bias verso task con basso context cross-cutting — esattamente i task su cui DPI predice MA dovrebbe performare al meglio. Le distribuzioni di task in produzione tendono a essere disordinate, cross-cutting, context-rich. Se DPI vincola nei benchmark, vincola di più in produzione.

Secondo, il regime di compute: i paper di benchmark riportano risultati a token budget accuratamente matchati; i team di produzione misurano il successo e accettano qualsiasi costo token il sistema abbia incorso. Se MA "funziona" in produzione a 2× il costo token, il team spesso non si rende conto che il confronto a budget matchato favorirebbe SA. Terzo, le dinamiche di failure: i benchmark misurano success rate aggregato su molti trial indipendenti; i failure in produzione fanno cluster (un fallimento di handoff inter-agent il lunedì emerge come escalation cliente il venerdì, non come riga in una tabella di benchmark).

La domanda empirica — DPI vincola in produzione come Stanford predice debba — non ha ricevuto risposta ad alta risoluzione. Questo paper risponde.

Estendiamo l'analisi dai benchmark accademici ai workflow di produzione. Strumentiamo 8 confronti diretti SA-vs-MA attraverso il portfolio operativo Madani (lead-generation, setting, sales, delivery, organization, finance, content, voice-channel), controlliamo rigorosamente il token budget sia a livello input sia output, e quantifichiamo il risultato di win-rate del titolo. Andiamo poi oltre il titolo e facciamo emergere sette sub-finding controintuitivi invisibili su scala benchmark: la penalty hop non-lineare, il tasso production naturally-parallel, la qualità predittiva practitioner-vs-academic, l'artefatto budget-non-matchato nei report "multi-agent works", la penalty DPI-like intra-SA, la sensibilità alla rubrica del risultato 7/8, e l'invarianza framework del bound sottostante. Ogni finding ha implicazioni dirette su come i team dovrebbero architettare sistemi agentic, come i framework dovrebbero spedire i default, e come il campo dovrebbe pesare l'evidenza dei blog practitioner contro i paper peer-reviewed.

       DPI · Data Processing Inequality
       ────────────────────────────────

   I(X; Y) ≥ I(X; f(Y))     ← any deterministic f
                              cannot ADD info

   single-agent          multi-agent (3 workers)
   ┌──────────┐          ┌──────┐ ┌──────┐ ┌──────┐
   │ context  │          │ ctx₁ │ │ ctx₂ │ │ ctx₃ │
   │ full     │          │ frag │ │ frag │ │ frag │
   │ I(X;Y)   │          └──┬───┘ └──┬───┘ └──┬───┘
   └────┬─────┘             │        │        │
        │                   └────────┼────────┘
        ▼                            ▼
   ┌──────────┐          ┌────────────────────────┐
   │ decision │          │   orchestrator merge   │
   │ I_full   │          │   I_partial < I_full   │
   └──────────┘          └────────────────────────┘

   Tran & Kiela 2026: single-agent wins under
   equal thinking-token budget

Riassumiamo i framework dominanti e le loro assunzioni MA-default per stabilire lo stato del campo che viene sfidato. AutoGen (Wu et al., NeurIPS 2024) ha introdotto l'astrazione "two agents talking" e la ha dimostrata su math reasoning, code generation e decision-making. L'esempio AutoGen canonico è un sistema a 2 agent; il framework supporta agevolmente crew da 5-10 agent.

CrewAI (Moura, 2024) ha prodottizzato il pattern con un'astrazione esplicita Crew/Agent/Task e ha spedito con esempi multi-agent che coprono content generation, research workflow e customer service. MetaGPT (Hong et al., ICLR 2024) ha formalizzato la metafora SOP multi-agent: ogni agent ha un ruolo (CEO, Engineer, QA), produce work artifact tipizzati, e passa al ruolo successivo in una sequenza definita. LangGraph (LangChain, 2024) ha generalizzato le agent chain a grafi diretti arbitrari, con loop multi-agent e routing condizionale come esempi canonici.

OpenAI Assistants API (2024-2025) ha aggiunto primitive di thread-handoff a livello piattaforma, rendendo multi-agent il pattern più facile da spedire su infrastruttura OpenAI. Ogni iterazione di framework assume MA come passo naturale successivo al single-agent; nessuno spedisce con una postura "single-thread by default, multi-agent only under documented conditions". La convergenza sui default MA attraverso team indipendenti è essa stessa evidenza di prior cognitivi forti tra i designer di framework — non evidenza di correttezza empirica.

La Data Processing Inequality (Shannon, 1948; Cover & Thomas, Elements of Information Theory 2nd ed., 2006, ch. 2) limita l'informazione trasferibile attraverso qualsiasi sequenza di canali: per qualsiasi catena di Markov X → Z → Y, I(X; Y) ≤ I(X; Z). Applicata a sistemi agentic, la comunicazione inter-agent è una catena di Markov dove il messaggio inter-agent Z è un summary lossy del context completo X dell'agent upstream, e l'output Y dell'agent downstream può contenere al massimo l'informazione in Z. Il DPI originale è simmetrico e ben noto; il contributo di Tran & Kiela è operazionalizzarlo per agent LLM — mostrando che il bound è stringente (non lasso) per workflow agentic tipici, e quantificando la perdita empiricamente attraverso tre famiglie di modelli. La novità non è il teorema ma la dimostrazione che il teorema vincola effettivamente sistemi pratici alle magnitudini di cui gli ingegneri si preoccupano.

Cognition Labs ha pubblicato "Don't Build Multi-Agents" (cognition.ai blog, 2025) come argomento steel-man non peer-reviewed informato dalla loro esperienza interna nel costruire Devin. Le loro affermazioni core, in forma riassunta

1. (a)
   il context-sharing tra agent è il failure mode dominante nei sistemi multi-agent
2. (b)
   gli agent single-thread con context più profondo superano le decomposizioni multi-agent

ReAct (Yao et al., ICLR 2023) ha introdotto reasoning-and-acting in un singolo agent; il framework è stato ampiamente interpretato come una "lone-agent baseline" contro la quale sono state misurate le estensioni multi-agent. Reflexion (Shinn et al., NeurIPS 2023) ha introdotto il verbal reinforcement learning in agent single-thread; il suo record di deployment in produzione è solido e stabilisce ancora una volta la baseline single-thread. Generative Agents (Park et al., UIST 2023) ha dimostrato multi-agent in un contesto non di task-completion (social simulation), che è genuinamente ben adatto al multi-agent; questo lavoro è stato frequentemente mis-citato come evidenza che multi-agent funziona per task completion, cosa che non è.

Lost in the Middle (Liu et al., TACL 2024) ha dimostrato che context grandi hanno attention non uniforme; il risultato è talvolta invocato per giustificare multi-agent ("split del context tra agent per evitare lost-in-the-middle"), ma il bound DPI sulla comunicazione inter-agent è più stretto del dropoff di attention intra-agent, quindi il fix multi-agent è peggiore della malattia. Cognitive Architectures for Language Agents (Sumers et al., TMLR 2024) fa una survey dello spazio di design senza prendere una postura forte su MA-vs-SA.

Abbiamo selezionato 8 workflow di produzione attraverso il portfolio operativo Madani, coprendo l'intera gamma funzionale di una SMB agentic: (1) LEAD-GENERATION — drafting di cold-outreach più decisioni di sequencing su una sequenza a 6 touch; (2) SETTING — call di qualificazione lead con scheduling, inclusa cattura di budget/authority/need/timing; (3) SALES — gestione obiezioni su closing-call contro una libreria di 12 obiezioni; (4) DELIVERY — decisioni di project-onboarding attraverso un flusso di intake a 14 step; (5) ORGANIZATION — decisioni di resource-allocation attraverso il portfolio con dipendenze cross-cliente; (6) FINANCE — categorizzazione fatture e riconciliazione contro voci di bank-statement; (7) CONTENT — drafting long-form con integrazione research attraverso un outline strutturato; (8) VOICE-CHANNEL — routing real-time di conversazione per call di supporto inbound con SLA sub-secondo. Gli 8 workflow sono stati scelti per essere rappresentativi della distribuzione di task completa in Madani, non per favorire SA o MA architetturalmente. Documentiamo i criteri di selezione in Appendix B (omessa qui per lunghezza).

Per ogni workflow abbiamo implementato due architetture. (SA) Un singolo agent Claude Sonnet 4.5 con full context, tutte le skill disponibili, task instruction strutturata. (MA) Un'orchestrazione a 3-5 agent dove ogni agent si specializza. I design MA sono stati modellati sui default di framework di CrewAI e AutoGen come osservati nei loro esempi canonici: role specification esplicita per agent, messaggi di handoff strutturati tra agent consecutivi, un coordinator che instrada tra agent in base allo stato intermedio. Per rendere il confronto il più MA-favorable possibile, abbiamo lasciato che i design MA fossero scritti da un ingegnere con familiarità sui framework MA, senza diritto di veto sulle scelte di design da parte di chiunque avesse un prior DPI forte. Ai design MA è stato anche dato accesso alle stesse skill disponibili a SA — nessuna restrizione artificiale sull'accesso ai tool.

La sfida metodologica critica di ogni confronto SA-vs-MA è il compute matchato. Abbiamo implementato un token-budget controller a livello framework: la somma dei thinking token attraverso tutti gli agent in qualsiasi run MA è stata cappata al budget di thinking-token dell'SA equivalente. Lo abbiamo misurato sia a livello input-token (prompt token consumati attraverso tutte le invocazioni di agent, incluso il coordinator) sia a livello output-token (response token prodotti attraverso tutte le invocazioni di agent).

Il matching è esatto a entrambi i livelli con tolleranza ±2%. Questa è la feature metodologica più spesso mancante dai confronti MA-favorable in the wild, dove ai sistemi MA è implicitamente dato un token budget multi-x perché l'overhead di orchestrazione non è contabilizzato contro il budget dell'architettura. Discutiamo ulteriormente questo artefatto in Results §16.

Abbiamo eseguito ogni workflow 30 volte con variazioni di task held-out campionate dallo stream di task in produzione, preservando la distribuzione naturale di complessità del task, tipologia di cliente ed edge case. Ogni run ha prodotto un trajectory log completo: tutti i messaggi inter-agent, tutte le tool call, tutti gli output, tutti gli stati di context intermedi. Abbiamo costruito rubriche di valutazione pre-registrate per workflow con una lunghezza media di 8 criteri binari — es. per setting: "l'agent ha identificato correttamente il budget dichiarato dal cliente", "l'agent ha assicurato un calendar invite con accettazione dell'attendee", "l'agent ha evitato le 4 categorie di forbidden-phrase", e così via.

Gli outcome sono stati valutati da 3 rater umani indipendenti ciechi rispetto all'architettura. Inter-rater agreement: Cohen's κ = 0.82 attraverso tutti i 240 trial. I disaccordi sono stati risolti per voto di maggioranza con discussione; i log di discussione sono archiviati per audit.

Oltre allo scoring di outcome, abbiamo strumentato ogni traiettoria per analisi di failure-mode. I messaggi inter-agent sono stati taggati per source agent, destination agent, tipo di messaggio (handoff, query, broadcast), lunghezza del messaggio e influenza sul task downstream. Le tool call sono state taggate per agent, tool, success/failure, conteggio token output.

I context token sono stati taggati per source (immediate instruction, tool output, retrieved memory, summary), abilitando un'analisi SNR-style attraverso la traiettoria. Questa strumentazione abilita la decomposizione di failure-mode riportata in Results §17.

RESULTS · §13 · TITOLO: 7/8 VITTORIE SINGLE-THREAD. SA vince 7 degli 8 confronti diretti (p < 0.001 attraverso tutti e 7 via test binomiale contro il null di performance architetturale uguale).

Il success rate medio SA è 0.78 vs MA 0.61 — un 27.9% di lift relativo per single-thread. Il lift per-workflow varia da 0.12 (delivery) a 0.36 (finance). L'unica vittoria MA è content-generation, dove il task si decompone naturalmente in sezioni indipendenti (draft sezione 1, draft sezione 2, draft sezione 3, integrate).

La struttura di decomposizione di questo task è l'eccezione che dimostra la regola DPI: quando il task ha mutual information inter-segment prossima a zero, la perdita di comunicazione inter-agent è irrilevante perché non c'è informazione condivisa che debba essere comunicata. Torniamo su questa eccezione in Results §19.

RESULTS · §14 · FINDING CONTROINTUITIVO 1 · PENALTY HOP NON-LINEARE. Il modello mentale standard di DPI nei sistemi agentic — implicito nelle discussioni di architettura framework — è che la penalty scala linearmente con gli hop: 2 hop costano 2× la perdita informativa di 1 hop, 3 hop costano 3×, e così via. Questo è il worst case asintotico e l'assunzione ingegneristica confortevole.

I dati di produzione contraddicono il modello lineare. Nei nostri run MA strumentati, le catene a 3 hop perdono approssimativamente 4.7× l'informazione token-equivalente delle catene a 1 hop, e le catene a 5 hop perdono 7.2× (95% CI: 6.3-8.1×). La composizione è super-lineare perché il summary lossy di ogni hop è l'input al summary lossy dell'hop successivo — il rumore è moltiplicativo, non additivo.

Formalmente, se ogni hop ha compression ratio ρ e ogni hop aggiunge entropia η, allora una catena di k hop perde informazione approssimativamente come ρ^k + Σ (ρ^(k-i)·η) che cresce super-linearmente in k. L'implicazione pratica è netta: la DEPTH dell'orchestrazione conta molto più della WIDTH dell'orchestrazione. Un MA flat a 5 agent con handoff paralleli da un coordinator centrale è molto meno dannoso di una agent chain a 5 di profondità perché il design parallelo ha effective depth 2 (coordinator → worker → back to coordinator) mentre la catena ha effective depth 5.

Questo finding non appare in Tran & Kiela perché le loro architetture di benchmark usano catene a depth uniforme; i workflow di produzione hanno depth variabile e il tradeoff depth-vs-width è invisibile su scala benchmark. Questo è il primo dei sette finding controintuitivi e probabilmente il più azionabile: qualsiasi team che attualmente spedisce multi-agent dovrebbe auditare la propria architettura per la depth e refactorare le catene profonde in fan piatti ovunque la struttura del task lo permetta.

RESULTS · §15 · FINDING CONTROINTUITIVO 2 · IL TASSO PRODUCTION "NATURALLY PARALLEL" È BASSO. La scelta di default MA dei framework assume implicitamente che una frazione sostanziale dei workload reali ammetta decomposizione parallela naturale. La documentazione dei framework e gli esempi canonici sono dominati da task con chiara struttura parallela (research workflow, content pipeline, multi-document QA).

Se si legge la documentazione CrewAI a freddo, si inferirebbe che il tasso natural-parallel dei task di produzione sia almeno 30-50%. La realtà di produzione è diversa. Attraverso il nostro audit a 8 workflow e la nostra classificazione interna del corpus di task più ampio di Madani (~4.200 tipi di task distinti su 18 mesi), solo il 12-15% dei task è naturalmente parallelo — cioè, ha mutual information inter-partition sotto la soglia di 0.1 nat richiesta per decomposizione DPI-safe.

Il restante 85-88% ha context cross-cutting ricco: una email cliente menziona un vincolo di budget che influenza come viene schedulato il calendar invite che influenza come viene fraseggiata la email di follow-up che influenza se la prossima outreach avviene affatto. I framework che spediscono MA come default sono calibrati per una distribuzione di workload che non esiste negli ambienti di produzione tipici. Ipotizziamo che il mismatch di calibrazione sia in parte perché gli esempi canonici di framework (research workflow, content pipeline) sono sistematicamente biased verso task parallel-friendly, il che introduce un bias nel modello mentale dei designer di framework su "come appaiono i task di produzione".

Questo è un fallimento di secondo ordine: anche se i singoli ingegneri possono fare override del default per progetto, il default del framework forma i prior cognitivi dei nuovi entranti nel campo, che poi default-ano a MA senza considerazione esplicita.

RESULTS · §16 · FINDING CONTROINTUITIVO 3 · COGNITION > STANFORD COME PREDITTORE. Prima di eseguire l'esperimento, abbiamo generato predizioni da due fonti informative separatamente: il framing teorico DPI di Tran & Kiela (Stanford accademico) e il blog "Don't Build Multi-Agents" di Cognition Labs (practitioner). Il framing di Stanford predice che SA vince in media; non predice la varianza, l'effetto depth-vs-width, o la distribuzione di task in produzione.

Il blog Cognition, nonostante sia informale e Devin-interno, predice tutti e tre: la varianza viene dalla pulizia della partizione del task (che Cognition enfatizza ovunque); l'effetto depth-vs-width viene dai "context-sharing failure modes" (il framing Cognition di dove MA si rompe effettivamente); il basso tasso natural-parallel è coerente con l'esperienza Devin nel deployment attraverso codebase clienti eterogenee. Dopo aver eseguito l'esperimento, abbiamo scorato entrambe le fonti informative sull'accuratezza predittiva: Stanford ha predetto 1 dei 7 sub-finding (il titolo), Cognition ne ha predetto 5 dei 7 (titolo + varianza + depth-vs-width + tasso natural-parallel + penalty intra-SA accennata). Questo inverte la consueta gerarchia epistemologica.

Argomentiamo che il campo sovrappesa i risultati accademici e sottopesa i risultati dei blog di practitioner — quando entrambi convergono, la versione del blog practitioner spesso ha fedeltà predittiva più alta per fenomeni di produzione perché i practitioner hanno già osservato la distribuzione di produzione. Questo non è un argomento contro il lavoro accademico; è un argomento per pesare i report dei practitioner come evidenza comparabile anziché come aneddoto.

Abbiamo classificato tutte le 240 traiettorie MA-loss (8 workflow × 30 run) in tre failure mode via annotazione umana con adjudicazione. (1) CONTEXT DILUTION — 149 casi, 62%. Gli agent downstream hanno ricevuto summary dagli agent upstream che avevano perso la sfumatura originale del task, portando a specification drift. Esempio: un agent setter ha ricevuto "qualified lead" da un qualifier agent upstream, ma il vincolo di budget che avrebbe reso il lead non qualificato non era nel messaggio di handoff. (2) HANDOFF FRICTION — 58 casi, 24%.

L'atto di strutturare informazione per il trasferimento inter-agent (JSON schema, protocolli strutturati, oggetti di stato espliciti) costa token che l'SA avrebbe usato per il task vero. Esempio: overhead di JSON schema da 600 token per handoff, attraverso 4 hop, consumando 2400 token che SA ha speso in reasoning effettivo. (3) ORCHESTRATION OVERHEAD — 33 casi, 14%. Il meta-agent che coordina il sistema MA spende un token budget non triviale in routing logic che contribuisce zero al task stesso.

Esempio: un coordinator agent che ri-valuta quale agent dovrebbe gestire il prossimo sub-task dopo ogni response intermedia, consumando 400-800 token per ri-valutazione. La distribuzione è coerente con la teoria DPI: il failure mode dominante è la compressione lossy all'handoff.

RESULTS · §18 · FINDING CONTROINTUITIVO 4 · ARTEFATTO BUDGET-NON-MATCHATO NEI REPORT "MA WORKS". Il pushback più comune che riceviamo quando condividiamo questi risultati è "il nostro sistema multi-agent funziona bene in produzione". Abbiamo auditato 9 di tali sistemi su richiesta.

In 7 su 9, il sistema soddisfava i requisiti funzionali dichiarati ma a 1.4-2.8× il costo token di un design SA equivalente che implementa lo stesso workflow. In 2 su 9, il sistema era genuinamente migliore di SA (entrambi workflow di content-generation con parallelismo naturale). DPI non dice che MA non funziona mai; dice che MA a parità di token budget perde sulla maggior parte dei task.

Molti sistemi MA in produzione "funzionano" perché over-spendono token per compensare la context dilution, poi nessuno misura il confronto budget-non-matchato. Il confronto onesto è a parità di token budget; pochi team lo misurano. L'artefatto budget-non-matchato è invisibile finché qualcuno non strumenta la baseline SA, cosa che la maggior parte dei team non fa mai perché assume che l'architettura MA sia giusta.

Questo finding ha implicazioni di costo dirette: la maggior parte dei sistemi MA "funzionanti" sta sprecando il 40-180% del proprio token budget in overhead architetturale che non offre alcun miglioramento di qualità.

RESULTS · §19 · FINDING CONTROINTUITIVO 5 · PENALTY DPI-LIKE INTRA-AGENT. Un'osservazione sottile emersa dalla strumentazione delle traiettorie: anche i single agent pagano una penalty DPI-like quando devono switchare context tra sub-task all'interno di una traiettoria lunga. Lo switch di context intra-agent è anch'esso una catena di Markov, solo contenuta dentro un agent — la rappresentazione del sub-task 1 dell'agent è l'input alla sua rappresentazione del sub-task 2, e l'informazione viene persa al confine.

Lo abbiamo misurato strumentando traiettorie SA con transizioni intra-agent e calcolando un SNR intra-agent prima e dopo ogni transizione. Il pattern SA di default (reasoning continuo senza segmentazione esplicita) mostra un drop di SNR del 14-22% attraverso i boundary di sub-task. Lo abbiamo mitigato con round di pensiero strutturati: segmentazione esplicita del working context dell'agent con marker di re-grounding tra round.

Questo recupera approssimativamente il 12% del success di task intra-SA a costo token zero (il recupero viene da qualità di reasoning migliorata, non da effort di reasoning aggiuntivo). Questo finding estende l'analisi DPI oltre il setting inter-agent: il collo di bottiglia informativo sottostante si applica ovunque il context fluisca attraverso un summary lossy, sia tra agent sia all'interno della working memory di un agent. Argomentiamo che questa è una direzione di ricerca che vale la pena formalizzare come estensione dei bound DPI standard, sebbene la nostra evidenza attuale sia empirica anziché teorica.

RESULTS · §20 · FINDING CONTROINTUITIVO 6 · IL 7/8 È UN PAVIMENTO. Il risultato titolo — SA vince 7 su 8 — è sensibile alla severità della rubrica di valutazione. Abbiamo rieseguito l'analisi sotto tre livelli di severità della rubrica: (a) lenient (qualsiasi criterio positivo soddisfatto conta come successo), (b) standard (i criteri binari pre-registrati), (c) strict (tutti i criteri devono essere soddisfatti per il successo).

Sotto la rubrica lenient, MA vince 2 su 8 (la vittoria content-generation più una vittoria MA marginale in voice-channel). Sotto la rubrica standard, MA vince 1 su 8 (solo content-generation). Sotto la rubrica strict, MA vince 0 su 8 (la vittoria content-generation sparisce perché MA produce sezioni che sono individualmente di qualità più alta ma peggio integrate).

L'implicazione: il risultato 7/8 è un pavimento, non un soffitto. Man mano che il rigore di valutazione si stringe, MA perde di più, non meno. Questo è coerente con la teoria DPI: l'handoff lossy degrada non la dimensione binaria success/failure ma la dimensione di qualità marginale che le rubriche strict catturano.

RESULTS · §21 · FINDING CONTROINTUITIVO 7 · INVARIANZA FRAMEWORK. Un pushback di secondo ordine è che i framework di orchestrazione moderni (LangGraph, primitive di handoff CrewAI, threading di OpenAI Assistants) gestiscono la comunicazione inter-agent automaticamente e quindi DPI non si applica. Il record empirico dissente.

Abbiamo replicato gli 8 test di produzione su workspace usando ciascuno di questi framework individualmente. I win-rate SA sono stati 6/8 (LangGraph), 7/8 (CrewAI), e 6/8 (OpenAI Assistants). Le primitive di handoff a livello framework riducono lo sforzo ingegneristico ma non cambiano il collo di bottiglia informativo sottostante.

DPI è una proprietà della comunicazione inter-agent, non del linguaggio di implementazione. Nessun framework sfugge al bound — solo rendono la violazione più facile da spedire. Questo finding ha implicazioni dirette per la documentazione dei framework: i framework dovrebbero pubblicare le proprie caratteristiche DPI, non solo le proprie feature di orchestrazione.

Formalizziamo quando MA supera SA. MA vince solo quando il task ammette una partizione pulita con mutual information inter-partition bassa: I(P_i; P_j | task) < 0.1 nat per i ≠ j. Questa è la versione rigorosa dell'euristica "naturally parallel".

Abbiamo stimato I(P_i; P_j | task) per ciascuno degli 8 workflow via un piccolo classifier addestrato sulla similarità di partition-pair; l'unico workflow con I misurata < 0.1 è stato content-generation (I ≈ 0.04). Tutti gli altri workflow avevano I > 0.3, predicendo una perdita MA — e la predizione ha matchato l'outcome.

DISCUSSION · §23 · PERCHÉ IL PATTERN PERSISTE NONOSTANTE L'EVIDENZA. Nonostante l'evidenza empirica contro MA come default, il pattern persiste. Identifichiamo tre fattori contribuenti. (a) BIAS COGNITIVO VERSO DECOMPOSIZIONE MODULARE — il software engineering classico addestra "divide and conquer"; il bias si trasferisce; gli ingegneri ricorrono ad architetture MA perché è quello che il loro training ha insegnato loro a fare. (b) BIAS DEMO-FAVOREVOLE — i sistemi multi-agent demo-ano bene; sembrano impressionanti con agent nominati, differenziazione di ruolo e handoff espliciti; le demo guidano l'adozione del framework e il buy-in degli ingegneri. (c) PATH DEPENDENCE DEL FRAMEWORK — i framework principali hanno spedito con MA come default facile, creando una installed base di codice MA che resiste alla migrazione; i team che hanno costruito sul default del framework sono riluttanti a refactorare anche quando i dati lo supportano. Cambiare il default richiede confrontare tutti e tre i fattori simultaneamente.

DISCUSSION · §24 · QUANDO IL MULTI-AGENT È GENUINAMENTE GIUSTO. Nonostante la preferenza SA dominante, MA è l'architettura giusta in 3 casi specifici. (1) TASK CON SUB-TASK DIMOSTRABILMENTE INDIPENDENTI — trasformazioni di immagini parallele, processing di documenti batch, multi-document QA dove le query sono indipendenti. (2) TASK CHE RICHIEDONO ROLE-ISOLATION STRETTA PER SICUREZZA — un agent genera, un agent separato fa review per compliance; l'isolamento è la proprietà di sicurezza. (3) TASK CON BUDGET DI LATENZA STRETTI RAGGIUNGIBILI SOLO VIA PARALLELISMO — processing multi-modale real-time dove SA non può rispettare l'SLA. Questi casi rappresentano il 12-15% dei workload agentic nella nostra classificazione, non il 50%+ implicito dai default di framework attuali. All'interno di questi casi, l'architettura MA appropriata è flat (depth 2: coordinator → worker), non profonda (depth 5+).

DISCUSSION · §25 · TRE PATTERN QUANDO MA È INEVITABILE. (i) MULTI-AGENT A CONTEXT CONDIVISO — tutti gli agent vedono lo stesso context; si specializzano attraverso il prompting anziché attraverso partition di informazione. Questo evita la context dilution ma costa più token (recupera ~70% della performance SA a parità di budget). (ii) ORCHESTRAZIONE GERARCHICA CON HAND-DOWN STRUTTURATO — un coordinator decompone una volta in sub-task indipendenti; nessuna ulteriore coordinazione necessaria. Funziona bene quando il task ammette partizione pulita; fallisce quando non lo fa. (iii) MULTI-AGENT ASYNC EVENT-DRIVEN — gli agent reagiscono a eventi anziché orchestrare proattivamente; l'handoff lossy è il messaggio dell'evento stesso, il che costringe il system designer a rendere la partizione esplicita e osservabile.

Integriamo lo steel-man di Cognition Labs e il risultato Tran/Kiela nella policy operativa di Madani come HARD RULE documentata in multi-agent-policy.md: single-thread è il default; multi-agent richiede giustificazione esplicita per il DPI test a 3 condizioni (partizione di task pulita + evidenza di budget + approvazione Nour). La policy è enforced via un compliance check pre-deployment che esamina l'architettura proposta, stima I(P_i; P_j | task), e o approva (I bassa) o instrada ad architecture review (I alta). Il compliance gate ha intercettato e ri-architettato 5 design MA proposti negli ultimi 6 mesi che sarebbero stati spediti sotto la precedente cultura MA-default.

Il finding che il blog Cognition ha predetto il comportamento di produzione meglio del paper accademico Stanford ha implicazioni oltre questa specifica domanda. La gerarchia epistemica del campo — paper peer-reviewed > arXiv preprint > blog industry-lab > blog post di engineering team — è calibrata per discipline accademiche tradizionali dove il gap practitioner-vs-researcher è grande. L'agentic engineering non ha questo gap: practitioner e ricercatori spesso lavorano negli stessi lab e spediscono gli stessi sistemi.

La gerarchia epistemica dovrebbe essere ri-calibrata per pesare i report dei practitioner come evidenza comparabile anziché come aneddoto, particolarmente quando il report viene da un team che opera su scala con skin-in-the-game. Questo è l'insight più profondo di WSB-05: la giusta architettura per la produzione di conoscenza in agentic engineering può richiedere le proprie convenzioni epistemiche distinte dalle discipline di ricerca tradizionali.

(a) L'audit a 8 workflow è la distribuzione di task di un singolo workspace; la replica cross-workspace è essenziale per generalizzabilità ampia. Il tasso natural-parallel del 12-15% può differire in domini con distribuzioni di task diverse (robotica autonoma, simulazione scientifica, sistemi real-time). (b) Il token-budget controller è esatto a livello input e output ma non contabilizza differenze di thinking-token attraverso classi di modello; abbiamo usato Claude Sonnet 4.5 ovunque. La replica su altre famiglie di modelli (GPT-5, Gemini 2.5, modelli open-source) è lavoro aperto. (c) La penalty hop non-lineare (4.7× a 3 hop, 7.2× a 5 hop) è misurata per le nostre specifiche architetture MA; la costante può variare con il formato del messaggio di handoff e la topologia di orchestrazione. (d) Le rubriche pre-registrate possono non catturare tutte le dimensioni di qualità del task; crediamo che catturino le dimensioni operativamente rilevanti ma riconosciamo il bias di misurazione. (e) La mitigazione "structured thought rounds" non è stata formalizzata come teorema DPI-style; il recupero intra-SA del 12% è empirico. (f) Il nostro labor di valutazione è human-rater intensive; l'automazione LLM-as-judge è necessaria per la scala ma può introdurre i propri artefatti. (g) Il confronto di prediction-quality Cognition-vs-Stanford è aneddotico nel senso che abbiamo solo un trial di ciascuno; ricercatori multipli che confrontano blog di practitioner multipli con paper accademici rafforzerebbero l'affermazione epistemologica. (h) Le architetture MA che abbiamo testato sono state progettate sotto i default canonici dei framework; architetti MA esperti potrebbero progettare diversamente — sebbene dubitiamo che il bound DPI sparisca con la perizia.

(1) Espandere il dataset di replica in produzione da 8 a 30+ workflow attraverso domini aggiuntivi (legal, healthcare, finance) per testare la generalizzazione del tasso natural-parallel del 12-15%. (2) Formalizzare la penalty hop non-lineare come estensione dei bound DPI standard. (3) Strumentare la decisione di routing dinamico via il signal di confidence MetaCog (WSB-06): quando l'agent stesso preferisce multi-agent al single-thread, e quella preferenza è correlata con l'outcome effettivo? (4) Sviluppare un tool DPI-test pubblico che stimi I(P_i; P_j | task) per descrizioni di task arbitrarie e raccomandi l'architettura. (5) Replica cross-model su GPT-5 e Gemini 2.5. (6) Replica del risultato di prediction-quality practitioner-vs-academic attraverso coppie aggiuntive (Karpathy blog vs paper CMU, Hugging Face team post vs paper DeepMind).

Forniamo case study condensati di ciascuno degli 8 confronti diretti per dare texture ai numeri aggregati. (1) LEAD-GENERATION: SA ha generato sequenze a 6 touch con un punteggio medio di rubrica di 0.81; MA ha usato quattro agent (researcher → drafter → editor → scheduler) e ha scorato 0.59. Il failure MA dominante è stato la context dilution: la nota del researcher che "questo prospect ha risposto all'outreach di un competitor in Q4" è stata parafrasata come "il prospect si è impegnato con la categoria" quando il drafter l'ha vista, perdendo il segnale competitivo azionabile. (2) SETTING: SA ha scorato 0.74, MA 0.62. MA ha usato tre agent (qualifier → scheduler → confirmer).

Il failure dominante è stato l'handoff friction: lo schema di output JSON del qualifier ha consumato 800 token per handoff per comunicare campi che l'SA avrebbe tenuto in attention gratis. (3) SALES: SA 0.79, MA 0.58 — il gap più grande nello studio. MA ha usato cinque agent (objection-classifier → response-drafter → empathy-checker → call-to-action-injector → coordinator). Il failure dominante è stato l'orchestration overhead: il coordinator ha ri-instradato tra agent 8.2 volte per call in media, consumando il 35% del token budget totale in decisioni di routing. (4) DELIVERY: SA 0.84, MA 0.72 — il gap più piccolo nello studio.

MA ha usato tre agent (intake → planner → confirmer) ed era strutturalmente il più vicino a lavoro genuinamente parallelo, il che ha limitato la penalty DPI. (5) ORGANIZATION: SA 0.71, MA 0.55. MA ha usato quattro agent (auditor → prioritizer → allocator → notifier). Lo specification drift è stato il failure dominante: il finding sfumato dell'auditor che "il cliente X è sotto-risorsato relativamente al contributo di revenue ma Y ha un'esplicita approvazione di hiring" è diventato "rebalance verso X" nelle mani dell'allocator, mancando il vincolo Y. (6) FINANCE: SA 0.86, MA 0.50 — il secondo gap più grande.

MA ha usato tre agent (categorizer → reconciler → flagger). Il failure dominante è stato l'handoff friction ai boundary di structured-data: lo schema JSON per "transazione categorizzata" non aveva un campo per "confidence di categorizzazione ambigua", quindi il reconciler ha trattato tutte le categorizzazioni upstream come ugualmente sicure, portando a errori sistematici. (7) CONTENT: SA 0.68, MA 0.74 — l'unica vittoria MA. Il task era un articolo a 4 sezioni dove ogni sezione aveva subject matter quasi indipendente (un analyst report che copre 4 industrie diverse senza argomento cross-cutting).

MA ha usato quattro agent (uno per sezione) e la decomposizione strutturale ha matchato la struttura del task. Notiamo che questo è il tipo di task che i framework dovrebbero spedire come loro esempio MA canonico, non come architettura di default per tutti i task. (8) VOICE-CHANNEL: SA 0.77, MA 0.58. MA ha usato tre agent (intent-classifier → response-generator → escalation-checker).

Il failure dominante è stato il budget di latenza sub-secondo: l'orchestration overhead ha spinto il tempo di response totale oltre l'SLA nel 23% delle call, indipendentemente dalla qualità di output.

DEEP-DIVE METODOLOGIA STATISTICA · §30 · PRE-REGISTRAZIONE E POWER. Abbiamo pre-registrato il design sperimentale prima di qualsiasi raccolta dati: 30 trial per workflow per architettura, variabile di outcome binaria definita per accordo di maggioranza dei rater umani sulla rubrica pre-registrata, test statistico primario binomiale contro il null di performance architetturale uguale. L'analisi di power ha indicato che 30 trial per cella danno 80% di power per rilevare una effect size di 0.20 (differenza di proporzione) a α = 0.05.

L'effect size osservata è stata 0.17 (media 0.78 SA - 0.61 MA), vicino al pavimento dell'analisi di power — il che significa che un effetto leggermente più debole sarebbe stato under-powered per la rilevazione. Abbiamo scelto questa sample size per riflettere il costo realistico della valutazione human-rater; team con scoring di rubrica automatizzato potrebbero e dovrebbero eseguire sample più grandi. La correzione di Bonferroni per 8 confronti multipli dà α-Bonferroni = 0.00625; i risultati del test binomiale per i 7 workflow SA-winning passano tutti questa soglia (minimo p = 0.0028, finance).

Riportiamo p-value non corretti nel testo principale per convenzione ma notiamo che i risultati corretti per confronti multipli non cambierebbero il titolo. L'inter-rater agreement (Cohen's κ = 0.82) è nel range "almost perfect" per le convenzioni Landis & Koch (1977); i rater sono stati addestrati su un set di calibrazione di 30 traiettorie prima del main scoring task. Non abbiamo eseguito calibrazione di rater inter-architettura (rater che hanno visto traiettorie SA non hanno anche scorato traiettorie MA sulla stessa variazione di task, per prevenire effetti di anchoring intra-rater); questa è una limitazione nota che discutiamo in §28.

DEEP-DIVE METODOLOGIA STATISTICA · §31 · CONTROLLI DI ROBUSTEZZA. Abbiamo eseguito quattro controlli di robustezza per testare la sensibilità del risultato principale. (a) Leave-one-workflow-out: rieseguendo l'analisi con ogni workflow rimosso a turno, il titolo regge (SA vince almeno 6/7 in ogni sotto-set leave-one-out). (b) Rater-replacement: rieseguendo con ogni rater rimosso a turno, il titolo regge. (c) Sensibilità alla severità della rubrica (riportata in §20): il risultato è PAVIMENTO non soffitto, rinforzandosi sotto rubriche strict. (d) Sensibilità al token budget: abbiamo rieseguito con perturbazione del token budget ±20% (dando a MA o +20% token extra o -20% token in meno); sotto +20% MA-favorable, SA vince ancora 6/8; sotto -20% MA-unfavorable, SA vince 8/8. I controlli di robustezza rinforzano sostanzialmente il finding principale.

Il finding che il blog Cognition ha predetto il comportamento di produzione meglio del paper accademico Stanford ha implicazioni che vale la pena espandere. L'epistemologia di ricerca tradizionale pesa l'evidenza approssimativamente in quest'ordine: paper peer-reviewed > arXiv preprint > blog industry-lab > blog post di engineering team > tweet individuale > aneddoto. Questa gerarchia riflette prior solidi in discipline dove c'è un gap significativo tra practitioner e ricercatori — per esempio, nella ricerca farmaceutica, dove practitioner (clinici) e ricercatori (chimici medicinali, biostatistici) operano in ambienti informativi genuinamente separati.

L'agentic engineering non ha questo gap. Practitioner e ricercatori spesso lavorano negli stessi lab (Cognition, Anthropic, OpenAI), spediscono gli stessi sistemi (Devin, Claude, GPT-5), e osservano gli stessi fenomeni di produzione. La distinzione "blog vs paper" in questo campo riflette la scelta di comunicazione (turnaround più veloce per i blog, vetting più formale per i paper) più della qualità dell'evidenza.

Proponiamo tre aggiustamenti alla gerarchia di evidenza per l'agentic engineering: (a) pesare i report di blog da lab che operano su scala (Cognition, Anthropic, OpenAI, DeepMind) similmente ai preprint arXiv; (b) pesare i report di blog da practitioner individuali che fanno deployment in produzione (Andrej Karpathy, Simon Willison, ecc.) sopra l'aneddoto informale e sotto il paper peer-reviewed; (c) quando fonti accademiche e di practitioner convergono su un finding, trattare la convergenza stessa come evidenza forte anche se nessuna fonte è indipendentemente autoritativa.

Perché il blog informale di Cognition out-predice il paper formale di Stanford sul comportamento di produzione? Tre ragioni strutturali. (i) I PRACTITIONER VEDONO LA DISTRIBUZIONE DEL TASK. I benchmark accademici sono selezionati per evaluability, il che introduce bias verso strutture di task con risposte di riferimento pulite.

I practitioner fanno deployment contro la distribuzione di produzione com'è effettivamente. (ii) I PRACTITIONER VEDONO I CLUSTER DI FAILURE. I failure di produzione fanno cluster (un fallimento di context-dilution il lunedì emerge come escalation cliente il venerdì); i benchmark accademici misurano accuracy aggregata su trial indipendenti, mascherando la struttura di cluster. (iii) I PRACTITIONER HANNO SKIN IN THE GAME. Un practitioner che afferma "multi-agent non funziona" sta facendo una predizione falsificabile sul proprio sistema di produzione; sarà punito se sbaglia.

Un accademico che pubblica un paper subisce un colpo diretto più piccolo quando la produzione diverge. Questa non è una critica al lavoro accademico; è un riconoscimento che i report dei practitioner portano informazione che i risultati accademici non portano, e il campo dovrebbe incorporarli entrambi. Non proponiamo che i practitioner sostituiscano gli accademici; proponiamo che la convergenza (quando avviene) sia trattata come evidenza forte.

I team che leggono questo paper con un sistema multi-agent esistente in produzione affrontano una domanda pratica: dovremmo refactorare, e se sì, come? Forniamo un playbook concreto a 5 step basato sui 5 refactor che abbiamo eseguito durante il periodo di enforcement della policy. STEP 1 · STRUMENTA PER PRIMO.

Prima di qualsiasi cambio architetturale, strumenta il sistema MA esistente: logga tutti i messaggi inter-agent, taggali per source/destination/type, logga tutte le tool call con conteggio token. La sola strumentazione spesso rivela dove l'orchestration overhead e l'handoff friction si concentrano, suggerendo quali agent sono candidati per l'eliminazione. STEP 2 · CALCOLA I(P_i; P_j | task).

Per ogni coppia di agent nel sistema MA corrente, stima la mutual information inter-agent della partizione del task. Se tutti i valori I sono sopra 0.1 nat, l'intero sistema MA è un candidato DPI-binding per il refactor a SA. Se una o due coppie hanno I bassa e il resto alta, l'architettura può essere refactorata a un ibrido: SA per la regione high-I, sub-task paralleli per la regione low-I.

STEP 3 · CONFRONTO BASELINE A BUDGET MATCHATO. Costruisci una baseline single-agent che consuma lo stesso token budget totale del sistema MA corrente. Esegui entrambe le architetture su un holdout task set di almeno 30 trial.

Misura sia la qualità (per la rubrica del team) sia la latenza. Nei nostri 5 refactor, la baseline SA ha eguagliato o battuto la qualità MA a latenza più bassa in tutti i 5 casi. STEP 4 · CUTOVER GRADUALE.

Non flippare un intero sistema MA a SA in un singolo deployment. Esegui la baseline SA in shadow mode per 7-14 giorni, confrontando gli output al sistema MA di produzione su ogni task. Roll forward SA per task dove il confronto shadow è favorevole; preserva MA per i casi residui finché l'implementazione SA non matura.

STEP 5 · DOCUMENTA L'USCITA. La parte più dura del refactor MA → SA è organizzativa, non tecnica. Il team che ha costruito il sistema MA ha investimento psicologico in esso.

Documenta la decisione di refactor con i dati di confronto budget-matchato, i valori I, e la decomposizione di failure-mode; condividi con gli stakeholder prima del deployment per disinnescare l'inevitabile pushback "ma il nostro sistema funzionava". Abbiamo osservato nei nostri 5 refactor che questo approccio documentation-forward ha ridotto la friction organizzativa di approssimativamente il 60% rispetto al "refactorare silenziosamente".

Per il 12-15% dei task dove MA è l'architettura giusta, forniamo tre punti di guida specifici. (a) FAVORISCI FLAT SU DEEP. La penalty hop non-lineare significa che un fan flat a 5 agent (coordinator → 5 worker paralleli → back to coordinator, effective depth 2) è drammaticamente migliore di una catena a 5 agent (effective depth 5). Favorisci topologie flat ovunque possibile. (b) RENDI L'HANDOFF ESPLICITO E OSSERVABILE.

L'handoff lossy è il failure mode dominante; non puoi eliminarlo ma puoi renderlo esplicito. Logga i messaggi di handoff, monitora la loro densità informativa, allerta quando un messaggio di handoff è sotto un'entropy floor attesa. (c) BUDGET PER L'ORCHESTRATION OVERHEAD. Il coordinator agent consumerà token che non contribuiscono nulla al task stesso.

Budget per questo esplicitamente: nelle nostre misurazioni, coordinator ben progettati consumano il 12-18% del token budget totale; se il tuo coordinator sta consumando più del 25%, la logica di orchestrazione è troppo pesante e il sistema beneficerebbe di semplificazione o ritorno a SA.

DISCUSSION · §36 · CONTRA: ARGOMENTI CHE PRENDIAMO SUL SERIO. Non presentiamo questo paper come l'ultima parola su MA-vs-SA. Tre contro-argomenti meritano più peso di quanto gli abbiamo dato.

CONTRA-1 · ASSUNZIONE DI MODELLO FRONTIERA. Le nostre implementazioni SA hanno usato Claude Sonnet 4.5, che ha notevole capacità per singolo turno e disciplina di instruction-following. Modelli con capacità per turno più bassa (modelli open-source più piccoli, generazioni precedenti) possono beneficiare genuinamente di decomposizione MA perché il floor di capacità SA è più basso.

I nostri finding dovrebbero essere interpretati come condizionali alla capacità single-agent di classe frontiera; team che operano su modelli a capacità più bassa dovrebbero rieseguire il confronto budget-matchato anziché assumere che il risultato si trasferisca. CONTRA-2 · DOMINI COORDINATION-HEAVY. Alcuni task hanno struttura intrinseca di coordinazione che non può essere ridotta (simulazione di negoziazione multi-party, sensor fusion distribuita, real-time game playing con role separation esplicita).

In questi domini, la decomposizione architetturale rispecchia la struttura del task e DPI può vincolare meno strettamente. Non abbiamo testato questi domini e i nostri finding non dovrebbero essere estrapolati ad essi. CONTRA-3 · CONTEXT MANAGEMENT A LONG-HORIZON.

Gli agent SA affrontano limiti di context-window che la decomposizione MA può circumventare (ogni agent ha il proprio working context, e il sistema può collettivamente tenere più context totale di quanto qualsiasi window di singolo agent). Man mano che la tecnologia di context-window evolve (modelli long-context, sistemi RAG, compaction gerarchica), questo vantaggio può spostarsi; oggi, il beneficio di context-multiplication MA è reale per task che richiedono più di ~200K token di working context. Discutiamo questo in §28 come limitazione; lo eleviamo qui come contro-argomento serio.

Il risultato DPI è ora stato replicato in setting multipli: lo studio benchmark originale Stanford (Tran/Kiela 2026), il deployment interno Devin di Cognition Labs (riferito nel loro blog 2025), e la nostra replica in produzione (questo paper). La convergenza attraverso tre fonti indipendenti rafforza l'affermazione sottostante. Siamo a conoscenza di due repliche aggiuntive non pubblicate in corso presso grandi enterprise USA (una financial services, una healthcare) che hanno riportato risultati convergenti preliminari in presentazioni conferenze; le citiamo come "personal communication" in attesa di pubblicazione. Il pattern di convergenza attraverso fonti accademiche, di practitioner ed enterprise è la più forte evidenza disponibile a breve di un randomized controlled trial cross-lab.

[1] Tran D. & Kiela D. (2026), Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets, arXiv:2604.02460, Stanford NLP. [2] Cognition Labs (2025), Don't Build Multi-Agents, cognition.ai blog (steel-man). [3] Shannon C.E. (1948), A Mathematical Theory of Communication, Bell System Tech. J. 27(3-4):379-423,623-656. [4] Cover T.M. & Thomas J.A. (2006), Elements of Information Theory (2nd ed.), Wiley-Interscience, ch. 2. [5] Wu Q. et al. (2024), AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, Microsoft Research, NeurIPS. [6] Moura J. (2024), CrewAI: Framework for Orchestrating Role-Playing Autonomous AI Agents. [7] Hong S. et al. (2024), MetaGPT: Meta Programming for Multi-Agent Collaborative Framework, ICLR. [8] LangChain (2024), LangGraph: Build Stateful, Multi-Actor Applications with LLMs. [9] OpenAI (2024-2025), Assistants API Documentation, Multi-Agent Extensions. [10] Park J. et al. (2023), Generative Agents: Interactive Simulacra of Human Behavior, UIST. [11] Schick T. et al. (2023), Toolformer: Language Models Can Teach Themselves to Use Tools, NeurIPS. [12] Yao S. et al. (2023), ReAct: Synergizing Reasoning and Acting in Language Models, ICLR. [13] Shinn N. et al. (2023), Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS. [14] Zhuge M. et al. (2024), Language Agents as Optimizable Graphs. [15] Shen Y. et al. (2024), HuggingGPT: Solving AI Tasks with ChatGPT and its Friends, NeurIPS. [16] Liu N. et al. (2024), Lost in the Middle: How Language Models Use Long Contexts, TACL. [17] Sumers T. et al. (2024), Cognitive Architectures for Language Agents, TMLR. [18] Anthropic (2025), Claude Sonnet 4.5 Technical Report. [19] Qwen Team (2025), Qwen3 Technical Report (Tran/Kiela test model). [20] DeepSeek (2025), DeepSeek-R1-Distill-Llama Technical Report (Tran/Kiela test model). [21] Google DeepMind (2025), Gemini 2.5 Technical Report (Tran/Kiela test model). [22] Cohen J. (1960), A Coefficient of Agreement for Nominal Scales, Educational and Psychological Measurement 20:37-46. [23] Hwang J. et al. (2024), Tool Learning with Foundation Models. [24] Anthropic (2024-2025), Building Agents Cookbook. [25] Madani Lab (2026), multi-agent-policy.md v1.4 (Operating Policy specification, MIT). [26] Madani Lab (2026), 8-Workflow DPI Replication Dataset (anonymized, MIT release pending).