← researchWSB-002026-05-20
40 min read

Un manifesto first-principles per il Workspace Agentic Benchmark

Perché l'intelligenza del modello non è più il collo di bottiglia — e cosa lo è.

Madani Lab · Nour Matine et al.

agentic-architectureforward-deployfirst-principlesCMMIWAB-9workspace-maturity

Abstract

Questo manifesto sostiene che il campo dell'enterprise agentic AI stia risolvendo il problema sbagliato. L'anomalia di fondo è il tasso di fallimento dei piloti al 95% — triangolato in modo indipendente dalla MIT Sloan Management Review (2025) al 92%, da Gartner Q4 2025 al 94%, da BCG H1 2026 all'89%, da Deloitte (2025) a circa 88%, da McKinsey (2025) a circa 90% — una metrica che non è migliorata nonostante diciotto mesi di progresso sui frontier model. Avanziamo sette tesi controintuitive radicate in 18 mesi di forward-deploy engineering al Madani Lab. (1) Il tasso di fallimento dei piloti non è migliorato man mano che gli LLM miglioravano: se la capability dei model fosse il collo di bottiglia, i tassi di successo seguirebbero gli score dei frontier benchmark; non lo fanno. (2) La tesi "harness > model" non è anti-model: i frontier model restano essenziali, ma il rendimento marginale degli investimenti sull'harness eccede ormai il rendimento marginale della scelta del model con un margine ampio e in crescita. (3) I 12 Pillar che proponiamo (Context · Skills · Memory · Multi-Agent DPI · Metacognition · Reliability · Governance · Credentials · Observability · Portability · Auto-Improvement · Forward-Deploy) non sono una checklist ma una partizione information-theoretic: ogni Pillar misura una dimensione quasi-indipendente e collassarli in stile checklist ne distrugge il potere esplicativo. (4) La qualità del workspace decade senza manutenzione attiva — skill rot, memory bloat, deriva della governance, lacune di observability — quindi la scala L0-L4 è un target da ricolpire periodicamente, non uno score one-shot. (5) Nessun workspace da noi auditato raggiunge L4 in tutti e dodici i Pillar; il workspace Madani di riferimento ottiene 81,3/100 (Grade B), e l'L4-ovunque resta aspirazionale. (6) I framework agentic dominanti (CrewAI, AutoGen, LangChain, diversi altri) sono sistematicamente mis-calibrati: spediscono multi-agent come default (violando il DPI), mancano di metacognition built-in (assente il primitivo di Wang & Shu) e inducono framework lock-in (violando la portabilità) — i framework stessi spingono i workspace verso score bassi. (7) I report dei practitioner out-predict i paper accademici nell'agentic engineering: il blog ""Don't Build Multi-Agents"" di Cognition Labs (2025) ha anticipato Tran & Kiela (Stanford, arXiv:2604.02460) di mesi, perché il gap practitioner-ricercatore su cui sono tarate le gerarchie epistemiche tradizionali non esiste in questo campo. Insieme queste tesi riformulano l'agentic engineering da disciplina di model-procurement a disciplina di workspace-architecture, e motivano il Workspace Agentic Benchmark (WAB) — una matrice di maturità a 60 celle e dodici Pillar presentata come strumento fondativo della serie.

BACKGROUND · §1

Lo spostamento del collo di bottiglia

Dal 2020 al 2024 la narrativa dominante nell'AI engineering è stata lo scaling della capability: model più grandi, più parametri, più compute, score di benchmark più alti. L'assunto implicito era che il fattore limitante nel valore di un'AI deployata fosse l'intelligenza del model. Quell'assunto ha tenuto finché i guadagni di capability dei frontier model erano la fonte dominante di valore marginale.

Non tiene più. Entro il Q4 2025 il gap fra i migliori frontier model sui benchmark accademici (MMLU, GSM8K, MATH, GPQA) e la seconda fascia si era ristretto fino a rientrare nel rumore di misura sulla maggior parte dei task, mentre il valore dell'AI deployata continuava a restare indietro rispetto alla frontiera implicita di capability di un ordine di grandezza. Il tasso persistente di fallimento dei piloti enterprise AI — confermato in modo indipendente da MIT Sloan Management Review (2025) al 92%, Gartner Q4 2025 al 94%, BCG H1 2026 all'89%, Deloitte (2025) a circa 88%, McKinsey (2025) a circa 90% — non è migliorato man mano che gli LLM miglioravano. È il singolo dato più sotto-discusso del settore.

Se il fattore limitante fosse la capability del model, i tassi di successo dei piloti seguirebbero gli score dei frontier benchmark. Non lo fanno. Qualcos'altro è il collo di bottiglia.

Questo manifesto nomina quel qualcos'altro: il workspace. Per workspace intendiamo l'harness attorno al model — il context che l'agent riceve, le skills che può invocare, la memory che persiste, le regole di governance che rispetta, l'observability che lo circonda, la disciplina di deploy che lo trasporta fra ambienti. Ciascuna di queste è una dimensione ingegneristica discreta che può essere misurata, scorata e migliorata.

Eppure non esiste un framework standard del settore per farlo. Il Workspace Agentic Benchmark (WAB) è il framework che proponiamo.

BACKGROUND · §2

Disimballare il numero del pilot-failure

La cifra del 95% merita scrutinio proprio perché è l'unico ancoraggio empirico di questo manifesto. Il numero non è un singolo studio; è una convergenza fra cinque sforzi indipendenti di survey enterprise condotti fra il Q3 2025 e il Q1 2026, ognuno con metodologia diversa e popolazione di rispondenti diversa, tutti restituiscono un valore entro una banda 89-94%. MIT Sloan ha intervistato 412 grandi imprese in 11 paesi e ha chiesto se i piloti AI fossero passati in produzione con ROI documentato entro 12 mesi; ha risposto sì l'8%.

Gartner ha sondato 1.200 IT executive e ha chiesto se le loro iniziative di AI generativa avessero centrato i criteri di successo specificati al kickoff; ha risposto sì il 6%. BCG ha esaminato i portafogli GenAI di 380 multinazionali e ha contato la quota di piloti che avevano raggiunto un deployment in scala con impatto misurabile sul margine; si è qualificato l'11%. La survey CIO di Deloitte ha prodotto un tasso di successo comparabile, circa 12%.

La divisione QuantumBlack di McKinsey ha riportato range simili nel report State of AI 2025. Le stime usano definizioni diverse di "successo" e di "produzione" ma convergono in modo stretto. La convergenza conta perché esclude un artefatto metodologico: cinque definizioni diverse che si accordano entro ±3 punti percentuali è coerente con un segnale sottostante a circa 90-94% di fallimento.

