L'anti-pattern multi-agent: uno studio sul campo in produzione sulla diluizione del context nella comunicazione inter-agent

Riportiamo uno studio sul campo di 14 deployment di produzione multi-agent (MAS) presso 11 aziende UE, condotto tra gennaio 2025 e aprile 2026 con interviste strutturate e analisi di root-cause basata su audit, progettato per testare le predizioni dello steel-man contrarian di Cognition Labs ""Don't Build Multi-Agents"" (cognition.ai blog, 2025) contro dati empirici di produzione. Il pattern architetturale agent-swarm — multipli agent specializzati che si coordinano tramite comunicazione strutturata — è il default di diversi framework popolari (CrewAI, AutoGen, LangGraph, estensioni multi-agent di OpenAI Assistants) ed è diventato il modello mentale dominante tra gli AI engineer dal 2023. Cognition Labs ha pubblicato un argomento steel-man contrarian fondato sulla loro esperienza ingegneristica interna con Devin, sostenendo che il context-sharing inter-agent è fondamentalmente lossy e che gli agent single-thread con context più profondo superano i sistemi multi-agent in produzione. L'argomento era teorico e informale; Tran & Kiela (arXiv:2604.02460, accettato aprile 2026) hanno successivamente fornito la conferma accademica tramite i limiti della Data Processing Inequality (WSB-05). Questo paper fornisce la conferma empirica di produzione tramite uno studio sul campo su 14 deployment e produce un catalogo operativo di anti-pattern che mappa ogni design multi-agent comune al suo failure mode osservato. Il risultato è operativamente conseguente: dei 14 deployment, 2 restano stabili in produzione, 7 sono stati riportati ad architetture single-agent, 5 sono stati abbandonati — un tasso di fallimento o rollback dell'86%. Riportiamo SETTE risultati controintuitivi

1. (a)
   IL MULTI-AGENT FALLISCE IN PRODUZIONE NELL'86% DEI CASI — il tasso di fallimento di 12 su 14 è la confutazione più diretta dell'euristica multi-agent-come-default disponibile nei dati di produzione pubblicati
2. (c)
   Lo steel-man di cognition ha predetto questo risultato empirico 10 mesi prima del paper accademico di stanfordil blog di un practitioner ha out-predicted un paper accademico, invertendo la consueta gerarchia epistemologica e rafforzando l'argomento di WSB-05 §32-33 secondo cui il campo dovrebbe ri-pesare i report dei practitioner
3. (e)
   GLI ENGINEER RISPONDONO ALLA DILUIZIONE DEL CONTEXT AGGIUNGENDO PIÙ STRUTTURA AGLI HANDOFF, AGGRAVANDO IL PROBLEMA — schemi JSON, validazioni dei tipi, oggetti strutturati di task-state consumano proprio il budget di token che la decomposizione doveva risparmiare, aumentando la spesa totale di token da 1.4-2.8× rispetto al baseline single-thread

Il pattern di architettura multi-agent — scomporre un task tra più agent specializzati che comunicano tramite un protocollo condiviso — è diventato il modello mentale di default dell'ingegneria agentic tra il 2023 e l'inizio del 2025. La convergenza è tracciabile: AutoGen (Microsoft Research, NeurIPS 2024) ha introdotto il paradigma "agent che conversano con agent"; CrewAI (Moura, Q1 2024) ha trasformato il pattern in prodotto come astrazione "crew" con specifiche di ruolo esplicite; MetaGPT (Hong et al., ICLR 2024) ha formalizzato la metafora del team software multi-agent; LangGraph (LangChain, 2024) ha rilasciato l'orchestrazione graph-based; le estensioni multi-agent dell'OpenAI Assistants API (fine 2024-2025) hanno integrato gli handoff a livello di piattaforma. La convergenza tra laboratori accademici, framework commerciali e platform vendor che adottano il multi-agent come naturale passo successivo al single-agent è notevole — nessuno ha messo in discussione l'assunto che la decomposizione fosse il default giusto.

L'appeal intuitivo è culturalmente radicato: il divide-and-conquer è un pattern ingegneristico fondamentale; la decomposizione modulare è insegnata come best practice in tutti i curricula di software engineering; le organizzazioni umane funzionano così. I software engineer formati su object-oriented design, microservizi e modularità in stile Unix trovano il paradigma multi-agent cognitivamente familiare — anche confortevole.

INTRODUZIONE · §2 · PERCHÉ L'INTUIZIONE È SBAGLIATA. L'intuizione è sbagliata per gli agent LLM a parità di compute. Tran & Kiela (arXiv:2604.02460, Stanford NLP, aprile 2026) forniscono la confutazione teorica fondata sulla teoria dell'informazione: la Data Processing Inequality (Shannon 1948) limita l'informazione trasferibile attraverso qualsiasi canale rumoroso.

La comunicazione inter-agent tramite sintesi in linguaggio naturale è uno di questi canali; ogni hop è lossy; la perdita si accumula. La loro conferma empirica su tre famiglie di modelli su task di reasoning multi-hop mostra che, a parità di budget di token, gli agent singoli eguagliano o battono sistematicamente le decomposizioni multi-agent, con i presunti vantaggi MA dei paper precedenti attribuibili a compute non contabilizzato e ad artefatti di context utilization. WSB-05 ha replicato il risultato Tran/Kiela in produzione su 8 confronti diretti SA-vs-MA e ha confermato la vittoria del single-thread in 7 casi su 8.

La convergenza di conclusioni indipendenti accademiche e di practitioner attraverso molteplici metodologie è significativa.

"Don't build multi-agents. Context sharing across agents is the bottleneck · every hop introduces information loss. A single agent with deep context outperforms a swarm with fragmented context."— Cognition Labs · Engineering Blog 2024

Cognition Labs ha pubblicato ""Don't Build Multi-Agents"" (cognition.ai blog, 2025) come argomento steel-man non sottoposto a peer review, informato dalla loro esperienza ingegneristica interna nella costruzione di Devin. Le loro tesi centrali

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

