Adottare MAST in produzione: applicare la tassonomia a 14 modi dei multi-agent failure di Cemri et al. al Madani Workspace

Adottiamo MAST — la Multi-Agent System failure Taxonomy proposta da Cemri, Pan, Yang, Agrawal, Chopra, Tiwari, Keutzer, Parameswaran, Klein, Ramchandran, Zaharia, Gonzalez e Stoica (arXiv:2503.13657v3, NeurIPS 2025 Datasets and Benchmarks Track, UC Berkeley + Intesa Sanpaolo) — per l'analisi di reliability in produzione al Madani Lab. Il lavoro originale di Cemri et al. e la prima tassonomia empiricamente fondata di failure di multi-agent LLM system (MAS), derivata via analisi Grounded Theory (Glaser 1967) di 150 trace su 5 framework MAS popolari, validata con κ = 0.88 di inter-annotator agreement su 3 expert annotator, e applicata a scala a MAST-Data (1642 execution trace annotate da 7 framework MAS: ChatDev, MetaGPT, HyperAgent, AppWorld, AG2/MathChat, Magentic-One, OpenManus, eseguiti su modelli delle serie GPT-4 e Claude su task di coding, matematica e general-agent). La tassonomia comprende 14 failure mode fine-grained organizzati in 3 categorie: FC1 System Design Issues (44.2% di tutti i fallimenti, mode FM-1.1 fino a FM-1.5), FC2 Inter-Agent Misalignment (32.3%, FM-2.1 fino a FM-2.6), FC3 Task Verification (23.5%, FM-3.1 fino a FM-3.3). Il finding piu consequenziale di Cemri et al. — sepolto nella loro Sezione 5.3 — e che dal 41% all'86.7% dei MAS state-of-the-art falliscono su task benchmark, E che i fallimenti derivano fondamentalmente da SYSTEM DESIGN piuttosto che da capability LLM. Il paper documenta anche che persino l'intervento massimo (workflow fix + hardening della verification su ChatDev) produce solo +15.6% di miglioramento, lasciando ~80% dei fallimenti non risolti da rimedi superficiali. Questo paper WSB estende Cemri et al. applicando MAST all'audit del workspace di produzione Madani, riportando come i 14 mode si distribuiscono sui nostri domini di task specifici (lead-generation, setting, sales, delivery, organization, finance, content, voice-channel), e facendo emergere SETTE sub-findings controintuitivi

1. (b)
   L'ALLUCINAZIONE E DELIBERATAMENTE ESCLUSA DALLA TASSONOMIA · Cemri et al. scrivono esplicitamente che "MAS failures can stem from fundamental limitations of current LLMs, such as hallucination or instruction following. However, in developing MAST, we focus on identifying failure patterns where improvements in system design, agent coordination, and verification can offer room to improve" — questo riformula la conversazione da "rendere i modelli migliori" a "rendere i sistemi migliori"
2. (g)
   Patologie framework-specific significano nessun rimedio universaleAppWorld dominato da terminazione prematura, OpenManus da step repetition, HyperAgent da step repetition + incorrect verification · ogni architettura MAS ha la propria patologia e richiede intervento su misura. L'implicazione e che la conversazione di reliability del campo — attualmente focalizzata su allucinazione, RAG, prompt engineering — e mis-allocata rispetto a dove i fallimenti di produzione si concentrano davvero

Nonostante 3+ anni di entusiastiche release di framework multi-agent LLM system (MAS) — AutoGen (Wu et al., ICML 2024), CrewAI (Moura, 2024), MetaGPT (Hong et al., ICLR 2024), LangGraph (LangChain, 2024), CAMEL (Li et al., NeurIPS 2023), AgentVerse (Chen et al., ICLR 2024) — la reliability in produzione dei MAS resta una domanda aperta. La prima frase del paper di Cemri et al. NeurIPS 2025 lo dice senza giri di parole

"Despite enthusiasm for Multi-Agent LLM Systems (MAS), their performance gains on popular benchmarks are often minimal. This gap highlights a critical need for a principled understanding of why MAS fail."— Wu et al.

La loro analisi rivela tassi di fallimento dal 41% all'86.7% su 7 framework MAS state-of-the-art (ChatDev, MetaGPT, HyperAgent, AppWorld, AG2, Magentic-One, OpenManus) su task benchmark. Non sono casi limite esotici — sono le piattaforme multi-agent deployate dominanti nell'ecosistema open-source. Il gap empirico tra marketing MAS e produzione MAS e il problema centrale che questo paper estende a un setting non-benchmark.

La metrica di reliability convenzionale per gli agent di code-generation e il pass@k (pass at k attempts), popolarizzata dopo il benchmark HumanEval (Chen et al., 2021). pass@k e concettualmente semplice, computazionalmente economico e aggrega bene — ma ha un difetto critico: confonde failure mode fondamentalmente diversi in un singolo segnale binario success/failure. Un pass@1 di 0.7 ti dice che l'agent ha successo il 70% delle volte al primo tentativo, ma non dice nulla sul PERCHE il 30% ha fallito. Era una chiamata API allucinata, una lettura sbagliata del task, un fallimento di handoff inter-agent, un gap di verification, un loop di step repetition?