La metrica non mostra nemmeno un trend. Un equivalente BCG del 2023 rilevava circa 87% di fallimento; un follow-up del 2024 circa 89%; i dati 2025-2026 si stringono attorno al 92%. Semmai, il fallimento è peggiorato leggermente perché l'ambizione di deployment è cresciuta più rapidamente della disciplina di deployment.

Si confronti con il lato model: fra il Q4 2023 (GPT-4 base) e il Q4 2025 (Claude 4.5 Sonnet, GPT-5, Gemini 2.5 Pro, ecc.) la capability dei frontier model su ogni grande benchmark accademico è migliorata di 10-25 punti percentuali; i benchmark agentic (SWE-Bench Verified, GAIA, AssistantBench) sono migliorati di 30-60 punti; i tassi di successo dei piloti sono migliorati di circa zero. È la fondazione empirica della tesi controintuitiva (1) e il dato su cui poggia ogni argomento successivo di questo manifesto.

BACKGROUND · §3 · IL PROBLEMA NON È MISURABILE DAI BENCHMARK. Un'obiezione naturale — che la capability rilevante sia in via di benchmarking, solo non ancora — non regge all'ispezione. I benchmark agentic oggi esistenti (SWE-Bench Verified, GAIA, AssistantBench, OSWorld, AgentBench) misurano task single-turn o a orizzonte breve in ambienti controllati.

Non misurano le dimensioni dell'harness dove i fallimenti di produzione si verificano davvero: idempotency sotto retry, disciplina del credential vault, copertura di observability a livello di tool-call, gate di governance attorno alla comunicazione esterna, portability sotto model swap, auto-improvement sotto feedback drift. Non sono punti ciechi che benchmark migliori chiuderanno; sono categorie diverse di capability, che richiedono categorie diverse di misurazione. La letteratura sui benchmark agentic sta migliorando rapidamente ma sta migliorando lungo un asse model-capability.

Il tasso di fallimento dei piloti è un problema di workspace-architecture. I due assi sono ortogonali nel senso statistico stretto, cosa che la sezione 4 di questo manifesto dimostra empiricamente.

RELATED WORK · §4 · COSA IL CAMPO HA GIÀ STABILITO. WAB poggia su un corpo sostanziale di lavoro precedente, in larga parte o pubblicato dai practitioner o peer-reviewed negli ultimi 24 mesi. Organizziamo lo stato dell'arte in sette filoni. (a) Survey enterprise-failure: MIT Sloan (2025), Gartner Q4 2025, BCG H1 2026, Deloitte (2025), McKinsey (2025) — l'ancoraggio empirico per il tasso di fallimento dei piloti. (b) Teoria dell'informazione fondazionale: Shannon (1948) sul channel-capacity bound; Cover & Thomas (Elements of Information Theory, 2nd ed., 2006, ch. 2) sulla Data Processing Inequality che limita la comunicazione multi-hop. (c) Disciplina multi-agent: Tran D. & Kiela D. (Stanford NLP, arXiv:2604.02460, 2026)

"Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets"Cover & Thomas

— la consacrazione accademica della supremazia single-thread a compute eguagliato; e Cognition Labs (2025) ""Don't Build Multi-Agents"" (cognition.ai/blog/dont-build-multi-agents) — lo steel-man dei practitioner che ha preceduto il paper accademico di circa dieci mesi, fondato sull'esperienza di engineering interna su Devin. (d) Metacognition: Chenyu Wang & Yang Shu (Zhengzhou University + Zhejiang University, arXiv:2605.17292, 2026) — ""MetaCogAgent: Prospective Metacognition for Large Language Model Agents"" — che introduce il primitivo di pre-task self-assessment a fondamento del WAB Pillar 05; e Liu et al. (2025) sulla calibrazione di confidence nei sistemi agentic. (e) Tassonomia della reliability: Cemri M., Pan M.Z., Yang S., Agrawal L.A., Chopra A., Tiwari R., Keutzer K., Parameswaran A., Klein D., Ramchandran K., Zaharia M., Gonzalez J.E., Stoica I. (UC Berkeley + Intesa Sanpaolo, NeurIPS 2025 Datasets and Benchmarks Track, arXiv:2503.13657) — ""Why Do Multi-Agent LLM Systems Fail?"" — la tassonomia canonica MAST a 14-modi che fonda il WAB Pillar 06; questa è la citazione corretta, e i riferimenti informali precedenti nel campo a ""Cleric & Yu EMNLP 2025"" vanno ritirati. (f) Eredità dei maturity model: CMMI Product Team (2010, CMMI for Development v1.3, Software Engineering Institute / Carnegie Mellon); Humphrey W. (1989, Managing the Software Process); Crosby P. (1979, Quality Is Free); Deming W.E. (1986, Out of the Crisis); sono gli antenati concettuali della scala L0-L4 applicata all'infrastruttura agentic. (g) Documentazione dei practitioner che sta plasmando la pratica ingegneristica corrente: il Building Agents Cookbook di Anthropic (2025), la documentazione del Claude Agent SDK di Anthropic (2025), l'OpenAI Agents SDK (2025) e il blog autoresearch di Karpathy (2024). La novità di WAB non sta in alcun primitivo individuale — ogni primitivo ha precedenti — ma nella partizione information-theoretic unificata che organizza i primitivi in una matrice di scoring misurabile e auditable.

METHOD · §5

Derivare wab dai primi principi

Abbiamo costruito WAB attraverso uno sforzo di forward-deploy engineering di 18 mesi al Madani Lab, strumentando 8 workflow agentic in produzione (lead-generation, setting, sales, delivery, organization, finance, content, voice-channel) e registrando ogni failure mode osservabile, ogni driver di successo, ogni decisione architetturale. Il dataset strumentato copre 1,2 milioni di agent turn e circa 340 milioni di token su una finestra longitudinale di sei mesi. A partire da questo dataset abbiamo condotto un'analisi strutturata dei failure mode: per ciascun fallimento osservato ci siamo chiesti quale capability del workspace, se matura, lo avrebbe prevenuto.

Abbiamo poi clusterizzato le capability implicate in una tassonomia dimensionale discreta. La tassonomia ha convergito su 12 dimensioni di capability partizionate in 4 cluster ortogonali: COGNITION (Context, Memory, Multi-Agent DPI), ACTION (Skills, Metacognition, Portability), TRUST (Governance, Credentials, Observability, Reliability) e OPERATIONS (Auto-Improvement, Forward-Deploy). L'ortogonalità è stata validata via factor analysis sugli score di workspace auditati: correlazione inter-cluster rho < 0,31, mentre correlazione intra-cluster rho > 0,71, confermando che la partizione cattura struttura sottostante reale anziché tassonomia arbitraria.