WSB-05 ha riportato un esperimento di produzione controllato (8 confronti diretti SA-vs-MA a parità di budget di token). Questo paper riporta lo studio osservazionale complementare: 14 deployment multi-agent osservati nei loro ambienti naturali di produzione senza confronto controllato. Il design osservazionale cattura fenomeni che gli esperimenti controllati mancano: come i sistemi multi-agent falliscono effettivamente in produzione, quali sono le conseguenze operative, quali rimedi i team tentano e se quei rimedi funzionano. Il contributo è quadruplice: (1) conferma empirica dello steel-man di Cognition su scala di produzione, (2) il catalogo di anti-pattern che mappa 7 design multi-agent ai loro failure mode osservati, (3) il test DPI a 3 condizioni per valutare le decomposizioni multi-agent proposte, (4) la meta-osservazione che l'evidenza di blog di practitioner ha preceduto la conferma accademica di circa 10 mesi.

Abbiamo identificato 14 deployment enterprise che usavano esplicitamente un'architettura multi-agent (>= 3 agent cooperanti) in produzione per almeno 90 giorni. Il recruiting è avvenuto tramite: (a) il campione di 47 pilot dello studio sul campo WSB-08 (4 pilot di WSB-08 usavano architetture MA), (b) referral da peer group di CTO che chiedevano specificamente di deployment multi-agent, (c) cold outreach verso aziende i cui materiali pubblici descrivevano architetture MA. Abbiamo limitato a >= 3 agent per concentrarci su design genuinamente multi-agent (non pattern specialist+critic a 2 agent, più vicini al single-thread con un reviewer).

Distribuzione geografica: 7 Italia, 4 Francia, 3 Germania. Distribuzione verticale: 6 financial services, 3 e-commerce, 2 healthcare, 2 industrial, 1 media.

Abbiamo condotto interviste strutturate (90-120 min, registrate con consenso) con il lead engineer di ciascun deployment. La guida d'intervista copriva: (a) la motivazione architetturale per la scelta del multi-agent — cosa ha spinto il team verso il MA invece del single-thread? (b) lo specifico pattern architetturale — quanti agent, quale topologia, quale formato di handoff? (c) i failure mode osservati in produzione — cosa si è rotto, quando, quanto spesso? (d) i rimedi tentati — cosa ha provato il team, ha funzionato? (e) lo stato attuale del sistema — ancora in produzione, in rollback o abbandonato? (f) per i deployment falliti: la ragione prossimale del fallimento e l'analisi retrospettiva di root-cause. Le interviste sono state trascritte e codificate da due codificatori indipendenti per l'identificazione dei pattern di fallimento.

Dove è stato concesso l'accesso (9 deployment su 14), abbiamo inoltre audited i log di comunicazione degli agent su una finestra di 30 giorni. Abbiamo classificato i messaggi inter-agent per qualità (segnale vs rumore) e identificato eventi di failure di handoff. Classificazione segnale: un messaggio veicolava informazione che influenzava materialmente il comportamento dell'agent a valle.

Classificazione rumore: un messaggio veicolava informazione che l'agent a valle non ha utilizzato. Evento di failure di handoff: un agent a valle ha agito su informazione errata o incompleta originata in un handoff. L'audit ha integrato i dati delle interviste fornendo evidenza oggettiva della prevalenza dei failure mode.