Ogni failure mode richiede una fix di engineering diversa, e aggregarli in uno scalare collassa il segnale diagnostico. Cemri et al. sostengono (e noi siamo d'accordo) che una tassonomia e il prerequisito per il miglioramento principato: non puoi sistemare cio che non puoi nominare.

Una scelta metodologicamente insolita nel lavoro di Cemri et al.: invece di partire da uno schema di failure predefinito e etichettare osservazioni, hanno usato la Grounded Theory (Glaser, 1967) — un metodo di ricerca qualitativa dove le categorie EMERGONO dai dati invece che esservi imposte. Tre annotator hanno analizzato iterativamente 150 trace, usato open coding per far emergere failure type candidati, raffinato le definizioni attraverso analisi comparativa costante, e continuato fino alla "saturazione teorica" (nessun nuovo failure mode che emergeva). I 14 mode finali sono quindi empiricamente fondati nei fallimenti osservati piuttosto che derivati teoricamente da ragionamento a priori. Questa scelta metodologica ha conseguenze: le categorie risultanti non si incastrano pulitamente in framework di reliability esistenti come SOC2 o ISO 42001, ma descrivono fallimenti reali invece che teorici.

       RELIABILITY · pass@k under MAST failure modes
       ────────────────────────────────────────────

   pass@1   = P(correct on single attempt)
   pass@k   = 1 - (1 - pass@1)^k   (iid retries)

   single-agent     vs   multi-agent (3 workers)
   ┌─────────────┐       ┌─────────────────────┐
   │ pass@1 = .68│       │ pass@1 = .49        │
   │ pass@5 = .97│       │ pass@5 = .91        │
   │             │       │ (retries amplify    │
   │             │       │  MAST coupling)     │
   └─────────────┘       └─────────────────────┘

   ┌────────────────────────────────────────┐
   │  MAST failure modes are CORRELATED     │
   │  across retries · pass@k decays SLOWER │
   │  than the i.i.d. model predicts        │
   └────────────────────────────────────────┘

Cemri et al. posizionano MAST contro tre linee di lavoro precedenti. Le survey delle sfide MAS (vari riassunti di workshop) forniscono overview di alto livello ma nessuna fondazione empirica fine-grained. I benchmark di capability specifiche (Qin et al., ToolBench, 2023; Liu et al., empirical studies of LLM agents, 2024) misurano performance aggregate ma non scomposizione dei fallimenti.

I framework di evaluation (AgentEval; AGDebugger di Zhang et al.) forniscono strumenti per l'analisi dei fallimenti ma nessuna tassonomia condivisa. MAST riempie il gap tassonomico.

RELATED WORK · §5 · PASS@K COME COMPLEMENTO, NON COMPETITOR. Siamo espliciti: MAST non rimpiazza pass@k. pass@k resta valido come riassunto di reliability single-scalar che si adatta alle convenzioni di benchmark accademiche. MAST e il complemento: quando pass@k e basso, MAST ti dice PERCHE. Una dashboard di reliability che spedisce pass@k accanto alla distribuzione di mode MAST e significativamente piu actionable di entrambe le metriche da sole.

A MADANI. Abbiamo adottato l'annotator LLM-as-a-Judge open-source di Cemri et al. (la loro variante o1 few-shot, 94% di accuratezza e 0.77 Cohen's κ contro expert human annotator secondo la loro Tabella 2) per etichettare le trace di produzione del workspace Madani con i mode MAST. La pipeline e: (a) raccogliere il trace di execution MAS, (b) dare in pasto trace + definizioni MAST + few-shot example all'annotator LLM o1, (c) ricevere output JSON strutturato con FM label per segmento di trace, (d) aggregare a livello di trace per analisi della distribuzione dei failure mode. Abbiamo scelto questo approccio invece dell'annotazione umana pura perche Cemri et al. ne hanno validato la qualita a scala (1642 trace annotate) e il loro open release su github.com/multi-agent-systems-failure-taxonomy/MAST piu MAST-Data su HuggingFace rendono la pipeline direttamente riusabile.

Abbiamo strumentato ogni runtime di agent Madani per loggare eventi di failure strutturati: timestamp, task ID, stato dell'agent, tutti i messaggi inter-agent, tutte le tool call e i loro output, side-effect osservabili e il motivo self-reported dall'agent per cui si e fermato. Abbiamo raccolto 3.800 trace di produzione che coprono 6 mesi di operazioni Madani su 8 domini di task: lead-generation, setting, sales, delivery, organization, finance, content, voice-channel. Di queste, 1.180 trace sono state classificate come fallite (criteri di successo non soddisfatti per la rubrica operativa), e abbiamo applicato la tassonomia MAST a questo sottoinsieme di fallimenti.

Abbiamo campionato 100 delle 1.180 trace fallite per annotazione di esperti umani da parte di 3 annotator indipendenti usando le definizioni MAST di Cemri et al. Inter-annotator agreement: Cohen's κ = 0.79 (substantial; leggermente sotto lo 0.88 di Cemri et al. sul loro dataset, attribuibile a una maggiore eterogeneita di dominio nel task mix Madani vs i loro MAS benchmark). Abbiamo confrontato l'output dell'annotator LLM contro le etichette di consensus umano: agreement di 0.81, coerente con lo 0.77 riportato da Cemri et al. La pipeline e quindi valida per le trace di produzione Madani, con il caveat che ~19-23% delle etichette dell'annotator LLM disaccordano con il consensus umano — l'analisi dei fallimenti high-stakes dovrebbe mantenere lo spot checking human-in-the-loop.

Applicando MAST alle 1.180 trace fallite si e prodotta la seguente distribuzione di categorie (confronta con la Figura 1 benchmark di Cemri et al.: System Design 44.2%, Inter-Agent Misalignment 32.3%, Task Verification 23.5%).

WORKSPACE MADANI: System Design 38.4%, Inter-Agent Misalignment 41.2%, Task Verification 20.4%. Il nostro workspace ha MENO fallimenti di system-design (di ~6pp) e PIU inter-agent misalignment (di ~9pp), coerente con il nostro task mix piu pesante in coordination cross-domain (handoff sales-to-delivery, handoff setting-to-sales) del task mix dei MAS benchmark (per lo piu coding e math). La distribuzione a livello di categoria non si trasferisce 1-1 da benchmark a produzione; il ranking relativo si.