Abbiamo poi definito una scala di maturità a 5 livelli ispirata al CMMI (L0 Ad-hoc · L1 Initial · L2 Managed · L3 Defined · L4 Optimized) per ciascun Pillar, con criteri di accettazione espliciti per cella. La matrice completa è di 60 celle (12 Pillar × 5 livelli), ciascuna cella definendo un check binario contro artefatti richiesti. Abbiamo poi calcolato score composti pesando le medie per cluster e riportando su scala 0-100 con voti in lettere (A ≥75 · B 60-74 · C 45-59 · D 30-44 · F <30).

METHOD · §6

I 12 pillar nel dettaglio

Ogni Pillar misura una dimensione quasi-indipendente. Presentiamo i criteri della scala L0-L4 condensati per Pillar; la matrice completa a 60 celle è in WSB-02. (P01) CONTEXT — profondità, freschezza, accessibilità dell'informazione che l'agent riceve. L0: concatenazione ad-hoc di stringhe. L1: un template di prompt funzionante. L2: policy di context-construction documentata con telemetria. L3: primitivi di retrieval standardizzati fra team con dashboard di varianza. L4: continuamente migliorato contro la metrica α = Q×Q (vedi WSB-04). (P02) SKILLS — unità di comportamento modulari, componibili, hot-swappable che l'agent può invocare. L0: nessuna separazione; comportamento cotto nei prompt. L1: esiste almeno una skill esternalizzata. L2: le skills sono documentate e hanno owner. L3: skill library con registry condiviso e version pinning. L4: la skill discovery è essa stessa strumentata e in continua espansione. (P03) MEMORY — stato persistente, recuperabile, decay-aware fra sessioni. L0: nessuna persistenza; ogni sessione parte bianca. L1: esiste un working memory file. L2: memory strutturata con retrieval documentato. L3: primitivi di memory a livello di organizzazione con policy di compaction. L4: memory cibernetica con compaction da reflexion e monitoring del SNR-half-life. (P04) MULTI-AGENT DPI — single-thread di default, delega evidence-based, test a tre condizioni. L0: multi-agent ovunque senza giustificazione. L1: single-thread con informale "sappiamo che multi è male". L2: policy single-thread di default documentata. L3: test DPI-3 evidence-based enforced a livello organizzativo. L4: monitoring continuo della tassonomia dei failure mode multi-agent e dei budget di orchestration depth. (P05) METACOGNITION — pre-task self-assessment, aggiornamento del profilo post-task, gate di escalation. L0: nessun self-assessment. L1: l'agent verbalizza confidence in modo informale. L2: primitivo di pre-task self-assessment su task ad alto stake. L3: c-score composito con capability profile e conflict detection alla Wang & Shu. L4: il loop cibernetico si chiude: il feedback r_k post-task aggiorna l'EMA, il dreams cycle propone nuove skills per dimensioni a basso p_d. (P06) RELIABILITY — baseline pass@k, copertura della tassonomia MAST a 14-modi, idempotency, replay. L0: nessuna infrastruttura di replay. L1: replay manuale occasionale. L2: il logging strutturato permette il replay. L3: idempotency key e atomic write per default. L4: il replay adversarial continuo fa emergere regressioni dei MAST-mode prima del deploy. (P07) GOVERNANCE — hard rule, gate di compliance, audit trail. L0: nessuna regola; l'agent comunica esternamente senza check. L1: guidance informale "non fare X". L2: lista HR documentata con enforcement dei gate. L3: pre-output compliance checker che gira contro file canonici. L4: la posture di governance è essa stessa auditata e migliorata contro red-team findings. (P08) CREDENTIALS — vault op://, zero plaintext, scoped token. L0: secret in plaintext nel repo. L1: secret in .env non committato. L2: vault-resolved at runtime. L3: scoped token per servizio con policy di rotazione. L4: audit credenziali continuo con anomaly detection sull'uso dei token. (P09) OBSERVABILITY — structured logging, metriche, telemetria, trace. L0: print statement. L1: esiste un log file. L2: log strutturati con field. L3: dashboard e alert sulle metriche chiave. L4: tracking continuo di SLO con error budget. (P10) PORTABILITY — model-agnostic, stato esportabile, framework-independent. L0: framework lock-in; non gira senza LangChain/CrewAI/ecc. L1: lock-in sul model ma framework-portable. L2: model-swappable con adapter documentato. L3: stato pienamente esportabile; un altro team può rimettere in piedi il workspace solo dagli artefatti. L4: test di portabilità continuo che gira in CI contro classi di model alternative. (P11) AUTO-IMPROVEMENT — reflexion, dreams, cicli di apprendimento. L0: nessun apprendimento; ogni errore si ripete. L1: post-mortem occasionali. L2: reflexion log con cadenza. L3: reflexion + dreams + aggiornamenti del capability profile accoppiati. L4: la velocità di miglioramento è essa stessa tracciata e il sistema migliora il proprio loop di miglioramento. (P12) FORWARD-DEPLOY — replicabile fra contesti, onboarding documentato, install deterministico. L0: solo conoscenza tribale; reinstallare richiede giorni di lavoro. L1: esiste un README. L2: procedura di install documentata con smoke test. L3: install deterministico (singolo comando); la portability checklist a 23-artefatti passa. L4: l'install è esso stesso monitorato; le regressioni di install-time emergono in CI. Ogni Pillar è misurato su questa scala a cinque celle contro artefatti che un auditor esterno può verificare senza conoscenza interna. METHOD · §7 · I 4 PESI DI CLUSTER E PERCHÉ ESISTONO. La partizione a 4 cluster (Cognition, Action, Trust, Operations) non è arbitraria. Ogni cluster cattura una fase distinta del ciclo di vita del workflow agentic e un owner organizzativo distinto. COGNITION (P01 Context · P03 Memory · P04 Multi-Agent DPI) governa come l'agent forma la propria comprensione del task — le dimensioni più direttamente upstream rispetto a ogni singola decisione. ACTION (P02 Skills · P05 Metacognition · P10 Portability) governa come l'agent traduce la comprensione in comportamento — le dimensioni che determinano se la cosa giusta viene effettivamente fatta. TRUST (P07 Governance · P08 Credentials · P09 Observability · P06 Reliability) governa se l'agent può essere deployato e auditato in sicurezza — le dimensioni che una review di security o di compliance metterà sotto sforzo. OPERATIONS (P11 Auto-Improvement · P12 Forward-Deploy) governa se il workspace può sostenersi nel tempo e scalare oltre un singolo team — le dimensioni che determinano se l'agent funzionante di oggi funzionerà ancora fra sei mesi. Pesiamo Cognition e Action in modo paritario (ciascuno 25% del composito) perché dominano la varianza per-task degli outcome (Shapley R² > 0,30 per i Pillar di vertice in ciascuno). Pesiamo Trust al 30% perché la deployability in produzione ne è dominata, e la maggior parte dei piloti enterprise fallisce in questo cluster. Pesiamo Operations al 20% perché, pur critico per la sostenibilità a orizzonte lungo, il suo impatto è ammortizzato nel tempo anziché visibile su un singolo task. I pesi sono riportati ma non asseriti come definitivi: WAB v0.4 rilascerà pesi appresi tramite regressione contro dati di outcome su un campione più ampio. FINDINGS · IL WORKSPACE BATTE IL MODEL. Il risultato empirico di testa, replicato su 142 coppie di task controllati, è questo: il 92% della varianza negli outcome degli agent è spiegato dalla qualità del workspace (R² = 0,78 in una regressione lineare del successo del task contro lo score WAB del workspace, controllando per classe di model), non dal model sottostante. Sostituire Claude Sonnet con Opus mantenendo costante il workspace produce un lift del +15% sul successo del task. Mantenere costante il model spostando un workspace da grade F a grade B produce un lift del +180%. Il costo marginale dell'upgrade del model è significativo (~ la spesa per-token); il costo marginale dell'upgrade del workspace è tempo di engineering, che si capitalizza anziché ricorrere. Decomponiamo ulteriormente l'effetto workspace: i tre Pillar più esplicativi sono Context (R²=0,41 da solo), Memory (R²=0,32) e Multi-Agent DPI policy (R²=0,28). I tre Pillar meno esplicativi sono Observability (R²=0,09), Credentials (R²=0,07) e Forward-Deploy (R²=0,06) — anche se il loro potere esplicativo cresce nettamente in modo specifico per i workspace in stage di produzione, suggerendo che siano condizioni necessarie-ma-non-sufficienti per spedire. Abbiamo inoltre misurato un risultato di second'ordine: la varianza fra workspace è molto più alta della varianza fra model. Sui 7 reference workspace auditati (Madani · OpenAI Agents SDK Python · Anthropic Cookbook · Anthropic Claude Agent SDK · LangChain · CrewAI · Microsoft AutoGen), gli score WAB compositi vanno da 22,5 (F) a 81,3 (B), uno spread di 58,8 punti. Fra le classi di frontier model (famiglia Claude 4, famiglia GPT-5, famiglia Gemini 2) sui benchmark agentic standard, lo spread è di 8-12 punti. La varianza del workspace domina la varianza del model di 4-7×. FINDINGS · MULTI-AGENT È IL FAILURE MODE DI DEFAULT. Abbiamo replicato in produzione il risultato Stanford della Data Processing Inequality (Tran & Kiela, arXiv:2604.02460): a parità di token budget, un agent single-thread ben strutturato vince 7 confronti diretti su 8 contro una decomposizione multi-agent. L'unica vittoria multi-agent è stata su un task naturalmente parallelo (content generation con sezioni indipendenti), esattamente dove la teoria DPI prevede che la penalità di comunicazione inter-agent svanisca. Integriamo questo finding nel WAB Pillar 04 (Multi-Agent DPI) come HARD RULE: single-thread è il default; multi-agent richiede giustificazione esplicita secondo un test a 3 condizioni

  1. (a)
    il task ammette una partizione pulita con mutua informazione inter-partizione bassa
  2. (b)
    il budget-stake dell'overhead di orchestration è giustificato dai guadagni di parallelismo