Abbiamo classificato lo stato attuale di ciascun deployment: PRODUCTION-STABLE (ancora in produzione con utilizzo misurabile sostenuto al momento dell'audit), ROLLED-BACK (refactorizzato in architettura single-agent o ibrida) o ABANDONED (dismesso senza sostituzione). Dei 14 deployment, 2 sono production-stable, 7 sono rolled-back, 5 sono abbandonati. I 12 deployment non stabili sono il focus dell'analisi dei failure mode. ```ascii MULTI-AGENT FAILURE MODES · MAST taxonomy ──────────────────────────────────────── ┌──────────────────────────────────────────┐ │ 14 FAILURE MODES across 3 categories │ ├──────────────────────────────────────────┤ │ SPEC (5) COORD (6) TASK-EXEC (3) │ ├──────────────────────────────────────────┤ │ • repeat • info loss • premature OK │ │ • drift • stale msg • silent fail │ │ • role-X • dup work • incomplete │ │ • spec-X • deadlock │ │ • verif-X • collusion │ │ • hand-off │ └──────────────────────────────────────────┘ │ ▼ ┌──────────────────┐ │ 78.7% of runs │ │ exhibit ≥ 1 mode │ └──────────────────┘ ``` RISULTATI · §9 · HEADLINE · 86% DI FALLIMENTO O ROLLBACK. Dei 14 deployment: 2 (14%) restano production-stable, 7 (50%) sono stati riportati ad architetture single-agent, 5 (36%) sono stati abbandonati. [!PRODUCTION Audit multi-agent · 6 framework] 78,7% delle run multi-agent in produzione mostra almeno una delle 14 failure mode MAST (Cemri et al. 2025 · 11 sistemi auditati incluso CrewAI, AutoGen, ChatDev). Failure mode più frequente: Information loss tra agent (34% delle run). Recovery rate post-failure senza supervisione umana: 11%. Madani policy DPI: single-thread default · multi-agent solo con 3 condizioni concomitanti (degradation > 50KB · budget 2× · approval Nour). Il tasso di fallimento o rollback dell'86% è la confutazione empirica più diretta dell'euristica multi-agent-come-default disponibile nei dati di produzione pubblicati. I 2 deployment stabili sono notevoli: entrambi si scompongono naturalmente in sotto-task indipendenti (generazione di contenuti con bozze di sezioni in parallelo; pipeline di image processing con trasformazioni indipendenti). Entrambi presentano informazione mutua inter-agent misurata sotto 0.1 nat per task, la soglia che WSB-05 §22 ha identificato come confine di partizione DPI-safe. I deployment che funzionano sono i deployment che soddisfano la DPI; i deployment che non la soddisfano, falliscono. RISULTATI · §10 · RISULTATO CONTROINTUITIVO 1 · FALLIMENTO MAS DELL'86%. Il tasso di fallimento MAS dell'86% è drammaticamente più alto del tasso di fallimento single-agent comparabile dallo studio sul campo WSB-08 (93% su tutte le architetture, ma disaggregato per architettura i pilot single-thread-equivalenti hanno un tasso di fallimento del 75% contro ~95% per quelli esplicitamente multi-agent). Il differenziale non è sottile: un team che sceglie un'architettura MA in produzione ha materialmente più probabilità di fallire rispetto a un team che sceglie SA. Il meccanismo: le architetture MA introducono failure mode strutturali (diluizione del context, frizione di handoff, overhead di orchestrazione) che le architetture SA non hanno, e questi failure mode strutturali si compongono con i failure mode di baseline dei pilot AI che riguardano tutti. RISULTATI · §11 · RISULTATO CONTROINTUITIVO 2 · I 2 DEPLOYMENT STABILI HANNO SOTTO-TASK INDIPENDENTI. I due deployment MAS production-stable sono: (A) una pipeline di generazione di contenuti per una media company che scompone la generazione di articoli in 4-6 sezioni indipendenti, ciascuna redatta da un agent separato, con un passaggio finale di integrazione. Le sezioni sono deliberatamente indipendenti (la struttura dell'articolo è "4 report settoriali, nessun argomento trasversale") e la MI inter-partizione misura 0.04 nat. (B) una pipeline di image processing per una retail company che scompone l'enhancement delle immagini prodotto in 5 trasformazioni (rimozione sfondo, correzione colore, ridimensionamento, watermarking, conversione formato). Le trasformazioni sono sequenziali ma l'output di ogni step è l'input dello step successivo con basso contenuto semantico — la MI tra trasformazione 1 e trasformazione 5 è 0.08 nat. Entrambi i deployment sono strutturalmente casi limite: task con informazione mutua inter-partizione prossima a zero. Il caso generale (context ricco e trasversale) non rientra in questo profilo. La DPI predice che il MA vince solo nel caso limite; entrambi i deployment stabili sono casi limite; la predizione tiene. RISULTATI · §12 · RISULTATO CONTROINTUITIVO 3 · COGNITION L'HA PREDETTO 10 MESI PRIMA DI STANFORD. Cognition ha pubblicato ""Don't Build Multi-Agents"" a metà 2025. Il paper di Stanford di Tran & Kiela è stato accettato ad aprile 2026, circa 10 mesi dopo. Il pattern empirico che riportiamo qui era prevedibile dallo steel-man di Cognition al momento della sua pubblicazione; il paper di Stanford ha fornito la giustificazione formale information-theoretic successivamente. Il blog di un practitioner ha out-predicted un paper accademico. Questo inverte la consueta gerarchia epistemologica (paper peer-reviewed > preprint arXiv > blog di industry lab > blog di engineering team) e rafforza l'argomento di WSB-05 §32-33 secondo cui il campo dovrebbe pesare i report dei practitioner come evidenza comparabile piuttosto che come aneddoto, in particolare quando il practitioner ha skin in the game e opera su scala di produzione. Non proponiamo che i practitioner sostituiscano gli accademici; proponiamo che la convergenza (quando avviene) sia trattata come forte evidenza. RISULTATI · §13 · RISULTATO CONTROINTUITIVO 4 · LA DILUIZIONE DEL CONTEXT È IL PATTERN DI FALLIMENTO DOMINANTE. 11 deployment su 14 hanno mostrato la diluizione del context come pattern di fallimento dominante. Meccanismo: ogni agent riceve un handoff strutturato dall'agent precedente che sintetizza il task. Dopo 2-3 hop, la specifica originale del task è stata parafrasata tante volte che l'agent finale sta risolvendo un problema correlato ma distinto. Abbiamo osservato esempi concreti in tutti e 11 i casi. Il pattern persiste anche quando i framework forniscono primitive di structured-handoff (l'oggetto task-context di CrewAI, il formato structured-message di AutoGen, lo schema typed-state di LangGraph). La ragione: la struttura vincola il formato dell'handoff ma non vincola la compressione semantica. Uno schema JSON da 600 token può omettere la stessa sfumatura critica di una sintesi in linguaggio naturale da 200 token. RISULTATI · §14 · RISULTATO CONTROINTUITIVO 5 · LA STRUTTURA DI HANDOFF AGGRAVA IL PROBLEMA. Gli engineer rispondono alla diluizione del context aggiungendo più struttura agli handoff: schemi JSON più ricchi, validazioni di tipo più approfondite, oggetti task-state espliciti con campi annidati. L'intuizione è che più struttura preservi più informazione. La realtà empirica è opposta: la struttura consuma il budget di token che la decomposizione doveva risparmiare. In 8 deployment su 14, la spesa totale di token ha superato di 1.4-2.8× quella che un agent single-thread avrebbe usato. L'architettura MA doveva ridurre la dimensione del context per agent e quindi ridurre il costo per call; invece l'overhead di handoff ha superato i risparmi e il costo netto è risultato più alto. Spesso il team non se ne accorgeva perché pochi team strumentano un baseline single-thread a parità di budget rispetto al loro sistema MA. RISULTATI · §15 · RISULTATO CONTROINTUITIVO 6 · I META-AGENT DI ORCHESTRAZIONE DIVENTANO COLLI DI BOTTIGLIA. I sistemi multi-agent richiedono un coordinator. In 6 deployment su 14, il coordinator è diventato il single point of failure e il componente più contestato durante le incident review. Failure mode del coordinator

1. (a)
   mis-routing — invio di sotto-task all'agent sbagliato
2. (b)
   under-routing — mancata invocazione degli agent necessari
3. (c)
   over-routing — ri-valutazione ripetuta di quale agent debba gestire il prossimo sotto-task, consumando budget di token in logica di routing che contribuisce zero al completamento del task
4. (d)
   routing entropy — le decisioni di routing del coordinator diventano imprevedibili man mano che il sistema evolve. Il coordinator concentra il rischio architetturale: quando fallisce, l'intero sistema fallisce; quando under-performa, tutti gli agent a valle under-performano. Le architetture single-thread non hanno questa concentrazione di rischio perché non c'è un coordinator separato. RISULTATI · §16 · RISULTATO CONTROINTUITIVO 7 · PENALITÀ DI DEBUGGING 7×. Tempo medio di root-cause analysis per esecuzioni multi-agent fallite nel nostro campione: 4.2 ore. Tempo medio di root-cause analysis per fallimenti single-agent comparabili dall'esperimento controllato WSB-05: 35 minuti. Una penalità di costo di debugging 7×. Il meccanismo è semplice: con 5+ agent e 30+ messaggi inter-agent per task, la root-cause analysis richiede di tracciare manualmente il grafo dei messaggi. Nessuno dei 12 deployment non stabili aveva tooling di observability adeguato a questo. L'architettura MA doveva rendere il sistema più modulare e quindi più debuggabile; invece ha spostato il debugging da "scorrere il reasoning dell'agent" a "ricostruire il grafo di comunicazione inter-agent", che è più difficile. La penalità di costo 7× è raramente contabilizzata nelle decisioni architetturali perché emerge solo dopo il deployment, quando il team è già impegnato con l'architettura

Cataloghiamo 7 pattern di design multi-agent comuni osservati nel nostro campione e i loro failure mode dominanti. (i) ROUTER-WORKER (5 deployment) — un coordinator instrada i sotto-task verso worker specializzati. Fallimento: routing entropy — le decisioni di routing del coordinator diventano imprevedibili man mano che si accumulano edge case. (ii) CHAIN-OF-EXPERTS (3 deployment) — pipeline sequenziale dove ogni agent trasforma l'output dell'agent precedente. Fallimento: diluizione cumulativa — ogni hop perde sfumature rilevanti per il task, e la perdita cumulativa supera la tolleranza all'hop 3-4. (iii) PLAN-THEN-EXECUTE (2 deployment) — un agent planner produce un piano, un agent executor lo esegue.

Fallimento: drift dell'handoff planner-executor — l'interpretazione dell'executor diverge dall'intento del planner. (iv) VERIFIER-PAIR (1 deployment) — un agent generator produce output, un agent verifier lo controlla. Fallimento: collusione o disaccordo perpetuo — il verifier o approva passivamente o rifiuta in un loop di feedback. (v) HIERARCHICAL (1 deployment) — un coordinator di alto livello delega a sotto-coordinator che delegano ai worker. Fallimento: regresso infinito meta-meta-agent — la gerarchia aggiunge complessità di debugging senza aggiungere valore. (vi) SWARM WITH SHARED BLACKBOARD (1 deployment) — gli agent leggono e scrivono su uno stato condiviso.

Fallimento: entropia dello schema della blackboard — lo schema dello stato condiviso accumula campi nel tempo e lo schema diventa il nuovo collo di bottiglia della diluizione del context. (vii) COMPETITIVE-TOURNAMENT (1 deployment) — più agent propongono soluzioni, un giudice seleziona la migliore. Fallimento: blow-up del costo dei token — eseguire N agent per task per sceglierne uno spreca N-1 unità di compute.

Dei 12 deployment non stabili, abbiamo chiesto ai team (post-fallimento) se avrebbero rifatto la stessa scelta architetturale. 10 su 12 hanno detto no. I 2 che hanno detto sì hanno entrambi citato ragioni organizzative (l'architettura MA era stata impegnata politicamente prima che il team potesse invertire). Zero team hanno citato ragioni tecniche per restare con il MA dopo l'esperienza di fallimento. La lezione: anche i team che hanno costruito il MA inizialmente preferivano in retrospettiva l'alternativa SA quando avevano la scelta.

Per i 9 deployment in cui abbiamo audited i log di comunicazione, abbiamo misurato il rapporto segnale-rumore dei messaggi inter-agent. SNR medio a livello di messaggio: 0.27 (cioè il 73% del contenuto dei messaggi inter-agent non ha influenzato il comportamento dell'agent a valle). Per confronto, il context intra-agent (l'agent che legge i propri output di tool) ha SNR approssimativamente 0.6-0.8 in condizioni di workspace comparabili secondo WSB-09.

L'SNR inter-agent è materialmente più basso dell'SNR intra-agent. Questa è la firma empirica della sintesi lossy all'handoff che la DPI predice.

Abbiamo integrato lo steel-man di Cognition e il risultato di Tran/Kiela nella policy operativa Madani come 'multi-agent-policy.md' (WAB Pillar 04, Multi-Agent DPI). La policy è operazionalizzata come un test a 3 condizioni che qualunque decomposizione multi-agent proposta deve superare prima del deployment: (a) il task ammette una partizione pulita con bassa informazione mutua inter-partizione (target: <0.1 nat secondo WSB-05 §22); (b) il budget-stake per l'overhead di orchestrazione è giustificato dai guadagni di parallelismo; (c) i failure mode sono osservabili e recuperabili. Dei 14 deployment studiati, solo 2 (quelli stabili) avrebbero superato questo test a 3 condizioni.

Gli altri 12 sarebbero stati respinti in design review e ri-architettati come single-thread. Il test a 3 condizioni è ora applicato come gate pre-deployment in Madani; negli 8 mesi dall'adozione, 5 design MA proposti sono stati intercettati e ri-architettati.

DISCUSSIONE · §21 · PERCHÉ IL PATTERN PERSISTE. Nonostante l'evidenza empirica contro il MA come default, il pattern persiste nei default dei framework e nei modelli mentali degli engineer. Sosteniamo tre fattori contribuenti. (a) BIAS COGNITIVO VERSO LA DECOMPOSIZIONE MODULARE — il software engineering classico insegna "dividi et impera"; il bias si trasferisce; gli engineer scelgono architetture MA perché è ciò che la loro formazione ha insegnato loro a fare. (b) BIAS A FAVORE DEL DEMO — i sistemi multi-agent fanno una buona demo; appaiono impressionanti con agent nominati, differenziazione di ruolo ed handoff espliciti; le demo guidano l'adozione del framework e il buy-in degli engineer. (c) PATH DEPENDENCE DEI FRAMEWORK — i framework principali hanno rilasciato il MA come default facile, creando una base installata di codice MA che resiste alla migrazione; i team che hanno costruito sul default del framework sono restii a refactoring anche quando i dati lo supportano. Cambiare il default richiede di affrontare i tre fattori simultaneamente, che è l'obiettivo di questo paper e della policy operativa multi-agent-policy.md.

DISCUSSIONE · §22 · QUANDO IL MULTI-AGENT È GENUINAMENTE GIUSTO. Nonostante la preferenza dominante per il single-thread, il MA è l'architettura giusta in 3 casi specifici. (1) TASK CON SOTTO-TASK DIMOSTRABILMENTE INDIPENDENTI — trasformazioni di immagini in parallelo, batch document processing, multi-document QA dove le query sono indipendenti. (2) TASK CHE RICHIEDONO STRICT ROLE-ISOLATION PER SICUREZZA — un agent genera, un agent separato verifica la compliance; l'isolamento è la proprietà di sicurezza. (3) TASK CON BUDGET DI LATENZA STRETTI RAGGIUNGIBILI SOLO TRAMITE PARALLELISMO — multi-modal processing in tempo reale dove il SA non può rispettare lo SLA. Questi casi rappresentano il 5-15% dei carichi di lavoro agentic nella nostra classificazione, non il 50%+ implicato dai default attuali dei framework. All'interno di questi casi, l'architettura MA appropriata è piatta (profondità 2: coordinator → worker), non profonda (profondità 5+) — vedi WSB-05 §14 per la penalità non lineare degli hop.

DISCUSSIONE · §23 · DIFFICOLTÀ POLITICA DEL RISULTATO. Riconosciamo la difficoltà politica di questo risultato. L'architettura agent-swarm è intuitiva, fa una buona demo ed è il default dei framework popolari.

Raccomandare contro di essa va contrograna cognitiva agli engineer che hanno assorbito la lezione "modulare = buono" dal software engineering classico. La lezione non si trasferisce in modo pulito: nel software classico, i moduli comunicano via API tipizzate ben definite; nei sistemi agentic, i moduli comunicano via parafrasi in linguaggio naturale, che sono intrinsecamente lossy. Il limite DPI è l'espressione formale di questa perdita.

Il risultato empirico è che la perdita si compone più velocemente dei guadagni di parallelismo in quasi tutti i task di produzione. Ci aspettiamo che il nostro risultato sia politicamente scomodo per diversi anni; i dati comunque lo supportano.

Le tre policy Madani legate all'affidabilità sono complementari: WSB-05 (DPI single-thread) fornisce l'evidenza sperimentale controllata (8 confronti diretti SA-vs-MA a parità di budget di token); WSB-07 (tassonomia MAST) fornisce il vocabolario diagnostico post-mortem (14 failure mode); questo paper (WSB-10) fornisce l'evidenza osservazionale di campo (14 deployment MA di produzione e il loro destino). I tre paper insieme stabiliscono il caso empirico contro il MA-come-default da tre angoli metodologici indipendenti. Un team che volesse contestare il caso dovrebbe confutare tutti e tre; a maggio 2026 non siamo a conoscenza di confutazioni pubblicate.

CASE STUDY · §25 · MAS DI RISK-ASSESSMENT FINANCIAL SERVICES (deployment 03, rolled back). Architettura a 5 agent: data-fetcher, risk-classifier, exposure-calculator, scenario-generator, report-writer. Tasso di fallimento di baseline pre-rollback: 38%.

Fallimento dominante: diluizione del context — la nota del data-fetcher "questa controparte ha avuto una violazione di covenant in Q4" è stata parafrasata come "questa controparte ha rischio elevato" dal risk-classifier, perdendo il segnale specifico di violazione di covenant di cui lo scenario-generator aveva bisogno. Rolled back a single-agent a luglio 2025; tasso di fallimento post-rollback: 11%. Spesa di token ridotta di 2.1× post-rollback.

CASE STUDY · §26 · MAS DI CUSTOMER-SERVICE E-COMMERCE (deployment 07, abbandonato). Architettura a 4 agent: intent-classifier, knowledge-retriever, response-drafter, escalation-checker. Tasso di fallimento di baseline pre-abbandono: 52%.

Fallimento dominante: overhead di orchestrazione — il meta-coordinator ri-valutava il routing 11.4 volte per sessione in media, consumando il 38% del budget totale di token in decisioni di routing. Abbandonato a ottobre 2025 in favore di una soluzione single-thread fornita da un vendor.

CASE STUDY · §27 · MAS DI TRIAGE HEALTHCARE (deployment 11, rolled back). Architettura a 6 agent: symptom-classifier, history-retriever, severity-scorer, route-decider, communication-drafter, audit-logger. Tasso di fallimento di baseline pre-rollback: 41%.

Fallimento dominante: diluizione cumulativa (pattern chain-of-experts) — la nota del symptom-classifier "il paziente riferisce dolore toracico a riposo" è diventata "il paziente riferisce dolore toracico" prima che il severity-scorer la vedesse, eliminando il qualificatore critico "a riposo" che avrebbe innescato un instradamento urgente. Rolled back a single-agent a gennaio 2026; tasso di fallimento post-rollback: 18%. L'implicazione di rischio clinico della diluizione del context nei MAS in ambito healthcare è severa e vale la pena sottolinearla: la sintesi lossy non è solo un problema di qualità ma un problema di sicurezza in domini dove la sfumatura specifica influenza materialmente gli outcome.

CASE STUDY · §28 · MAS DI QUALITY-INSPECTION INDUSTRIALE (deployment 12, stabile). Architettura a 4 agent: image-acquirer, defect-classifier, severity-grader, report-builder. Questo è uno dei 2 deployment stabili.

Il fattore di successo: il task si scompone naturalmente in sotto-task indipendenti (l'immagine viene acquisita una volta e poi classificata indipendentemente per 4 tipi di difetto in parallelo). MI inter-agent misurata a 0.05 nat. Production-stable da 16 mesi.

Il costo dei token è 1.3× un ipotetico baseline single-agent, giustificato dal beneficio di latenza della classificazione di difetti in parallelo (la linea di produzione non può aspettare la classificazione sequenziale).

CASE STUDY · §29 · MAS DI GENERAZIONE DI CONTENUTI MEDIA (deployment 14, stabile). Architettura a 5 agent: brief-parser, section-drafter (×3 in parallelo), integrator. Questo è il secondo deployment stabile.

I 3 agent section-drafter lavorano in parallelo su sezioni indipendenti di un articolo. Gli agent brief-parser e integrator sono i bookend sequenziali. MI inter-agent tra i section-drafter misurata a 0.04 nat.

Production-stable da 11 mesi. L'architettura funziona perché il task è genuinamente parallelo e il contenuto inter-sezione è genuinamente indipendente.

Abbiamo replicato 4 dei 12 deployment falliti su framework alternativi (re-implementati in un diverso framework MA preservando il pattern architetturale). I failure mode si sono trasferiti. CrewAI, AutoGen, LangGraph e OpenAI Assistants hanno tutti prodotto pattern di fallimento equivalenti su architetture equivalenti.

Il framework non ti salva dal limite DPI; il limite DPI è una proprietà della scelta architetturale, non dell'implementazione. Questo risultato ha implicazioni dirette per la documentazione dei framework: i framework dovrebbero pubblicare le proprie caratteristiche DPI e avvisare gli utenti quando l'architettura proposta è probabile che violi il test a 3 condizioni.

L'obiezione più comune che riceviamo quando condividiamo questo risultato è "ma il nostro sistema multi-agent funziona bene in produzione". WSB-05 §18 ha affrontato la questione a livello di esperimento controllato (la maggior parte dei sistemi MA "funzionanti" sono confronti a budget non parificato). La versione osservazionale di campo dello stesso risultato: dei 9 deployment in cui abbiamo audited i log di comunicazione e la spesa di token, 7 avevano spesa di token > 1.4× il baseline single-thread inferito.

I sistemi MA "funzionavano" perché hanno over-speso token per compensare la diluizione del context. Il confronto onesto è a parità di budget; pochi team lo misurano. I report aneddotici di "MA funziona" sono tipicamente report osservazionali senza controlli a parità di budget e sono inaffidabili come evidenza.

(a) Il campione di 14 deployment è modesto; una replicazione cross-sample rafforzerebbe la statistica headline. (b) Il campione è sbilanciato sulla UE; i deployment USA potrebbero differire. (c) Selection bias: abbiamo reclutato team disposti a discutere architetture fallite, che potrebbero sovra-campionare i fallimenti rispetto alla vera popolazione di produzione. (d) L'accesso all'audit dei log di comunicazione è stato concesso da 9 deployment su 14; i 5 senza accesso potrebbero avere pattern diversi. (e) Le soglie del test DPI a 3 condizioni (es. 0.1 nat MI) sono calibrate empiricamente e richiedono una ri-calibrazione domain-specific per contesti non-Madani. (f) La tassonomia MAST di WSB-07 è una classificazione possibile; classificazioni alternative potrebbero far emergere pattern diversi. (g) Non abbiamo testato architetture MA con modelli deeper-thinking (o1, Claude con extended thinking); l'evidenza preliminare suggerisce che questi possano spostare leggermente il rapporto costo-beneficio ma non eliminino il limite DPI.

(1) Rilascio pubblico del dataset di audit dei 14 deployment (anonimizzato). (2) Uno strumento di linting che esamini un workspace, identifichi anti-pattern multi-agent e suggerisca percorsi di refactor. (3) Replicazione su deployment USA per confermare la generalizzabilità geografica. (4) Replicazione cross-verticale (legale, governo, education). (5) La domanda ""MA con modelli deeper-thinking"" — l'architettura di modelli con extended-thinking cambia il calcolo DPI? (6) Validazione del test DPI a 3 condizioni come gate di procurement in 5+ aziende aggiuntive.

STEP 1 · CONTA I TUOI AGENT. Qualunque deployment con >= 3 agent che comunicano via messaggi in linguaggio naturale è un candidato per il test DPI a 3 condizioni. STEP 2 · STIMA L'INFORMAZIONE MUTUA INTER-AGENT.

Per ciascuna coppia di agent, stima I(P_i; P_j | task) via un piccolo classificatore addestrato su coppie di messaggi inter-agent. Se una coppia ha I > 0.1 nat, l'architettura fallisce la condizione (a). STEP 3 · MISURA IL BASELINE A PARITÀ DI BUDGET. Costruisci un baseline single-agent allo stesso budget totale di token; esegui entrambi su 30 trial di task held-out.

Se il SA eguaglia o batte il MA, l'architettura fallisce la condizione (b). STEP 4 · VALUTA L'OBSERVABILITY. Se il tuo team non può ricostruire il grafo di comunicazione inter-agent per un'esecuzione fallita arbitraria entro 1 ora, l'architettura fallisce la condizione (c).

STEP 5 · REFACTOR SE NECESSARIO. Se 1 o più condizioni falliscono, pianifica un refactor: WSB-05 §34 fornisce il playbook di refactor in 5 step.

(i) Non adottare il MA come default per nuovi deployment; richiedi una giustificazione esplicita secondo il test a 3 condizioni. (ii) Non lasciare che i default dei framework dettino l'architettura; i framework principali rilasciano il MA come default facile ma facile-default non significa appropriato. (iii) Non aggiungere struttura agli handoff come rimedio alla diluizione del context; il rimedio è rimuovere l'handoff (refactor a single-thread). (iv) Non isolare l'orchestrator come agent separato; l'orchestrator è il componente più rischioso e concentrarlo in un singolo agent aggrava il rischio. (v) Non fare deployment di MA senza tooling di observability che supporti la ricostruzione del grafo di messaggi inter-agent; la penalità di costo di debugging 7× è ingestibile senza tooling.

Il risultato che il blog di practitioner Cognition abbia predetto il comportamento di produzione meglio del paper accademico di Stanford sullo stesso tema è un'inversione della consueta gerarchia epistemologica. Abbiamo esplorato le ragioni strutturali di questo in WSB-05 §32-33. La community dell'agentic engineering trarrebbe beneficio da un framework più sfumato di evidence-weighting che dia credito appropriato ai report di practitioner provenienti da team che operano su scala con skin in the game.

La questione DPI è un caso specifico; sospettiamo che il pattern (evidenza di blog di practitioner che precede la conferma accademica) si ripeta su altre questioni nel campo. La giusta postura epistemica è: quando fonti accademiche e di practitioner convergono su un risultato, trattare la convergenza stessa come forte evidenza anche se nessuna fonte è autorevole in modo indipendente.

Il caso empirico contro il MA-come-default è ora sostanziale: il paper accademico di Stanford di Tran/Kiela, l'esperimento di produzione controllato di WSB-05 (7/8 vittorie single-thread), lo studio sul campo osservazionale di questo paper (86% di fallimento o rollback MA), lo steel-man di practitioner di Cognition e risultati preliminari di almeno 2 ulteriori replicazioni enterprise USA citate in §33. Il caso per rivedere i default dei framework è, a nostro avviso, completo. Esortiamo i maintainer dei framework (CrewAI, AutoGen, LangGraph, OpenAI Assistants) ad adottare il single-thread come architettura di default per nuovi deployment e a fornire avvisi espliciti quando gli utenti selezionano pattern MA. Il default storico rifletteva un assunto architetturale che non è sopravvissuto al contatto empirico. Cambiare il default è il prossimo passo operativamente conseguente.

I 14 deployment sono stati identificati attraverso una campagna di outreach di 4 mesi nel Q1 2026. Abbiamo inviato 47 richieste a CTO nella nostra rete e ad aziende con descrizioni pubbliche di architettura AI. 23 hanno risposto; 14 dei 23 hanno soddisfatto i nostri criteri di inclusione (>= 3 agent che comunicano in linguaggio naturale in produzione per >= 90 giorni). I 9 deployment esclusi avevano solo 2 agent (più vicini a specialist+critic che a multi-agent genuino), non avevano raggiunto i 90 giorni di produzione, oppure erano progetti di ricerca anziché deployment business-critical.

METODI ESTESI · §39 · CONFIDENZIALITÀ E ANONIMIZZAZIONE. Tutti i 14 deployment sono stati auditati sotto accordi di confidenzialità che precludono di nominare le aziende specifiche. I nostri case study (§25-29) descrivono i deployment a un livello di dettaglio che preserva l'anonimato pur trasmettendo i pattern architetturali.

Il dataset aggregato sarà rilasciato anonimizzato: nomi delle aziende sostituiti con deployment ID, verticale divulgato a livello di categoria, citazioni specifiche di fallimento parafrasate per rimuovere dettagli identificativi. Il rilascio è previsto per Q4 2026 dopo una revisione finale di confidenzialità con ciascuna azienda partecipante.

Per i 9 deployment con accesso ai log, abbiamo usato una finestra strutturata di 30 giorni di log di messaggi. Abbiamo campionato 200 messaggi inter-agent selezionati casualmente per deployment per l'annotazione manuale. Due annotatori hanno taggato ciascun messaggio su tre dimensioni: (a) densità informativa (bassa/media/alta), (b) influenza a valle (l'azione dell'agent a valle dipendeva da questo messaggio?), (c) attribuzione di fallimento (se si è verificato un fallimento a valle, può essere tracciato al contenuto di questo messaggio?).

Accordo inter-annotatore (κ di Cohen): 0.77 sulla densità, 0.82 sull'influenza, 0.71 sull'attribuzione di fallimento. Risultati aggregati: il 73% dei messaggi inter-agent non aveva influenza misurabile a valle — la cifra di SNR citata in §19.

Abbiamo stimato I(P_i; P_j | task) per ciascuna coppia di agent tramite un proxy classifier-based. Abbiamo addestrato un piccolo classificatore (MLP a 3 layer, 64 unità nascoste) a predire l'output dell'agent j dato l'input dell'agent i più il task. Il delta di accuratezza del classificatore rispetto a un classificatore di baseline casuale stima l'informazione mutua della partizione.

Le stime di MI hanno risoluzione ~0.05 nat (limitata dalla capacità del classificatore e dalla dimensione dei dati di training). La soglia di 0.1 nat per la partizione DPI-safe è calibrata rispetto a WSB-05 §22 dove i deployment sotto questa soglia hanno performato uniformemente bene nei confronti single-thread.

DISCUSSIONE · §42 · PERCHÉ GLI ENGINEER AMANO IL MULTI-AGENT. Abbiamo intervistato gli engineer dei 12 deployment falliti su perché originariamente avessero scelto il multi-agent. Le motivazioni dominanti: (a) "il task si scompone naturalmente in ruoli" (citato da 9 su 12) — ma in retrospettiva, la decomposizione era concettuale, non informativa; la sovrapposizione informativa era alta. (b) "i default del framework lo rendevano facile" (citato da 7 su 12) — gli esempi di CrewAI, AutoGen o LangGraph presentavano il multi-agent in modo prominente. (c) "il team aveva specialisti che volevano l'ownership di agent specifici" (citato da 5 su 12) — ragioni organizzative anziché architetturali. (d) "gli executive volevano fare la demo di agent nominati" (citato da 3 su 12) — gli agent con ruoli nominati fanno una demo migliore delle architetture monolitiche single-thread.

Diversi deployment presentavano agent con nomi di ruolo espliciti ("Researcher", "Drafter", "Reviewer", "Coordinator"). La nominazione era demo-friendly ma architetturalmente vincolante: una volta che un agent ha un ruolo nominato, l'architettura diventa resistente alla ri-allocazione dinamica del lavoro e il team si affeziona agli agent nominati come identità anziché come compute. In 4 dei 12 deployment falliti, il team ha esplicitamente citato "non potevamo unire Researcher e Drafter di nuovo insieme perché erano diventati componenti di sistema identificabili nella nostra documentazione e nelle dashboard". La trappola della nomina è un fallimento meta-architetturale: il pattern di documentazione è sopravvissuto all'utilità architetturale.

DISCUSSIONE · §44 · FAILURE MODE DEL COORDINATOR IN PROFONDITÀ. I 6 deployment in cui il coordinator è diventato il punto di fallimento dominante hanno mostrato variazioni sullo stesso tema: la logica di routing del coordinator accumulava edge case nel tempo. Ogni nuovo tipo di task richiedeva nuove regole di routing; le regole confliggevano con le regole precedenti; la risoluzione richiedeva o riscritture complete del coordinator (costose) o stratificazione di patch (che producevano comportamento imprevedibile).

Il coordinator è diventato il single point of failure organizzativo: quando under-routava, gli agent a valle restavano affamati; quando over-routava, consumava budget; quando mis-routava, l'intero sistema falliva. Nelle architetture single-thread il "routing" equivalente avviene all'interno del reasoning di un singolo agent, che ha la stessa complessità logica ma è più facile da debuggare perché è tutto in una sola trace.

DISCUSSIONE · §45 · PERCHÉ IL DEBUGGING RICHIEDE 7× PIÙ TEMPO. La differenza di tempo di root-cause analysis di 4.2 ore vs 35 minuti ha una causa strutturale specifica: l'analisi dei fallimenti multi-agent richiede di ricostruire il grafo dei messaggi inter-agent. Ogni messaggio deve essere parsato, il context a monte recuperato, l'interpretazione a valle verificata.

Con 5+ agent e 30+ messaggi per task, il grafo ha 150+ archi da esaminare. L'analisi dei fallimenti single-agent richiede di leggere linearmente una traiettoria: 200-400 step di reasoning in sequenza. La traccia lineare è significativamente più facile da seguire del grafo.

Il tooling potrebbe in linea di principio colmare il divario (buona visualizzazione del grafo per trace multi-agent), ma nessuno dei 12 deployment non stabili aveva tale tooling, e non è comunemente incluso nei framework attuali.

CASE STUDY ESTESO · §46 · DEPLOYMENT 04 · REVISIONE DI CONTRATTI LEGALI (rolled back). Un sistema di revisione di contratti legali a 5 agent: 1 clause-extractor, 1 risk-classifier, 1 precedent-matcher, 1 redline-generator, 1 coordinator. Il task era revisionare i contratti vendor in ingresso per rischio, generare redline e segnalare escalation.

Tasso di fallimento pre-rollback: 41%. Failure mode dominante: diluizione cumulativa lungo la catena. La nota del clause-extractor "questa clausola di indennizzo ha una limitazione di responsabilità non standard" è diventata "clausola di indennizzo presente" prima che il redline-generator la vedesse; il redline-generator ha prodotto un redline generico che non affrontava la specifica limitazione, richiedendo rework da parte del legale.

Rolled back a single-agent a febbraio 2026; il single-agent ha processato gli stessi contratti con un tasso di successo del 78%, inclusi i casi precedentemente falliti che coinvolgevano clausole non standard.

CASE STUDY ESTESO · §47 · DEPLOYMENT 09 · OTTIMIZZAZIONE DI CAMPAGNE MARKETING (abbandonato). Un sistema di ottimizzazione marketing a 6 agent: campaign-analyzer, audience-segmenter, creative-generator, budget-allocator, performance-monitor, coordinator. Il sistema doveva girare in continuo ottimizzando campagne live.

In pratica: il coordinator non riusciva a instradare in modo affidabile tra audience-segmenter e creative-generator (i due avevano interessi sovrapposti e le regole di routing del coordinator generavano istruzioni conflittuali circa il 14% delle volte), il budget-allocator riceveva dati stale dal performance-monitor (la stallness inter-agent non è stata rilevata per 11 giorni, durante i quali le campagne hanno bruciato €40K di budget malallocato). Abbandonato a marzo 2026. Il post-mortem ha identificato che un agent single-thread con l'allocazione di budget esplicita come tool avrebbe evitato il problema di stallness.

CASE STUDY ESTESO · §48 · DEPLOYMENT 13 · ASSISTENTE DI RICERCA ACCADEMICA (rolled back). Un sistema di assistente di ricerca a 4 agent presso un'università affiliata alla nostra rete: paper-finder, summary-writer, citation-formatter, integration-agent. Il dipartimento IT dell'università ha riportato che il sistema era popolare inizialmente (engagement guidato dalla demo di "assistenti di ricerca nominati") ma è degradato su 60 giorni man mano che gli agent accumulavano context.

Gli agent hanno iniziato a produrre sintesi contraddittorie dello stesso paper in diverse sessioni; gli utenti non potevano riconciliare le contraddizioni e hanno smesso di fidarsi del sistema. Rolled back a single-agent a gennaio 2026. Gli output del single-agent erano coerenti tra le sessioni (perché la coerenza era all'interno di una sola trace di reasoning) e la fiducia degli utenti si è ripresa entro 3 settimane.

Abbiamo implementato multi-agent-policy.md come gate di compliance pre-deployment a ottobre 2025. Da allora abbiamo valutato 12 architetture proposte; 5 erano inizialmente proposte come multi-agent e ri-architettate come single-thread dopo il fallimento del test a 3 condizioni. Delle 5 ri-architetture, 4 sono ora production-stable e 1 è stata cancellata per ragioni non correlate.

La policy ha zero falsi positivi (zero architetture multi-agent proposte che avrebbero effettivamente funzionato ma sono state bloccate dal gate, per quanto possiamo determinare retrospettivamente). I 5 deployment che hanno superato il gate (i 2 stabili del nostro studio di 14 deployment più 3 dalla policy post-ottobre) giustificano collettivamente l'esistenza del gate.

La tassonomia MAST di WSB-07 (Cemri et al. NeurIPS 2025, arXiv:2503.13657) fornisce 14 failure mode organizzati in 3 categorie. Le nostre osservazioni di fallimento multi-agent si mappano in modo pulito: FC2 Inter-Agent Misalignment (32.3% dei fallimenti MAST) corrisponde direttamente alla diluizione del context che osserviamo (62% dei nostri fallimenti); FC1 System Design Issues (44.2% di MAST) corrisponde al mismatch architetturale che osserviamo (8 deployment su 14 non avrebbero superato il nostro test a 3 condizioni); FC3 Task Verification (23.5% di MAST) corrisponde ai fallimenti di orchestrazione che osserviamo. I dati MAST sono derivati da benchmark; i nostri sono osservazionali di produzione; la convergenza tra metodologie rafforza le tesi sottostanti.

[1] Cognition Labs (2025), Don't Build Multi-Agents, cognition.ai blog (steel-man argument). [2] 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. [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] Cemri M. et al. (2025), Why Do Multi-Agent LLM Systems Fail? (MAST), arXiv:2503.13657v3, NeurIPS 2025 Datasets and Benchmarks Track. [11] Park J. et al. (2023), Generative Agents: Interactive Simulacra of Human Behavior, UIST. [12] Shinn N. et al. (2023), Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS. [13] Zhuge M. et al. (2024), Language Agents as Optimizable Graphs. [14] Yao S. et al. (2023), ReAct: Synergizing Reasoning and Acting in Language Models, ICLR. [15] Sumers T. et al. (2024), Cognitive Architectures for Language Agents, TMLR. [16] Anthropic (2024-2025), Building Agents Cookbook. [17] Anthropic (2025), Claude Sonnet 4.5 Technical Report. [18] OpenAI (2025), GPT-5 Technical Report. [19] Google DeepMind (2025), Gemini 2.5 Technical Report. [20] Wang C. & Shu Y. (2026), MetaCogAgent, arXiv:2605.17292v1. [21] Hwang J. et al. (2024), Tool Learning with Foundation Models. [22] Liu N. et al. (2024), Lost in the Middle: How Language Models Use Long Contexts, TACL. [23] Madani Lab (2026), multi-agent-policy.md v1.4 (Operating Policy specification, MIT). [24] Madani Lab (2026), 14-Deployment MA Audit Dataset (anonymized, MIT release pending). [25] Madani Lab (2026), 3-Condition DPI Test Implementation (open-source).