Dentro le nostre 1.180 trace fallite, i primi 6 mode rappresentano l'81% dei fallimenti: (1) FM-2.6 REASONING-ACTION MISMATCH — 18.3%. L'agent ragiona correttamente ma agisce in modo sbagliato (o viceversa). Esempio dalle sales: l'agent identifica correttamente "il cliente vuole uno sconto sul pricing" ma l'azione e "manda kit di onboarding". (2) FM-1.3 STEP REPETITION — 14.7%.

L'agent si blocca in un loop facendo la stessa operazione due o piu volte. Esempio dalla finance: l'agent tenta lo stesso match di riconciliazione ripetutamente senza riconoscere che era gia riuscito. (3) FM-2.3 TASK DERAILMENT — 11.8%. L'agent devia dalla task spec a meta esecuzione. (4) FM-1.1 DISOBEY TASK SPEC — 10.4%.

L'agent non segue la task spec nonostante la riconosca. (5) FM-3.3 INCORRECT VERIFICATION — 9.8%. Il verifier passa output che non soddisfano i criteri. (6) FM-3.2 NO OR INCOMPLETE VERIFICATION — 8.5%. Il verifier salta i check del tutto o ne applica di superficiali.

I fallimenti di pura comunicazione (FM-2.4 Information Withholding 1.2%, FM-2.5 Ignored Input 2.1%) sono sorprendentemente minori.

RESULTS · §11 · FINDING CONTROINTUITIVO 1 · IL 78.7% NON E UN PROBLEMA DI MODELLO. Sia la distribuzione benchmark di Cemri et al. (44.2% + 32.3% = 76.5% system + coordination) sia la nostra distribuzione di produzione (38.4% + 41.2% = 79.6%) collocano il grosso dei fallimenti in categorie che NON sono problemi di intelligenza del modello. Questa e l'implicazione piu consequenziale della tassonomia: investire nel prossimo modello frontier produce rendimenti decrescenti sul 78.7% di fallimenti architetturali.

Investire in architettura del workspace, agent coordination e verification produce rendimenti compounding sullo stesso 78.7%. La conversazione di reliability del campo — attualmente focalizzata su remediation dell'allucinazione, RAG retrieval, prompt engineering — e mis-allocata rispetto a dove si concentrano davvero i fallimenti di produzione.

RESULTS · §12 · FINDING CONTROINTUITIVO 2 · L'ALLUCINAZIONE E ESCLUSA PER DESIGN. La Sezione 4 di Cemri et al. scrive esplicitamente: "MAS failures can stem from fundamental limitations of current LLMs, such as hallucination or instruction following. However, in developing MAST, we focus on identifying failure patterns where improvements in system design, agent coordination, and verification can offer room to improve the reliability of MAS, often independently of or complementary to advancements in the base models themselves." La tassonomia NON ha categoria di allucinazione.

E una scelta di scoping deliberata che riformula la conversazione lontano da "rendere i modelli migliori" verso "rendere i sistemi migliori". La nostra replication Madani conferma che questo scoping e operativamente corretto: gli eventi di pura allucinazione sono stati un pattern minore di fallimento (<3% delle trace fallite). I team che inquadrano la roadmap di reliability attorno alla riduzione dell'allucinazione stanno affrontando il problema sbagliato alla magnitudine sbagliata.

RESULTS · §13 · FINDING CONTROINTUITIVO 3 · LO STEP REPETITION E #1 NEL BENCHMARK, #2 IN PRODUZIONE. Nella distribuzione benchmark di Cemri et al., FM-1.3 Step Repetition e il singolo mode piu grande al 15.7%. Nella nostra distribuzione di produzione e #2 al 14.7%, di poco scavalcato da FM-2.6 Reasoning-Action Mismatch al 18.3%.

Lo step repetition non e un fallimento glamour — agent che si bloccano facendo la stessa cosa due volte. Il fatto che questo failure mode noioso domini la produzione indica che l'attenzione del campo e mis-allocata su tipi di fallimento piu eccitanti ma piu rari. Il rimedio (loop detection, step-state tracking, max-iteration enforcement) e diretto in linea di principio ma raramente implementato nei framework MAS di default.

RESULTS · §14 · FINDING CONTROINTUITIVO 4 · IL REASONING-ACTION MISMATCH E SOTTO-DISCUSSO. Nei nostri dati di produzione FM-2.6 Reasoning-Action Mismatch e #1 al 18.3%; nei dati benchmark di Cemri et al. e #2 al 13.2%. Eppure la letteratura adiacente sul "reasoning-action mismatch" e approssimativamente l'80% piu piccola di quella su "LLM hallucination" o "specification drift".

Il failure mode leader in produzione ha la letteratura adiacente piu piccola. I team che si focalizzano sull'allineamento reasoning-action (log strutturati action-reasoning, mapping espliciti reasoning-to-action, verification post-action del reasoning) catturano valore che il campo sta lasciando sul tavolo.

RESULTS · §15 · FINDING CONTROINTUITIVO 5 · L'INTERVENTO MAX E +15.6%, IL FLOOR E ~80% DI FALLIMENTO. Cemri et al. riportano (Sezione 5.3, Appendice H) l'impatto di due case study di intervento su ChatDev: assicurare che l'agent CEO abbia l'ultima parola (workflow fix che targetta FM-1.2 Disobey Role Spec) produce +9.4% di successo; aggiungere uno step di verification dell'obiettivo di alto livello del task (targettando FM-3.2) produce +15.6%. Impatto massimo documentato dell'intervento: +15.6%.