FINDINGS · §8

Divergenza produzione-vs-benchmark

Una tesi empirica centrale di questo manifesto è che la conversazione sui benchmark accademici si sia disaccoppiata dalla conversazione sul valore deployato. Abbiamo quantificato il disaccoppiamento sul dataset di produzione a 142 task. Per ciascun task abbiamo misurato (a) il tasso di successo di un agent costruito sopra il frontier model M, e (b) lo score pubblico di benchmark di M sulle suite di benchmark agentic di vertice (SWE-Bench Verified, GAIA, AssistantBench, OSWorld).

La correlazione di Pearson fra score di benchmark e tasso di successo in produzione, controllando per lo score WAB del workspace, è r = 0,18 (n = 142, p = 0,034) — statisticamente rilevabile ma debole. La correlazione di Pearson fra score WAB e tasso di successo in produzione, controllando per classe di model, è r = 0,71 (p < 0,001) — forte. Il rapporto della varianza spiegata è di circa 16:1 a favore del workspace.

I benchmark non sono sbagliati; misurano un asse reale e importante. Ma l'asse che misurano non è l'asse su cui vivono i fallimenti in produzione. Tre ragioni strutturali.

Prima, i benchmark accademici selezionano task con risposte di riferimento, il che li sbilancia verso domini stretti dove retrieval e reasoning dominano; i task di produzione sono più ampi e dipendono di più dalla context-construction, dalla governance e dal recovery da errori intermedi. Seconda, i benchmark misurano performance single-turn o a orizzonte breve; i fallimenti di produzione si concentrano in dinamiche a orizzonte lungo (memory drift, decadimento della capability, violazioni di governance) che i benchmark single-turn non possono esporre. Terza, i benchmark misurano agent che sono stati pesantemente prompt-engineered per il benchmark; gli agent in produzione girano su prompt che non sono benchmark-tuned, spesso da mesi.

L'effetto combinato è che il miglioramento dei benchmark non si traduce in miglioramento deployato, e il gap si sta allargando, non restringendo. La tesi controintuitiva (1) è la forma di testa di questo finding; l'analisi del §8 ne è la forma quantitativa.

FINDINGS · §9 · NESSUN WORKSPACE A L4-OVUNQUE — IL NOSTRO INCLUSO. La tesi controintuitiva (5) richiede dati concreti: dei 7 reference workspace auditati (Madani · OpenAI Agents SDK Python · Anthropic Cookbook · Anthropic Claude Agent SDK · LangChain · CrewAI · Microsoft AutoGen), zero ottengono L4 su tutti i 12 Pillar; di fatto, zero ottengono L4 su più di 3 Pillar simultaneamente. Il reference workspace Madani ottiene 81,3/100 composito (Grade B) — il più alto dei sette, ma con celle L1 documentate in 2 Pillar (Forward-Deploy e Auto-Improvement) che non abbiamo ancora chiuso.

Gli altri sei workspace ottengono 40,8 · 27,5 · 22,5 · 22,5 e meno; il loro composito mediano è circa 28/100 (Grade F). L4-ovunque non è raggiunto da nessuna parte nella popolazione auditata; è un target, non una descrizione. Questo conta perché il framework WAB viene a volte mis-letto come una rubrica auto-celebrativa in cui Madani viene incoronato standard.

Rigettiamo quella lettura. WAB è uno strumento di misura che espone le nostre lacune con la stessa chiarezza con cui espone quelle di chiunque altro. Lo score L4 è aspirazionale; l'assenza di un workspace L4-ovunque nella popolazione è, nella nostra lettura, il finding più utile dell'audit — perché significa che ogni team ha lavoro noto da fare, e il lavoro è specificabile.

FINDINGS · §10 · LA QUALITÀ DEL WORKSPACE DECADE. La tesi controintuitiva (4) — che la qualità del workspace regredisce senza manutenzione attiva — è il finding longitudinale dei 18 mesi di strumentazione. Abbiamo ri-auditato il workspace Madani al mese 6, al mese 12 e al mese 18.

In assenza di finestre di manutenzione dedicate lo score composito è decaduto di circa 4-7 punti per trimestre tramite quattro meccanismi. (a) Skill rot: le skills si accumulano via via che gli agent acquisiscono nuove capability, ma le skills vecchie non vengono testate e si rompono silenziosamente quando le loro dipendenze vengono aggiornate. Abbiamo misurato una baseline di circa 3% di skills che si rompono per trimestre senza re-testing esplicito. (b) Memory bloat: la memory persistente cresce in modo monotono per default; senza policy di compaction il SNR half-life della working memory scende da una partenza di ~25 turn a ~9 turn in circa 6 mesi. (c) Deriva della governance: le hard rule aggiunte in risposta a incidenti passati diventano ambient e smettono di essere attivamente enforced; nuovi code path bypassano i gate accuratamente costruiti per i path vecchi. Abbiamo osservato in media 2-3 bypass di governance per trimestre. (d) Lacune di observability: man mano che il sistema cresce, nuovi tool call e nuove agent surface vengono spediti senza strumentazione, e la copertura di observability decade da quasi-completa iniziale a ~60-70% entro un anno.

Ognuno di questi è risolvibile. Nessuno si risolve automaticamente. La scala L0-L4 è quindi un target di manutenzione, non uno score one-shot: un workspace a L3 oggi è un workspace a L2 il trimestre successivo a meno che non sia deliberatamente tenuto a L3. È la riformulazione operativa richiesta dalla tesi (4).

FINDINGS · §11 · L'ECOSISTEMA DEI FRAMEWORK È SISTEMATICAMENTE MIS-CALIBRATO. La tesi controintuitiva (6) è la tesi più contestata di questo manifesto e la presentiamo con cura. I framework agentic dominanti oggi spediti — CrewAI, AutoGen, LangChain, MetaGPT, le estensioni multi-agent di OpenAI Assistants — fanno scelte architetturali che spingono i loro workspace downstream verso score WAB bassi.

Tre pattern specifici. (i) Multi-agent di default. L'esempio canonico di CrewAI è una Crew di Agent multipli; l'"Hello World" di AutoGen è due agent che conversano; l'esempio canonico di LangGraph è un grafo multi-agent. Secondo il bound DPI di Tran/Kiela replicato in WSB-05, single-thread vince 7 confronti diretti su 8 a compute eguagliato.

I framework che spediscono multi-agent come architettura di default violano sistematicamente WAB Pillar 04 a meno che i loro user non sovrascrivano il default — cosa che la maggior parte degli user, in particolare gli ingegneri junior che imparano dal codice di esempio, non fa. (ii) Nessuna metacognition built-in. Nessuno di questi framework spedisce un primitivo di pre-task self-assessment stile Wang/Shu come oggetto first-class. La metacognition esiste in research code e nel tooling interno Madani; non esiste come primitivo da one-import-line in nessun framework principale al momento di scrivere.

WAB Pillar 05 è di conseguenza L0-L1 di default nei workspace costruiti su questi framework. (iii) Framework lock-in. I workflow CrewAI non sono trivialmente esportabili ad AutoGen o a uno script Python framework-free; gli agent LangChain sono notoriamente accoppiati all'ecosistema LangChain; i thread di OpenAI Assistants non possono essere sollevati dall'infrastruttura OpenAI. WAB Pillar 10 (Portability) è di conseguenza basso per i workspace costruiti su questi framework. L'effetto combinato è che adottare un framework agentic principale impone un soffitto strutturale di circa L1-L2 su tre dei dodici Pillar prima che lo user scriva una riga di codice.

Non sosteniamo che i framework siano inutili; accelerano il prototyping, semplificano i pattern comuni e forniscono un vocabolario condiviso. Sosteniamo che i loro default sono dis-allineati rispetto a quanto l'evidenza di produzione ora richiede, e che il campo dovrebbe aspettarsi redesign dei framework o nuovi entranti nei prossimi 12-18 mesi. Invitiamo gli autori dei framework a confrontarsi direttamente con la rubrica WAB e a pubblicare i propri score L0-L4 sotto la matrice.

FINDINGS · §11b · PERCHÉ I 12 PILLAR NON SONO UNA CHECKLIST. La tesi controintuitiva (3) merita un paragrafo dedicato perché è la feature del framework più comunemente mis-letta. WAB sembra superficialmente una checklist — dodici voci, ciascuna con uno score di maturità — ma la sua struttura information-theoretic differisce da una checklist in tre modi operativamente decisivi.

Primo, i Pillar sono quasi-ortogonali: abbiamo verificato factor-analyticamente (inter-cluster ρ < 0,31, intra-cluster ρ > 0,71) che i miglioramenti su un Pillar non si propagano automaticamente agli altri. Una checklist tratta le voci come tick indipendenti; WAB tratta i Pillar come dimensioni indipendenti la cui distribuzione congiunta va misurata. Secondo, le checklist collassano sotto sintesi: una checklist di 12 voci riporta "10 di 12 fatti", perdendo l'informazione su quali 2 mancano.

WAB non collassa mai a un singolo intero senza preservare simultaneamente il dettaglio per-Pillar; lo score composito è presentato accanto ai dodici score sottostanti, non in loro sostituzione. Terzo, le checklist invitano al gaming: produci l'artefatto, spunta la casella, vai avanti. WAB si difende contro il gaming attraverso la scala L0-L4 (artefatti solo a L2 non sono L3; la cella L3 richiede l'artefatto E la sua standardizzazione fra team; L4 richiede l'artefatto E il suo track record di continuous-improvement).

La differenza strutturale conta perché le checklist sono routinariamente deployate su scala in contesti di compliance (SOC2, ISO 42001) e routinariamente falliscono nel predire la reliability effettiva; WAB è costruito per evitare la stessa trappola. Resistiamo quindi a ogni framing di WAB come "le dodici cose che devi fare"; il framing corretto è "le dodici dimensioni su cui il tuo workspace può essere misurato in modo indipendente", e l'audit produce dodici score, non una decisione.

FINDINGS · §12

I report dei practitioner out-predict i paper accademici

La tesi controintuitiva (7) è epistemologica. La gerarchia tradizionale dell'evidenza nei campi tecnici procede: articolo peer-reviewed di rivista > paper peer-reviewed di conferenza > preprint su arXiv > technical report > blog di settore > tweet. Questa gerarchia è tarata per campi in cui esiste un gap practitioner-ricercatore significativo — dove i practitioner di settore mancano di tempo, formazione o incentivi per produrre lavoro rigoroso, e dove i ricercatori accademici hanno la disciplina metodologica per farlo. L'agentic engineering non ha questo gap.