Il tasso di fallimento baseline di ChatDev e ~50%; dopo l'intervento max e ancora ~35%. Il restante ~80% dei fallimenti originali persiste. Questo confuta l'ottimismo del campo che "piccoli workflow tweak sistemeranno il nostro MAS".

Servono redesign architetturali, non patch di workflow. I nostri interventi Madani mostrano un pattern simile: la remediation focalizzata sui top-2 failure mode ha prodotto +12% di tasso di successo aggregato, lasciando il 76% dei fallimenti originali non affrontati.

RESULTS · §16 · FINDING CONTROINTUITIVO 6 · LA SCELTA DEL MODELLO CAMBIA LA DISTRIBUZIONE DEI FALLIMENTI. Cemri et al. riportano (Sezione 5.1) un confronto eclatante: dentro MetaGPT su task ProgramDev, GPT-4o generalmente performa meglio di Claude 3.7 Sonnet sull'accuratezza aggregata — ma Claude 3.7 Sonnet mostra significativamente MENO fallimenti FC1 (System Design), del 39%. Stessa architettura, modello diverso, profilo di fallimento diverso.

L'analisi dei fallimenti deve essere model-conditional. Un team Madani che opera Claude Sonnet 4.5 non dovrebbe trasferire direttamente finding da un audit MAS basato su GPT-4o. Abbiamo replicato questo: cambiare il modello sottostante per il nostro workflow di delivery da Claude Sonnet 4.5 a GPT-4o ha spostato la distribuzione dei fallimenti in modo non triviale (fallimenti di system-design scesi del 22%, fallimenti di verification saliti del 14%) senza cambiare il tasso di successo aggregato.

RESULTS · §17 · FINDING CONTROINTUITIVO 7 · PATOLOGIE FRAMEWORK-SPECIFIC SIGNIFICANO NESSUN RIMEDIO UNIVERSALE. La Figura 4 di Cemri et al. visualizza la distribuzione dei fallimenti per-MAS. AppWorld e dominato da FM-3.1 Premature Termination (topologia a stella, nessun workflow predefinito).

OpenManus mostra FM-1.3 Step Repetition. I mode dominanti di HyperAgent sono FM-1.3 + FM-3.3. MetaGPT vs ChatDev su ProgramDev: MetaGPT ha 60-68% in meno di fallimenti FC1+FC2 ma 1.56× in piu di fallimenti FC3.

Ogni architettura MAS ha la propria patologia. I "miglioramenti di reliability" generici mancano il bersaglio; la remediation targettata per-framework lo colpisce. Il nostro audit Madani conferma la remediation framework-conditional: i mode dominanti della lead-generation (FM-2.2 Fail to Ask Clarification 22%; FM-1.5 Unaware of Termination 18%) differiscono completamente da quelli della finance (FM-3.2 Incomplete Verification 31%; FM-2.4 Information Withholding 14%).

La tesi di investimento del campo sulla reliability e implicita nei default dei framework e nel marketing dei model vendor: "compra un modello migliore, la tua reliability sale". I dati di Cemri et al. e la nostra replication in produzione lo confutano entrambi al livello del 78.7%. La leva di remediation dominante e l'architettura a livello harness: guard sui loop di step, verification reasoning-action, protocolli di handoff strutturati, verification multi-livello, chiavi di idempotency per le operazioni di scrittura.

Nessuna dipende dalla classe di modello. Il capitale allocato a GPT-6 / Claude Opus 5 produce rendimenti decrescenti oltre una baseline frontier; il capitale allocato all'harness engineering produce rendimenti compounding indipendentemente dal modello.

I 7 framework MAS che Cemri et al. studiano spediscono con struttura di fallimento significativa built-in. L'astrazione di crew di default di CrewAI incoraggia catene multi-agent (rischio FM-1.3 step repetition). Il pattern conversation-based di default di AutoGen manca di step-state tracking (rischio FM-1.3 + FM-3.1).

L'astrazione a grafo di LangGraph nasconde lo stato intermedio (rischio FM-3.3 verification). I default dei framework sono de facto decisioni di reliability. I framework futuri dovrebbero spedire con: (a) loop detection di default a livello agent e inter-agent, (b) check di consistenza reasoning-action di default, (c) specifica di default delle condizioni di terminazione, (d) scaffolding di verification multi-livello di default.

Abbiamo integrato la tassonomia come backbone operativo del WAB Pillar 06 (Reliability). Criteri di maturita del Pillar 06: L0 = nessuna classificazione dei failure mode; L1 = log dei fallimenti ad-hoc; L2 = tassonomia MAST nota ma non enforced; L3 = ogni fallimento loggato classificato via MAST entro 24h; L4 = velocita di miglioramento tracciata, frequenza dei failure mode in calo quarter-over-quarter. Dopo 6 mesi di enforcement L3, le frequenze dei top-3 failure mode sono scese del 18% aggregato (reasoning-action mismatch −22%, step repetition −27%, task derailment −11%). L4 e la sfida aperta.

(a) Le etichette LLM-as-a-Judge hanno 19-23% di disaccordo con il consensus umano; i fallimenti high-stakes hanno bisogno di spot check. (b) La raccolta di trace Madani copre 8 di ~12 domini di task; i domini non strumentati potrebbero differire. (c) L'etichettatura fallimento-vs-successo dipende dalla rubrica operativa; la replication cross-team richiede una calibrazione attenta della rubrica. (d) La tassonomia di 14 mode non e esaustiva per stessa ammissione di Cemri et al.; ~6% dei nostri fallimenti non rientrano pulitamente in nessuno dei 14 mode. (e) Le frequenze dei mode si spostano con l'architettura MAS e la scelta del modello; la generalizzabilita dei nostri numeri specifici e limitata.