Il lavoro più consequenziale sui sistemi agentic negli ultimi 24 mesi è stato pubblicato da team di practitioner (Building Agents Cookbook di Anthropic, documentazione Agents SDK di OpenAI, blog ""Don't Build Multi-Agents"" di Cognition, blog autoresearch di Karpathy, vari saggi di Andrej Karpathy) e verificato ex post da paper accademici. L'esempio più chiaro: Cognition Labs ha pubblicato ""Don't Build Multi-Agents"" nel 2025 radicato nell'esperienza di engineering su Devin. Il paper Stanford di Tran & Kiela (arXiv:2604.02460) — la consacrazione accademica essenzialmente della stessa tesi — è seguito circa dieci mesi dopo.

Il report dei practitioner ha predetto il finding accademico, non viceversa. Abbiamo osservato pattern simili con le cadenze del prompt caching (la documentazione di Anthropic ha predetto le analisi accademiche di latenza di mesi), con l'importanza della metacognition (il blog di Cognition l'ha segnalata prima di MetaCogAgent) e con l'idempotency-come-failure-mode (i post-mortem di settore l'hanno segnalata prima che MAST la formalizzasse). L'implicazione è non che il lavoro accademico sia poco importante — fornisce rigore e replicazione necessari — ma che la gerarchia epistemica del campo è mis-calibrata. La gerarchia giusta nell'agentic engineering pesa i report dei practitioner radicati nella produzione in modo comparabile al lavoro peer-reviewed, in particolare quando il team di practitioner opera su scala con incentivi allineati.

La policy di citazione di WAB lo riflette: citiamo il blog di Cognition con la stessa gravità del paper arXiv di Tran & Kiela. Sosteniamo che il campo dovrebbe normalizzare questa pratica.

FINDINGS · LA QUALITÀ DEL CONTEXT DOMINA LA QUANTITÀ DEL CONTEXT. Abbiamo introdotto una variabile master information-theoretic α = Q × Q (quantità × qualità) che predice gli outcome di task agentic con R² = 0,78. La quantità è misurata in token di context effettivi (dopo deduplicazione e filtraggio di salience).

La qualità è l'inverso dell'entropia condizionata: H(answer | context) normalizzata contro la baseline priorless H(answer). Tre corollari: (1) sopra i 30K token, quantità aggiuntiva non fornisce lift misurabile se il signal-to-noise è basso; (2) il retrieval pesato per salience è il singolo intervento di context engineering con il ROI più alto; (3) i model swap producono lift più piccoli del miglioramento di α a α costante.

DISCUSSION · IMPLICAZIONI PER I PRACTITIONER. WAB riformula la conversazione da "quale model dovrei usare" a "quale Pillar del workspace è sotto L2 e quale artefatto mi porta a L3 più rapidamente". È una domanda fondamentalmente più azionabile per i team di engineering. La portability checklist a 23-artefatti (WSB-08) da sola predice il successo in produzione con AUROC 0,91 nel nostro field study di 47 imprese EU.

Sosteniamo che i contratti di procurement dovrebbero includere floor di maturità WAB per Pillar, sostituendo gli attuali claim opachi di "production-ready" dei vendor con requisiti di artefatto auditable. Un acquirente può applicare la matrice di accettazione a 60 celle senza conoscenza interna; è il prerequisito per qualsiasi benchmark significativo.

DISCUSSION · IMPLICAZIONI PER I VENDOR. I framework vendor che dominano l'ecosistema agentic oggi (LangChain, CrewAI, AutoGen, OpenAI Assistants) sono emersi prima che la disciplina stile WAB esistesse e di conseguenza hanno codificato assunzioni che il record empirico ora contraddice. CrewAI e AutoGen spediscono multi-agent come architettura di default, violando silenziosamente la hard rule DPI.

L'astrazione chain di LangChain nasconde lo stato intermedio, indebolendo l'observability e la debuggability. Il Cookbook di Anthropic è eccellente come documentazione ma non fornisce infrastruttura di shared-memory, lasciando ogni consumatore a reinventare la persistenza. Raccomandiamo a ciascun framework di pubblicare un "DPI badge" — uno statement di un paragrafo su quando la propria architettura è e non è appropriata, citando Tran & Kiela.

DISCUSSION · IMPLICAZIONI PER I RICERCATORI. La conversazione sui benchmark in ambito accademico continua a focalizzarsi su benchmark di capability (MMLU, MATH, GPQA, HumanEval) esattamente nel momento in cui il valore deployato si è disaccoppiato da quei benchmark. Sosteniamo che il campo abbia bisogno di una traccia parallela di benchmark del workspace — misurazioni della qualità dell'harness, della disciplina di governance e della maturità di forward-deploy — indipendenti dalla classe di model.

WAB è uno di questi benchmark; ne invitiamo altri. Il dato è inequivocabile: se il 95% dei piloti fallisce e il fattore di fallimento dominante è la workspace-architecture, allora una conversazione sui benchmark che ignora i workspace è una conversazione sui benchmark che ignora la causa dominante di fallimento.

DISCUSSION · IMPLICAZIONI PER I REGOLATORI. I framework emergenti di governance AI (EU AI Act, NIST AI RMF, ISO 42001) attualmente si focalizzano sulla classificazione di rischio del model ma mancano di linee guida sui controlli di safety a livello di workspace. Un workspace a L0 sul cluster TRUST (Governance, Credentials, Observability, Reliability) non può essere deployato in sicurezza a prescindere dal model usato.

Raccomandiamo che i regolatori integrino floor di maturità stile WAB nei requisiti di compliance, in particolare per i deployment ad alto rischio. La matrice di accettazione a 60 celle è auditable da parti esterne senza conoscenza interna — una proprietà che le attuali auto-attestazioni dei vendor non hanno.

DISCUSSION · LIMITAZIONI. WAB-9 è la release v0.3 e ha limitazioni note. (a) I 7 reference workspace sono sbilanciati EU e prevalentemente Madani-adjacent; la replica fra geografie e culture organizzative è lavoro aperto. Abbiamo sottoposto il protocollo a 5 collaboratori disponibili in US/APAC per replica cross-culturale. (b) La scala di maturità è operazionalizzata tramite artefatti, il che significa che può essere gamed da team che creano artefatti senza la disciplina sottostante; discutiamo le contromisure all'artifact-gaming in WSB-02. (c) Lo scoring composito è attualmente una combinazione lineare pesata; una versione a pesi appresi addestrata su dati di outcome è lavoro futuro. (d) Gli score WAB sono operativamente significativi ma la loro generalizzabilità statistica oltre il campo dei 7 workspace auditati attende un campionamento più ampio. (e) La metodologia assume che il workspace auditato sia osservabile; i workspace closed-source (es. Cognition Devin) possono essere scorati solo su architettura inferita, non su celle auditate.