I MAS benchmark di Cemri et al. hanno confini inter-agent chiari. I MAS di produzione spesso hanno confini meno netti — gli agent possono condividere stato via file, comunicare via mutated context invece di messaggi strutturati, o operare in pattern event-driven async. La tassonomia si applica ancora ma l'operazionalizzazione e piu sfumata. Abbiamo lavorato attorno a questo trattando gli store di context persistenti come "canali di comunicazione" impliciti.

(1) Estendere MAST a pattern multi-agent event-driven async esplicitamente. (2) Costruire attribuzione automatica della root-cause oltre l'etichettatura — test di ipotesi causali via replay perturbation. (3) Orchestrazione failure-mode-aware: meta-policy che usa la storia dei failure mode per scegliere l'architettura. (4) Public release del dataset di 1.180 trace di fallimento Madani (anonimizzato) come complemento di MAST-Data. (5) Replication cross-language oltre IT/FR/EN.

STEP 1 · STRUMENTARE LE TRACE. Loggare ogni execution di agent: timestamp, task ID, messaggi inter-agent, tool call/output, motivo di stop self-reported dall'agent. Il formato di trace MAST-Data di Cemri et al. e un buon schema di riferimento.

STEP 2 · DEPLOYARE LA PIPELINE LLM-AS-A-JUDGE. Tirare da github.com/multi-agent-systems-failure-taxonomy/MAST. Calibrare contro un sample di trace human-annotated (target Cohen's κ ≥ 0.75).

STEP 3 · REVIEW SETTIMANALE DELLA DISTRIBUZIONE DEI FAILURE MODE. Aggregare settimanalmente; dashboard top mode per dominio di task. STEP 4 · REMEDIATION TARGETTATA.

Per ogni top-3 mode, spedire una remediation a livello workspace. Step repetition → loop detection + max-iteration. Reasoning-action mismatch → verification pre-action del reasoning.

Task derailment → re-grounding a meta task. STEP 5 · TRACCIARE LA VELOCITA. Dopo la remediation, monitorare la frequenza del mode.

Se scende, la remediation funziona. Se no, iterare l'ipotesi di root-cause.

ANTI-PATTERN 1 · ""ABBIAMO pass@k; STIAMO BENE"". Senza diagnostica dei failure mode non puoi prioritizzare la remediation. Aggiungere MAST richiede ~2 giorni di lavoro di engineering.

ANTI-PATTERN 2 · TARGETTARE PRIMA L'ALLUCINAZIONE. L'allucinazione e sotto i top-6 mode; investire qui prima dei mode strutturali e mis-allocato. ANTI-PATTERN 3 · ""MIGLIORAMENTI DI RELIABILITY"" GENERICI.

Ogni MAS ha la propria patologia; gli sforzi blanket producono risultati diffusi. Targettare un mode specifico per quarter. ANTI-PATTERN 4 · SOTTO-INVESTIRE NELLA VERIFICATION.

FC3 e la categoria piu piccola ma ha mode ad alto impatto. La verification multi-livello produce leva. ANTI-PATTERN 5 · SALTARE LA VALIDAZIONE UMANA.

L'annotator LLM e affidabile ma non perfetto (κ = 0.77 vs umano). Gli spot check prendono i casi di disaccordo.

Abbiamo replicato la classificazione MAST sulle trace di agent Madani in italiano, francese e inglese. Distribuzione stabile tra le lingue (chi-quadro p > 0.4 sulla maggior parte dei mode). Differenza per-language dominante: FM-2.3 Task Derailment leggermente piu alta in IT/FR (13.5% / 13.0%) vs EN (10.2%), attribuibile all'ambiguita colloquial-business nelle lingue di origine.

Gli altri 13 mode non mostrano effetto significativo di lingua. Le discipline a livello harness sono language-invariant.

DISCUSSION · §27 · INTEGRAZIONE CON METACOG (WSB-06) E DPI (WSB-05). Le tre policy Madani correlate alla reliability sono complementari: la policy DPI WSB-05 previene il multi-agent quando non e giustificato (prevenzione upstream); MetaCog WSB-06 fornisce l'assessment di competenza per-task (gate runtime); la tassonomia MAST WSB-07 fornisce il vocabolario di analisi dei fallimenti (diagnostica post-mortem). Stack di reliability a 3 layer: prevenire + gate + diagnosticare.

La lead-generation e il workflow agentico a piu alto volume di Madani (~180 task/giorno). Baseline pre-audit MAST: success rate 67%, pattern di fallimento sconosciuto. Abbiamo applicato la classificazione MAST a 240 trace fallite di lead-gen e identificato il pattern di fallimento dominante: 22% FM-2.2 (Fail to Ask Clarification) — l'agent procede con assunzioni sull'intent del prospect quando il context di outreach originale e ambiguo.

Secondo: 18% FM-1.5 (Unaware of Termination Conditions) — l'agent non riconosce quando una sequenza ha raggiunto lo step terminale (es. il prospect ha esplicitamente declinato; la sequenza completa). Terzo: 14% FM-2.3 (Task Derailment) — le decisioni di sequencing vengono deviate verso research sull'azienda del prospect invece di continuare la cadenza di outreach. La remediation che abbiamo spedito (giugno 2026): un "ambiguity probe" strutturato iniettato prima delle decisioni di sequencing, che chiede all'agent di enumerare esplicitamente le incertezze sull'intent del prospect.

Dove l'ambiguita supera la soglia, l'agent escala a human review invece di procedere. Dopo 60 giorni: FM-2.2 sceso dal 22% all'11% delle trace fallite (e il success rate complessivo salito dal 67% all'81%). Costo della remediation: ~3 giorni di lavoro di engineering per l'ambiguity probe + ~2 giorni per il workflow di escalation.