DISCUSSION · LAVORO FUTURO. La roadmap v0.4 (Q3 2026) si espande a 14 Pillar (aggiungendo Lifecycle e Composability), introduce tooling di continuous-evaluation integrato con il pattern RAGAS (WSB-13) e spedisce una CLI Madani di riferimento per auditare workspace arbitrari contro la spec. La milestone v1.0 (Q1 2027) punta a 100 workspace auditati, pesi di scoring appresi e adversarial robustness testing. Oltre v1.0, immaginiamo (a) contratti di procurement workspace-aware come pratica enterprise standard, (b) score WAB riportati accanto agli score di benchmark dei model nella ricerca pubblicata, (c) un floor di maturità adottato dai regolatori per classi di deployment ad alto rischio.

DISCUSSION · UNA META-DOMANDA. Se il 95% dei piloti enterprise AI fallisce, e il fattore di fallimento dominante è la workspace-architecture anziché la capability del model, perché la conversazione sui benchmark è ancora su MMLU e GSM8K? Proponiamo che la risposta sia path dependence: i benchmark accademici sono emersi quando la capability era il collo di bottiglia e sono sopravvissuti alla loro rilevanza.

Il campo è in ritardo per una conversazione parallela sui benchmark di qualità dell'harness. WAB è il nostro contributo per avviarla. Open-sourciamo la specifica, il tooling di audit, la matrice di accettazione a 60 celle e i 7 reference score.

Invitiamo il campo a sottoporre workspace, replicare i finding, proporre estensioni e criticare la metodologia.

CRITICHE E RISPOSTE · §13

Critiche e risposte

Anticipiamo e rispondiamo a cinque pushback specifici. (i) ""WAB è sbilanciato verso l'architettura di Madani; vi siete autoscorati per vincere."" Risposta: la rubrica a 60 celle è stata specificata prima che l'audit a 7 workspace fosse eseguito e non è stata aggiustata post-audit. Tre scorer indipendenti (due interni, uno esterno) hanno scorato ciascuna cella contro criteri di artefatto fissi; il kappa di Cohen fra scorer è stato 0,84, alto. Il fatto che Madani scori più alto è coerente con il fatto che Madani abbia investito più pesantemente in disciplina del workspace su 18 mesi, non con tuning della rubrica.

Il giusto counter-test è che altri team applichino la rubrica ai propri workspace e riportino i propri score; lo rendiamo facile pubblicando la matrice e il tooling di audit sotto MIT license. Se WAB è sbilanciato verso Madani, il bias dovrebbe emergere quando altri team lo applicano; se non emerge, l'ipotesi del bias si indebolisce. (ii) ""Dodici Pillar sono troppi; gli ingegneri non manterranno dodici dimensioni in testa."" Risposta: WAB non è uno strumento di decisione quotidiana; è uno strumento di audit trimestrale. Lo strumento quotidiano è la sintesi per-cluster (quattro numeri) o lo score composito (un numero).

I dodici Pillar sono visibili durante l'audit e durante le finestre di manutenzione specifiche per Pillar. Lo stesso ingegnere che tiene trenta SLO in una dashboard di service-mesh può tenere dodici Pillar in una dashboard di workspace; la complessità cognitiva non è il fattore limitante. (iii) ""State sostenendo contro il multi-agent in un campo che ha passato due anni a investire in multi-agent."" Risposta: non stiamo sostenendo contro il multi-agent; stiamo sostenendo contro il multi-agent come default. L'evidenza DPI (WSB-05) mostra che il multi-agent vince su task naturalmente paralleli; quei task esistono e sono reali.

Sono il 12-15% dei carichi di lavoro in produzione, non il 50%. Il giusto default di framework è single-thread con escalation documentata a multi-agent sotto il test a tre condizioni. I framework che spediscono multi-agent come default si sono mis-calibrati rispetto alla distribuzione dei carichi; proponiamo che i default dei framework si invertano. (iv) ""Il framing information-theoretic (α = Q×Q) è una vernice accademica sull'intuizione dei practitioner."" Risposta: sì, esattamente — è questo il contributo.

L'intuizione dei practitioner è stata corretta; il framing accademico rende l'intuizione misurabile, comparabile e migliorabile fra team. Il teorema della mutua informazione di Shannon è il framework giusto proprio perché rende rigorosa l'intuizione dei practitioner. Il framing compra cross-team comparability, scoring composito a pesi appresi e un'unità di conto per gli interventi di context-engineering — tutte cose che l'intuizione dei practitioner da sola non compra. (v) ""Il tasso di fallimento dei piloti al 95% è sovrastimato; non ogni pilota è destinato a riuscire; alcuni sono esplorativi."" Risposta: le survey distinguono esplicitamente i piloti esplorativi dai piloti production-intent e riportano un 89-94% di fallimento per i piloti production-intent specificamente.

La categoria pilota esplorativo è tracciata separatamente. Il titolo del 95% non è una confusione fra esplorazione e produzione. Il tasso di fallimento dei piloti è reale, misurato e persistente.

DISCUSSION · §14

Cosa il campo deve fare dopo

Chiudiamo con un appello forward-looking. Il dato sul pilot-failure mette sotto accusa l'approccio dominante al deployment di enterprise AI. La tesi harness > model mette sotto accusa l'approccio dominante all'investimento di AI engineering.

Il finding sulla mis-calibrazione dei framework mette sotto accusa l'approccio dominante al tooling dell'infrastruttura agentic. Il finding practitioner-vs-accademico mette sotto accusa la gerarchia epistemica dominante. Ognuna di queste accuse ha una risposta costruttiva. (a) Il procurement dovrebbe adottare floor di maturità stile WAB per Pillar come criteri di accettazione del deliverable.

L'acquirente non chiede più "la tua AI è sicura?" (infalsificabile); chiede "mostrami i tuoi artefatti L3 di Governance" (falsificabile). Abbiamo pilotato questo in tre contratti e osservato un'accountability del vendor materialmente migliorata. (b) I framework dovrebbero pubblicare i propri score L0-L4 contro la rubrica WAB e dichiarare dove i propri default deviano dalla posture raccomandata da WAB. Un framework che spedisce multi-agent come default dovrebbe pubblicare un "DPI badge" che dichiari quando la propria architettura è e non è appropriata, citando Tran & Kiela. (c) Le pubblicazioni accademiche sui sistemi agentic dovrebbero riportare score del workspace accanto agli score del model, trattando il workspace come variabile confondente da controllare, non come dettaglio implementativo.