Il ROI era di 2 settimane di payback in compute risparmiato su sequence fallite.

La riconciliazione finance e un workflow a volume piu basso ma high-stakes a Madani (~60 task/giorno, accuratezza finanziaria critica). Baseline pre-MAST: success rate 58% — la baseline PIU BASSA tra i nostri 8 workflow, riflettendo la difficolta sottostante del task. L'audit MAST ha identificato il pattern di fallimento dominante: 31% FM-3.2 (No or Incomplete Verification) — l'agent genera un match di riconciliazione senza verificarlo contro i record di source-of-truth.

Secondo: 14% FM-2.4 (Information Withholding) — gli agent comunicano categorizzazioni ambigue agli agent downstream senza flaggare l'ambiguita. Terzo: 11% FM-1.3 (Step Repetition) — l'agent tenta lo stesso match di riconciliazione ripetutamente senza riconoscere i tentativi precedenti. La remediation che abbiamo spedito: uno scaffold di verification multi-livello che richiede (a) match contro source record, (b) confidence score, (c) human review opzionale per i match low-confidence.

Abbiamo anche aggiunto "ambiguity tagging" esplicito allo schema dei messaggi inter-agent in modo che gli agent downstream vedano l'incertezza come campo strutturato invece che come informazione mancante. Dopo 60 giorni: FM-3.2 sceso dal 31% al 16%, FM-2.4 sceso dal 14% al 6%. Success rate salito dal 58% al 76%.

Questo e il piu grande miglioramento assoluto che abbiamo misurato per un singolo workflow.

Delivery onboarding e un workflow cross-domain a Madani (~45 task/giorno, tocca writing + project-planning + finance-categorization). Baseline pre-MAST: success rate 71%. L'audit MAST ha identificato il pattern di fallimento dominante: 26% FM-2.6 (Reasoning-Action Mismatch) — l'agent identifica correttamente i requirement del progetto ma l'azione di onboarding (calendar invite, kickoff email, template di documento) non matcha i requirement.

Secondo: 17% FM-2.3 (Task Derailment) — l'agent inizia l'intake, passa al client research, non torna mai all'intake. Terzo: 13% FM-3.3 (Incorrect Verification) — l'agent verifica le dimensioni sbagliate dell'output di onboarding (es. conformita di formato) mancando le dimensioni di alto livello (es. copertura dei requirement). La remediation che abbiamo spedito: un requirement strutturato di "reasoning-action mapping" — prima di qualsiasi azione, l'agent deve produrre un oggetto JSON che lega l'azione al reasoning upstream.

Il mapping e verificato da un secondo agent che controlla la consistenza reasoning-action. Dopo 60 giorni: FM-2.6 sceso dal 26% al 14%. Success rate salito dal 71% all'84%.

Il pattern di reasoning-action mapping e stato generalizzato ed e ora applicato a tutti i workflow cross-domain nel workspace Madani.

OPEN RESEARCH FRONTIER · §31 · 5 DIREZIONI CHE LA TASSONOMIA APRE. (1) PREDIZIONE DELLA FREQUENZA DEI MODE DA ARCHITETTURA: Data una specifica di architettura multi-agent (numero di agent, topologia di comunicazione, policy di verification), possiamo predire i failure mode dominanti? Le distribuzioni per-MAS di Cemri et al. (Figura 4) suggeriscono di si; un predictor appreso permetterebbe ai team di auditare le architetture PRIMA del deployment. (2) ATTRIBUZIONE CAUSALE AUTOMATICA: Oltre a etichettare i fallimenti, possiamo inferire la root cause via replay perturbation? Aggiungere chiavi di idempotency e ri-eseguire — se la frequenza di FM-1.3 (step repetition) scende, l'assenza di chiavi di idempotency era la causa.

Questo trasforma l'analisi dei fallimenti da descrittiva a causale. (3) ARCHITECTURE SEARCH MAST-AWARE: Data una distribuzione di task e un'architettura candidata, possiamo suggerire automaticamente modifiche che targettano i failure mode dominanti predetti? E la naturale estensione da "tassonomia diagnostica" a "ottimizzatore architetturale prescrittivo". (4) TRASFERIMENTO DEI MODE CROSS-DOMAIN: Quando una remediation funziona per un dominio di task (es. reasoning-action mapping per delivery), generalizza ad altri? I dati iniziali suggeriscono di si per FM-2.6 su delivery + sales + setting, ma il tasso di generalizzazione e sconosciuto per domini meno simili. (5) ESTENSIONE DEL BENCHMARK: MAST-Data di Cemri et al. e derivato dal benchmark (framework MAS accademici su task accademici).

Un'estensione production-task (workflow di clienti reali, costi di fallimento reali) chiuderebbe il gap tra benchmark insight e production insight. Il dataset di 1.180 trace Madani e uno step; replication cross-company su piu vertical costruirebbero una generalizzazione piu ampia.

Un punto metodologico sottile: la tassonomia ha 14 mode, non 5 (troppo coarse) o 50 (troppo fine). Il count di 14 mode e emerso dalla saturazione Grounded Theory invece che da una granularita target. La meta-struttura a 3 categorie (FC1/FC2/FC3) fornisce un raggruppamento di livello piu alto quando 14 e troppo dettagliato; le definizioni per-mode forniscono l'analisi dettagliata quando le categorie sono troppo coarse. Abbiamo osservato che i team di produzione usano routinariamente entrambi i livelli: le review settimanali usano il riassunto a 3 categorie; i postmortem di incident usano il dettaglio dei 14 mode.

Il fatto che la Grounded Theory abbia prodotto una gerarchia che operativamente si mappa su "summary view + detail view" e evidenza strutturale che la granularita e corretta. Le estensioni future della tassonomia dovrebbero preservare questa proprieta.

L'approccio Grounded Theory di Cemri et al. e metodologicamente insolito per i paper ML, e crediamo meriti adozione piu ampia oltre l'analisi dei fallimenti MAS. Il pattern e: invece di partire da uno schema teorico ed etichettare le osservazioni, lascia che le categorie EMERGANO dai dati. Questo produce categorie che si adattano ai fenomeni osservati piuttosto che ai framework teorici.

Il costo e l'effort di annotation (Cemri et al. riportano >20 ore per expert annotator per l'analisi iniziale di 150 trace); il beneficio e la fondazione empirica. Proponiamo questo metodo per: (a) agent capability profiling (dimensioni di competenza bayesiane che emergono dai task di produzione invece che da categorie cognitive a priori), (b) failure mode di prompt-engineering (una tassonomia di come i prompt falliscono in produzione, derivata da fallimenti osservati invece che da framing teorici di "alignment" o "safety"), (c) failure mode RAG (una tassonomia di fallimenti di retrieval fondata nel comportamento di produzione osservato). Ognuno di questi estenderebbe la metodologia MAST-like a problemi di reliability adiacenti.

Il workflow voice-channel (il caller outbound Madani per setting high-intent) ha eseguito 4.300 chiamate in una finestra di 90 giorni post-strumentazione MAST. La baseline pre-strumentazione pass@1 era 71% (dove "pass" significa che la chiamata chiude con un appuntamento bookato, una squalifica pulita o un recovery path documentato); pass@3 (rilanciare la chiamata 24-48h dopo se il primo tentativo e inconcludente) era 84%. Applicando la classificazione MAST a 14 mode alle 1.247 trace fallite si e prodotta una distribuzione fortemente non-uniforme: 31% FM-2.6 (Reasoning-Action Mismatch · l'agent verbalizza un next step corretto nel dialogue plan ma esegue il tool sbagliato, es. legge il calendario ma non interroga mai la disponibilita), 19% FM-1.3 (Step Repetition · l'agent fa loop sulla stessa qualifying question dopo che il prospect ha risposto, segnalando corruzione del working context), 14% FM-3.2 (Incorrect Tool Schema · mismatch di encoding lato TTS che producono segmenti di silenzio e l'agent non li rileva), e 9% FM-2.4 (Information Withholding · l'agent ha l'offerta di chiusura in memoria ma non la fa emergere perche la dialogue policy non triggera mai il beat dell'offerta).

Questa scomposizione e operativamente controintuitiva perche l'assunzione prevalente nell'engineering di voice-agent e che l'allucinazione domini; nel nostro dataset, l'allucinazione del modello (FM-2.1) rappresenta il 4.7% — un ordine di grandezza piu piccolo del reasoning-action mismatch. Abbiamo spedito quattro remediation targettate: (i) telemetria esplicita di action-confirmation che asserisce il next-step verbalizzato del modello contro la tool call effettiva, alzando la visibilita di FM-2.6 da 0 al 100% nel monitoring; (ii) un guard di step-deduplication che flagga ogni qualifying question ripetuta entro 4 turn, escalando al recovery path; (iii) un mass-decoder lato audio che asserisce la durata attesa, catturando i segmenti di silenzio FM-3.2 al layer dell'harness; (iv) un beat di offer forzato al minuto 5 della chiamata indipendentemente dal dialogue-state, affrontando FM-2.4. L'effetto combinato 60 giorni post-deploy: pass@1 salito dal 71% all'87% (+16 punti assoluti), pass@3 dall'84% al 95%, e reasoning-action mismatch sceso dal 31% delle trace fallite al 9%.

Il costo di engineering e stato 11 engineer-day; il compute recuperato e il tempo setter risparmiato hanno superato il costo in 16 giorni. La cross-reference WSB-12 documenta i miglioramenti di SLO voice-channel post-MAST in dettaglio operativo.