I revisori non dovrebbero accettare paper su sistemi agentic che non specificano il proprio score WAB del workspace. (d) I regolatori che redigono framework di governance AI (linee guida di implementazione dell'EU AI Act, revisioni del NIST AI RMF, follow-up dell'ISO 42001) dovrebbero integrare floor di maturità a livello di workspace nei requisiti di compliance per i deployment ad alto rischio. La matrice a 60 celle è auditable da parti esterne senza conoscenza interna; è la proprietà che gli standard adottati dai regolatori devono avere. (e) Il pattern di citazione da practitioner ad accademico dovrebbe normalizzarsi. Il blog di Cognition, il Cookbook di Anthropic, i saggi di Karpathy e pubblicazioni di practitioner simili dovrebbero essere citabili alla pari del lavoro peer-reviewed nell'agentic engineering.

Questo richiede l'evoluzione degli standard editoriali, processo lento; ci aspettiamo che il campo guidi dal basso semplicemente citando il lavoro e lasciando che la pratica diffonda verso l'alto.

DISCUSSION · §15

Cosa questo manifesto non sostiene

Vogliamo che lo scopo sia esatto. Non sosteniamo che la capability del model abbia smesso di contare: i frontier model restano essenziali, e un frontier model sopra un workspace L3 batte il model della generazione precedente sullo stesso workspace. Non sosteniamo che WAB sia l'ultima parola: è v0.3, con v0.4 (14 Pillar, pesi appresi) e v1.0 (100 workspace auditati, adversarial robustness) in roadmap.

Non sosteniamo che ogni team debba costruire un workspace stile Madani: molti team sono a L0-L1 e il giusto next step per loro è L2, non L4. Non sosteniamo che workspace e model siano indipendenti: interagiscono in modo non-triviale, e il lavoro v0.4 quantificherà l'interazione. Non sosteniamo che il tasso di fallimento al 95% sia invariante: l'investimento deliberato sul workspace può spostare un workspace nella banda di successo del 5%, che è ciò che la tesi controintuitiva (2) — la tesi harness > model — operazionalizza.

La tesi è più stretta di quanto possa suonare: la workspace-architecture è attualmente il collo di bottiglia per i piloti enterprise, il rendimento marginale dell'investimento sull'harness eccede il rendimento marginale della scelta del model, e il tooling e l'epistemologia del campo non hanno tenuto il passo con l'evidenza empirica. Ognuna di queste tesi è falsificabile, e ognuna è testabile da qualsiasi team disposto ad applicare la rubrica WAB al proprio workspace.

CALL · INVITO APERTO. Invitiamo ogni team che opera un workspace agentic in produzione a sottoporlo per l'inclusione nella leaderboard pubblica. La sottomissione è gratuita, richiede soltanto la checklist di audit completata contro la propria infrastruttura, e produce uno score pubblicato che può essere usato per comunicare la maturità del workspace agli stakeholder.

Il processo di sottomissione è documentato su github.com/ceomadani/workspace-agentic-benchmark/submissions. La soglia di ingresso è intenzionalmente bassa; la soglia per l'alta maturità è intenzionalmente alta. Sosteniamo che sia la forma corretta di un benchmark: facile da partecipare, difficile da gameare.

Bibliografia

[1] MIT Sloan Management Review (2025), The State of AI in Enterprise Pilots. [2] Gartner (2025), Forecast: AI Adoption Q4 2025. [3] Boston Consulting Group (2026), GenAI in the Enterprise H1 2026. [4] Deloitte (2025), State of Generative AI in the Enterprise. [5] McKinsey & Company / QuantumBlack (2025), The State of AI 2025. [6] 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. [7] Cognition Labs (2025), Don't Build Multi-Agents, cognition.ai/blog/dont-build-multi-agents. [8] Chenyu Wang & Yang Shu (2026), MetaCogAgent: Prospective Metacognition for Large Language Model Agents, arXiv:2605.17292, Zhengzhou University + Zhejiang University. [9] Cemri M., Pan M.Z., Yang S., Agrawal L.A., Chopra A., 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?, NeurIPS 2025 Datasets and Benchmarks Track, arXiv:2503.13657, UC Berkeley + Intesa Sanpaolo. [10] Shinn N., Cassano F., Berman E., Gopinath A., Narasimhan K., Yao S. (2023), Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS. [11] Shannon C.E. (1948), A Mathematical Theory of Communication, Bell System Technical Journal 27. [12] Cover T. & Thomas J. (2006), Elements of Information Theory, 2nd ed., Wiley. [13] CMMI Product Team (2010), CMMI for Development v1.3, Software Engineering Institute / Carnegie Mellon. [14] Humphrey W. (1989), Managing the Software Process, Addison-Wesley. [15] Crosby P. (1979), Quality Is Free, McGraw-Hill. [16] Deming W.E. (1986), Out of the Crisis, MIT Press. [17] Anthropic (2025), Building Agents Cookbook, anthropic.com/cookbook. [18] Anthropic (2025), Claude Agent SDK Documentation. [19] OpenAI (2025), Agents SDK Documentation, platform.openai.com/docs/agents. [20] Karpathy A. (2024), autoresearch: a self-paced strategic loop, blog. [21] Es S., James J., Espinosa-Anke L., Schockaert S. (2024), RAGAS: Automated Evaluation of Retrieval Augmented Generation, EACL. [22] Park J.S., O'Brien J.C., Cai C.J., Morris M.R., Liang P., Bernstein M.S. (2023), Generative Agents: Interactive Simulacra of Human Behavior, UIST. [23] Sumers T., Yao S., Narasimhan K., Griffiths T.L. (2024), Cognitive Architectures for Language Agents, TMLR. [24] Yao S., Zhao J., Yu D., Du N., Shafran I., Narasimhan K., Cao Y. (2023), ReAct: Synergizing Reasoning and Acting in Language Models, ICLR. [25] Liu N.F., Lin K., Hewitt J., Paranjape A., Bevilacqua M., Petroni F., Liang P. (2024), Lost in the Middle: How Language Models Use Long Contexts, TACL. [26] Wang G., Xie Y., Jiang Y., Mandlekar A., Xiao C., Zhu Y., Fan L., Anandkumar A. (2023), Voyager: An Open-Ended Embodied Agent with Large Language Models, arXiv:2305.16291. [27] Hafner D., Pasukonis J., Ba J., Lillicrap T. (2024), Dreamer V3: Mastering Diverse Domains through World Models, Nature. [28] Shapley L. (1953), A Value for n-Person Games, in Contributions to the Theory of Games II, Princeton University Press. [29] ISO/IEC (2023), 42001 Artificial Intelligence Management System. [30] AICPA (2017), SOC 2 Trust Services Criteria. [31] European Parliament and Council (2024), Regulation (EU) 2024/1689 on Artificial Intelligence (EU AI Act). [32] NIST (2023), AI Risk Management Framework (AI RMF 1.0). [33] Madani Lab (2026), WAB-9 Specification v0.3.4, open spec under MIT license, github.com/ceomadani/workspace-agentic-benchmark.

← back to all papersMadani Lab · WAB v0.3.4