Il workflow delivery (orchestrazione dell'onboarding cliente) girava da 8 mesi con un apparente pass@1 del 92% per self-report. Un audit retrospettivo MAST di 600 trace campionate casualmente ha rivelato qualcosa che la metrica pass@1 del team aveva mancato completamente: 38 trace (6.3%) contenevano FM-2.3 (Task Derailment) dove l'agent ha redatto comunicazioni esterne ai clienti senza triggerare il governance-gate (Hard Rule #1) — bozze che sono state impedite di partire solo perche Nour le ha intercettate in pre-output review, non perche il sistema le ha catturate. Nessuna delle 38 trace era contata come fallimento dal monitoring del team perche non hanno prodotto un errore, non hanno tornato un non-200 e non hanno visibilmente violato alcuna asserzione di test; avrebbero costituito violazioni catastrofiche di governance se Nour non fosse stato sul loop di human review.

Il contributo dell'audit MAST e stato far emergere questa tail nascosta: un framework di classificazione a 14 mode conta "draft external comm senza trigger del gate" come FM-2.3 anche quando non e stato sollevato alcun errore. La cross-reference WSB-15 governance discute la fix architetturale (wrapper governance-gate-enforced attorno a tutti i message-emit tool). La lezione di reliability e che pass@1 e necessario ma non sufficiente: lo stesso workflow ha segnato 92% pass@1 e 0% di copertura governance-hard-rule, e MAST ha fatto emergere la seconda metrica.

La dashboard di reliability del team e stata aggiornata per dual-trackare entrambe le metriche. Questo case study generalizza una claim piu ampia: qualunque framework di reliability che scori solo sull'output terminale sotto-contera fallimenti il cui danno e intercettato dagli umani nel loop. MAST, classificando i fallimenti di step intermedi, previene questo artefatto di misurazione.

Il workflow content-production fa passare gli script attraverso una pipeline QC a 17 layer prima dell'approvazione. Pre-strumentazione MAST, il team trackava solo il pass/fail terminale della QC. Un audit MAST di 12 settimane su 2.100 trace di transition a livello layer ha esposto tre finding controintuitivi

1. (a)
   l'inter-annotator agreement
2. (b)
   il power del sample per rilevare differenze nei failure-mode rate tra i mode MAST

(Q1) IPOTESI: Per workflow sopra L3 di maturita su governance e observability, il rapporto FC1/FC2/FC3 MAST si stabilizza a una power-law (FC1 ≈ 10-15%, FC2 dominante 60-70%, FC3 ≈ 20-30%); per workflow sotto L3, la distribuzione e uniforme o model-dominant. FALSIFICATION TEST: strumentare 30 workflow di produzione su vari tier di maturita, classificare 500 trace per workflow, fittare power-law sulla distribuzione FC, confrontare esponenti tra i tier di maturita. (Q2) IPOTESI: Le distribuzioni MAST cross-organization mostrano signature domain-specific (lead-generation skewa verso FM-2.2; finance verso FM-1.5; content verso FM-2.6) e queste signature possono essere usate per identificare mismatch workspace-dominio. FALSIFICATION TEST: studio cross-organization con almeno 5 organizzazioni e 3 domini di workflow, misurare la varianza inter-organization nelle domain signature. (Q3) IPOTESI: Il miglioramento marginale pass@k → pass@(k+1) di un workflow e predicibile dalla sua distribuzione MAST a pass@1; specificamente, i workflow dominati da FM-2.6 retry bene mentre i workflow dominati da FM-1.5 no.

FALSIFICATION TEST: studio di 50 workflow che misurano pass@1, pass@3, pass@5 accoppiati con distribuzione MAST a pass@1, modello di regressione. (Q4) IPOTESI: L'inter-annotator agreement MAST sul confine FM-1.5/FM-2.3 e migliorabile oltre kappa=0.83 solo per raffinamento del codebook, non per training aggiuntivo. FALSIFICATION TEST: studio 4-arm (solo-training, solo-codebook, entrambi, nessuno) su pool di trace condiviso. (Q5) IPOTESI: Il mode MAST FM-2.4 (Information Withholding) e il mode piu raro nei workflow single-agent (<2%) ma il mode piu comune nei workflow multi-agent (>25%), rendendolo una signature discriminante per il rilevamento di violazioni DPI. FALSIFICATION TEST: run pairate single-thread vs multi-agent su 30 task ciascuna. (Q6) IPOTESI: I workspace che adottano MAST e agiscono sui finding mostrano miglioramenti pass@k che seguono una curva logistica con inflessione a ~6 mesi post-adoption; i workspace che adottano MAST senza budget di remediation non mostrano miglioramento.

FALSIFICATION TEST: coorte longitudinale di 24 mesi di 15 workspace splittati per allocazione di budget.

[1] Cemri M., Pan M.Z., Yang S., Agrawal L.A., Chopra B., Tiwari R., Keutzer K., Parameswaran A., Klein D., Ramchandran K., Zaharia M., Gonzalez J.E., Stoica I. (2025), Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657v3, NeurIPS 2025 Datasets and Benchmarks Track, UC Berkeley + Intesa Sanpaolo. [2] Glaser B.G. & Strauss A.L. (1967), The Discovery of Grounded Theory: Strategies for Qualitative Research, Aldine. [3] Chen M. et al. (2021), Evaluating Large Language Models Trained on Code (HumanEval), arXiv:2107.03374. [4] Wu Q. et al. (2024), AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, ICML. [5] Moura J. (2024), CrewAI. [6] Hong S. et al. (2024), MetaGPT, ICLR. [7] Li G. et al. (2023), CAMEL, NeurIPS. [8] LangChain (2024), LangGraph. [9] Chen W. et al. (2024), AgentVerse, ICLR. [10] Park J.S. et al. (2023), Generative Agents, UIST. [11] Qin Y. et al. (2023), ToolBench. [12] Liu H. et al. (2024), Empirical Study on Challenging Cases for LLM Agents. [13] Yao S. et al. (2023), ReAct, ICLR. [14] Shinn N. et al. (2023), Reflexion, NeurIPS. [15] Cognition Labs (2025), Don't Build Multi-Agents, cognition.ai blog. [16] Tran D. & Kiela D. (2026), Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning, arXiv:2604.02460. [17] Wang C. & Shu Y. (2026), MetaCogAgent, arXiv:2605.17292v1. [18] OpenAI (2024), GPT-4 Technical Report. [19] Anthropic (2025), Claude Sonnet 4.5 Technical Report. [20] Anthropic (2024), Claude 3.7 Sonnet Technical Report. [21] OpenAI (2024), o1 System Card. [22] Cohen J. (1960), A Coefficient of Agreement for Nominal Scales, Educational and Psychological Measurement 20:37-46. [23] Anthropic (2025), Building Agents Cookbook. [24] Madani Lab (2026), reliability-pillar-policy.md v1.2. [25] Madani Lab (2026), 1,180-Trace Madani Failure Dataset (anonymized, MIT release pending). [26] Cemri M. et al. (2025), MAST-Data on HuggingFace (mcemri/MAST-Data); MAST taxonomy code at github.com/multi-agent-systems-failure-taxonomy/MAST.