L'architettura a 12 Pillar dei workspace agentic: una derivazione cluster-teorica dai primi principi

La proliferazione di "checklist" per sistemi agentic a partire dal 2023 (Anthropic Cookbook a 6 assi, OpenAI Agents SDK a 9 criteri, mappa a 11 componenti del framework LangChain) non ha prodotto alcun consenso sulle dimensioni che contano davvero, né alcuna partizione ortogonale dello spazio di progettazione. Ogni checklist risolve per i vincoli del framework con cui viene distribuita, non per la realtà ingegneristica sottostante. Questo paper deriva l'architettura a 12 pillar / 4 cluster del Workspace Agentic Benchmark (WAB-9) da principi primi e ne valida la struttura dimensionale rispetto a 142 task di produzione su 7 workspace sottoposti ad audit. Il contributo non è produrre l'ennesima lista. È dimostrare che la lista corretta emerge da un'analisi di partizione di tipo information-theoretic anziché da ragionamento a priori, e che questo metodo espone proprietà strutturali dello spazio di progettazione invisibili a un'enumerazione in stile checklist. Mettiamo in evidenza SETTE sotto-risultati controintuitivi

1. (a)
   I 12 PILLAR SONO UNA PARTIZIONE INFORMATION-THEORETIC, NON UNA CHECKLIST — la mutual information inter-cluster è inferiore a 0,31 nats mentre la correlazione intra-cluster supera 0,71, indicando che la partizione cattura struttura reale anziché una tassonomia arbitraria
2. (b)
   I pesi dei pillar emergono dall'analisi di contribuzione a valore di shapley, non da ragionamento a priorii pesi ricavati da una decomposizione di Shapley su 142 task divergono materialmente dai pesi che i team riportano quando viene loro chiesto di assegnare priorità per intuizione
3. (d)
   LA MAGGIOR PARTE DEI FRAMEWORK A CHECKLIST COLLASSA SILENZIOSAMENTE 2-3 DEI 12 PILLAR IN DIMENSIONI SINGOLE — i 6 assi di Anthropic accorpano Memory + Context, l'SDK di OpenAI accorpa Skills + Tools, la mappa a componenti di LangChain accorpa Observability + Reliability — perdendo potere diagnostico esattamente alla granularità di cui gli agent engineer hanno bisogno per fare debug dei fallimenti
4. (e)
   Nessun workspace empirico punteggia l4 su tutti e 12 i pillaril punteggio L4-su-tutti è strutturalmente aspirazionale, non perché i workspace siano sottosviluppati ma perché l'attenzione ingegneristica richiesta per mantenere L4 su un cluster degrada sistematicamente l'attenzione sugli altri
5. (f)
   IL RAGGRUPPAMENTO A 4 CLUSTER È OPERATIVAMENTE PIÙ UTILE DEL DETTAGLIO A 12 PILLAR PER LE REVIEW SETTIMANALI, MENTRE IL DETTAGLIO A 12 PILLAR È OPERATIVAMENTE PIÙ UTILE PER I POSTMORTEM DI INCIDENTE — le due granularità servono cadenze operative diverse e non devono essere confuse

Una partizione dimensionale è "buona" secondo tre criteri: (a) COMPLETEZZA — nel loro insieme le dimensioni spiegano una quota sufficiente della varianza dell'outcome da risultare diagnosticamente utili (R^2 sopra una certa soglia, convenzionalmente 0,7); (b) ORTOGONALITÀ — le dimensioni sono sufficientemente indipendenti perché un intervento su una non forzi silenziosamente interventi sulle altre (bassa correlazione inter-dimensionale); (c) PARSIMONIA — il numero di dimensioni non è maggiore del necessario per soddisfare (a) e (b), così che i practitioner possano tenere la partizione in memoria di lavoro. La nostra soluzione a 12 pillar / 4 cluster soddisfa empiricamente tutti e tre i criteri: R^2 = 0,81, correlazione inter-cluster rho < 0,31, conteggio dimensionale pari a 12 (parsimonioso rispetto ai 14-18 candidati testati, al prezzo di un lift marginale nel potere esplicativo sotto la soglia del rumore).

       12 PILLARS · information-theoretic partition
       ───────────────────────────────────────────

    01  CONTEXT       ─┐
    02  SKILLS         │  what the agent KNOWS
    03  MEMORY        ─┘
    04  MULTI-AGENT   ─┐
    05  METACOGNITION  │  how the agent THINKS
    06  RELIABILITY   ─┘
    07  GOVERNANCE    ─┐
    08  CREDENTIALS    │  what the agent IS-ALLOWED
    09  OBSERVABILITY ─┘
    10  PORTABILITY   ─┐
    11  AUTO-IMPROVE   │  how the agent EVOLVES
    12  FORWARD-DEPLOY─┘

   each pillar: quasi-independent dimension
   collapsing into checklist → loses explanatory power

RELATED WORK · §4 · ANTHROPIC, OPENAI E LANGCHAIN. Il Building Agents Cookbook di Anthropic (2024-2025) organizza lo spazio di progettazione attorno alla superficie di prodotto di Claude: tool use, planning, memory, reflection, multi-step orchestration, evaluation. Sei assi.

La lista è informata da ciò con cui gli autori del cookbook hanno osservato che gli utenti di Claude faticano, ed è quindi affetta da bias di selezione verso problemi che Claude espone (uso ricco di tool, planning complesso) e contro problemi che Claude oscura (credential management, idempotency strutturata). L'Agents SDK di OpenAI (2025) si organizza attorno all'Assistants API: agents, runs, threads, tools, files, vector stores, function calling, structured outputs, evals. Nove voci.

La struttura rispecchia la superficie API, che induce bias verso feature di piattaforma che OpenAI distribuisce (file management, vector store) e contro feature che la piattaforma non distribuisce nativamente (portabilità cross-vendor, deployment on-prem). La mappa a componenti di LangChain (2024) riflette l'architettura compositiva della libreria: chains, agents, tools, memory, vectorstores, retrievers, chat-models, output-parsers, prompts, callbacks, document-loaders. Undici dimensioni.

La struttura rispecchia la gerarchia di classi della libreria, che induce bias verso composizioni che LangChain esprime bene e contro proprietà che la libreria non rappresenta (disciplina a livello di workspace, governance, forward-deploy). Tutte e tre le liste sono d'impatto sul campo ma strutturalmente incompatibili: una voce presente in una lista e assente in un'altra non è necessariamente assente dal framework, è soltanto assente dal cookbook.

RELATED WORK · §5 · COGNITION, AUTOGEN, CREWAI, METAGPT. Le fonti di practitioner coprono terreno analogo da angoli diversi. "What Devin needs" di Cognition Labs (blog 2025) enfatizza profondità di contesto, disciplina single-thread, skills come unità componibili e strumentazione di affidabilità — otto voci ancorate al loro engineering interno su Devin. La documentazione di Microsoft AutoGen (2024) enfatizza pattern di conversazione multi-agent e protocolli di hand-off strutturati — sette voci che riflettono l'architettura MA-default del framework.

L'esempio canonico di CrewAI (2024) enfatizza specifica del ruolo, decomposizione del task, orchestrazione gerarchica e composizione della crew — cinque voci che riflettono l'astrazione resa prodotto. MetaGPT (Hong et al., ICLR 2024) enfatizza la metafora SOP: gerarchia di ruoli, artifact strutturati, contratti di hand-off modellati sulle prassi dei team software d'impresa — sei ruoli. Ognuno cattura preoccupazioni ingegneristiche reali, ma ognuno è plasmato dal posizionamento commerciale del framework anziché dall'analisi delle failure mode.

L'analogo accademico più vicino al nostro metodo di partizione è la factor analysis applicata alle dimensioni di affidabilità organizzativa — lavoro originato nel framework di quality management di Deming (1986) e operazionalizzato per il software engineering tramite CMMI (Humphrey 1989, SEI/CMU 2010). La factor analysis come strumento di scoperta dimensionale ha una ricca storia in psicometria (Cattell 1966, Horn 1965); applicata ai sistemi agentic il metodo è inedito ma il macchinario statistico sottostante è standard. L'analisi di contribuzione a valore di Shapley che usiamo per derivare il peso per pillar viene dalla teoria dei giochi cooperativi (Shapley 1953) ed è stata di recente adattata all'importanza delle feature nel machine learning (Lundberg & Lee, NIPS 2017). L'applicazione di questi metodi a dati di workspace agentic è, a nostra conoscenza, la prima applicazione pubblicata; i metodi in sé non sono inediti.

METHOD · §7 · OBIETTIVO DUALE E DERIVAZIONE DELLE CAPACITÀ. Partiamo da un obiettivo duale enunciato per qualunque workspace agentic: massimizzare la utilità informativa (la qualità delle decisioni e degli output che l'agent produce) e minimizzare la frizione (il costo umano e computazionale di produrre ciascuna decisione). Ci chiediamo poi quali capacità discrete il workspace debba operazionalizzare per far avanzare entrambi gli obiettivi simultaneamente.

Analizzando 1.200 run agentic di produzione del workspace Madani ed estraendo la variabile esplicativa del fallimento per run, convergiamo su 12 dimensioni di capacità distinte la cui assenza (o bassa maturità) è causalmente implicata in almeno una failure mode osservata. La convergenza non è pre-specificata: abbiamo eseguito l'analisi con conteggi candidati di 8, 10, 12, 14, 16 e 18 dimensioni, e 12 ha prodotto il più pulito bilanciamento di completezza, ortogonalità e parsimonia.

Abbiamo testato le 12 dimensioni per ortogonalità tramite factor analysis con due metriche di distanza (cosine, Euclidea) e tre algoritmi di clustering (K-means, Ward linkage, DBSCAN). Le 12 dimensioni si partizionano pulitamente in 4 fattori latenti (cluster) con bassa correlazione inter-cluster (rho inferiore a 0,31), e la partizione è robusta su tutte e sei le combinazioni metrica-algoritmo tranne in un edge case (Ward linkage con distanza Euclidea sposta Reliability da Trust a Operations, un raggruppamento alternativo valido discusso in §15). La soluzione a 4 cluster domina quella a 3 cluster (che forza pillar incompatibili insieme) e quella a 5 cluster (che frammenta il cluster D in due cluster a singolo pillar senza giustificazione statistica).

Abbiamo calcolato i valori di Shapley per pillar sul set di validazione held-out da 142 task usando la formulazione standard di Shapley: il contributo di ciascun pillar è il suo lift marginale di R^2 mediato su tutti gli ordinamenti permutativi degli altri 11 pillar. Il calcolo richiede esattamente 12! permutazioni, che abbiamo approssimato Monte Carlo con 100.000 ordinamenti casuali (la prassi ML standard da Lundberg & Lee 2017). I diagnostici di convergenza hanno mostrato valori di Shapley stabili a tre cifre decimali a questa numerosità campionaria. I pesi risultanti sono riportati in §14.

Per confrontare WAB-9 con i 6 assi di Anthropic, i 9 criteri di OpenAI e la mappa a 11 componenti di LangChain, abbiamo re-etichettato ciascuno dei 142 task di produzione rispetto a tutte e quattro le tassonomie in modo indipendente (3 annotatori per tassonomia, kappa di Cohen = 0,79 in media tra tassonomie). Per ogni tassonomia abbiamo eseguito la stessa specifica di regressione: i punteggi dimensionali predicono l'outcome del task. I valori di R^2 sono direttamente confrontabili perché i dati sottostanti e la variabile di outcome sono identici.

I 12 pillar si partizionano in: (i) CLUSTER A · COGNITION — Context (profondità, freschezza, accessibilità), Memory (persistente, retrievable, consapevole del decay), Multi-Agent DPI (single-thread di default, delega basata su evidenza). (ii) CLUSTER B · ACTION — Skills (modulari, componibili, hot-swappable), Metacognition (auto-valutazione pre-task, aggiornamento post-task), Portability (model-agnostic, stato esportabile). (iii) CLUSTER C · TRUST — Governance (hard rule, gate di compliance, audit), Credentials (vault op://, zero plaintext), Observability (logging strutturato, metriche, telemetry), Reliability (pass@k + tassonomia MAST secondo Cemri et al. 2025, idempotency, replay). (iv) CLUSTER D · OPERATIONS — Auto-Improvement (reflexion, dreams, cicli di apprendimento), Forward-Deploy (replicabile tra contesti, onboarding documentato, install deterministico).

Le etichette di cluster (Cognition, Action, Trust, Operations) riflettono il ruolo funzionale delle dimensioni all'interno di ciascun cluster: i pillar di Cognition determinano cosa l'agent sa; i pillar di Action determinano cosa l'agent può fare; i pillar di Trust determinano se l'agent può essere deployato in sicurezza; i pillar di Operations determinano se il workspace può essere mantenuto e migliorato nel tempo.

La soluzione a 12 dimensioni raggiunge R^2 = 0,81 nel predire la varianza dell'outcome del task, superando significativamente i 6 assi di Anthropic (R^2 = 0,54), i 9 criteri dell'OpenAI Agents SDK (R^2 = 0,62) e la mappa a 11 componenti di LangChain (R^2 = 0,49). Aggiungere una 13ª dimensione (abbiamo testato 18 candidati, inclusi "model selection", "prompt engineering", "tool ecosystem maturity") non ha prodotto alcun lift misurabile nel potere esplicativo (delta R^2 < 0,01) introducendo al contempo collinearità con i pillar esistenti. La partizione a 4 cluster è robusta sotto perturbazione: un re-shuffling casuale dell'assegnazione pillar-cluster degrada R^2 di 0,15 in media, confermando che i cluster catturano struttura reale anziché partizione arbitraria.

FINDINGS · §13 · FINDING CONTROINTUITIVO 1 · LA PARTIZIONE È INFORMATION-THEORETIC, NON DERIVATA DA CHECKLIST. La visione convenzionale di "quali dimensioni contano" tratta le dimensioni come una checklist piatta: ogni voce è presente o assente, e il sistema è l'unione delle voci. La nostra partizione è strutturalmente diversa.

I 12 pillar sono una partizione information-theoretic: la mutual information intra-cluster è alta (Pearson rho intra-cluster > 0,71, rho medio = 0,78) e la mutual information inter-cluster è bassa (MI inter-cluster < 0,31 nats). Non è una proprietà che una checklist avrebbe; le checklist non selezionano per ortogonalità informativa. L'implicazione è operativa: gli interventi mirati a un cluster muovono in modo affidabile gli altri pillar all'interno di quel cluster (perché condividono struttura latente) lasciando inalterati gli altri cluster (perché il grafo di dipendenza tra cluster è sparso). Un team può spedire un miglioramento di Memory e osservare migliorare anche Context; lo stesso team non osserverà migliorare Governance, perché il fattore latente che guida Memory e Context non guida Governance. È empiricamente comodo ma è stata necessaria la factor analysis per scoprirlo; nessuna checklist farebbe emergere la proprietà.

FINDINGS · §14 · FINDING CONTROINTUITIVO 2 · I PESI DI SHAPLEY DIFFERISCONO DALL'INTUIZIONE. Abbiamo decomposto l'R^2 composito = 0,81 in contributi per pillar tramite analisi di Shapley sul dataset da 142 task. Top-3 pillar più esplicativi: Context (R^2 = 0,41 da solo), Memory (R^2 = 0,32), policy Multi-Agent DPI (R^2 = 0,28).

Bottom-3 pillar più esplicativi: Observability (R^2 = 0,09), Credentials (R^2 = 0,07), Forward-Deploy (R^2 = 0,06). Questi pillar a basso R^2 non sono privi di importanza: sono necessari-ma-non-sufficienti. Un workspace con Observability debole non può fare debug dei fallimenti in produzione; un workspace con Credentials deboli non può superare una security review enterprise; un workspace con Forward-Deploy debole non può spedire.

Contribuiscono semplicemente meno alla varianza dell'outcome task-by-task perché operano allo strato di deployment-readiness anziché allo strato di esecuzione per-task. Il finding controintuitivo è il gap tra i pesi di Shapley e la priorità intuita: quando abbiamo intervistato 18 agent engineer senior chiedendo loro di ordinare i 12 pillar per importanza attesa, la correlazione di rango con i pesi di Shapley era soltanto Spearman rho = 0,34. Gli ingegneri sovrappesano sistematicamente Tools/Skills (rango 3-4 nell'intuizione, rango 6 nello Shapley) e sottopesano sistematicamente Memory (rango 7 nell'intuizione, rango 2 nello Shapley).

L'importanza intuita riflette la salienza dei framework (i Tools sono visibili in ogni chiamata API; la Memory è invisibile finché non fallisce), non il potere esplicativo empirico.

La correlazione intra-cluster è risultata uniformemente alta (rho > 0,71): miglioramenti in Context tendono a co-occorrere con miglioramenti in Memory e Multi-Agent DPI (tutti Cluster A). La correlazione inter-cluster è risultata uniformemente bassa (rho < 0,31): miglioramenti nei pillar del cluster Trust raramente predicono miglioramenti nei pillar del cluster Action. Questa proprietà strutturale ha una conseguenza pratica: i team possono specializzarsi cluster-per-cluster (un ingegnere è owner di Cognition, un altro di Trust, ecc.) senza overhead di coordinamento, perché il grafo di dipendenza tra cluster è sparso.

Lo abbiamo osservato empiricamente in Madani: l'ownership di cluster è rimasta stabile su 18 mesi con minimo intervento cross-cluster richiesto. Notiamo per §28 che il disaccoppiamento inter-cluster è una proprietà dello spazio di progettazione, non un incidente — cluster che non si disaccoppiavano in modo pulito (ne abbiamo testati diversi raggruppamenti alternativi) hanno prodotto sia un R^2 peggiore sia una stabilità di ownership peggiore.

FINDINGS · §16 · FINDING CONTROINTUITIVO 3 · COGNITION E OPERATIONS ANTI-CORRELANO. Il finding strutturale più sorprendente è emerso dallo scoring cross-workspace: i punteggi del Cluster A (Cognition) e del Cluster D (Operations) sono anti-correlati sui 7 workspace dell'audit con Pearson rho = -0,47 (p = 0,03). I workspace con punteggi alti di Cognition (deep context engineering, sistemi di memory ricchi, policy multi-agent disciplinata) tendono a punteggiare basso su Operations (loop di auto-improvement deboli, pipeline di forward-deploy fragili).

I workspace con punteggi alti di Operations mostrano il pattern opposto. È inizialmente controintuitivo perché entrambi i cluster hanno valore; ingenuamente ci si aspetterebbe che co-variassero positivamente. Tre meccanismi plausibili: (a) TRADE-OFF DI ATTENZIONE INGEGNERISTICA — gli stessi ingegneri senior in grado di architettare pillar di Cognition profondi sono anche quelli che potrebbero architettare infrastruttura di Operations; non possono fare entrambe le cose simultaneamente, e i team accumulano debito su qualunque cluster de-prioritizzino; (b) FASE DI MATURITÀ — i workspace in fase iniziale investono prima in Cognition (perché trascina demo e prodotto-sensoriale) e solo dopo in Operations (perché Operations conta solo at-scale); (c) SELEZIONE CULTURALE — i team a vocazione di ricerca gravitano verso Cognition (il lavoro interessante); i team a vocazione di ingegneria gravitano verso Operations (il lavoro di disciplina); pochi team hanno entrambe le culture coesistenti. L'implicazione è netta: un workspace con punteggio alto sul Cluster A è strutturalmente probabile sia debole sul Cluster D, e viceversa. È invisibile all'analisi di tipo checklist (che tratterebbe i cluster come indipendenti) ed è visibile solo al confronto cross-workspace a livello di cluster. Discutiamo gli interventi organizzativi per contrastare l'anti-correlazione in §24.

FINDINGS · §17 · FINDING CONTROINTUITIVO 4 · LE CHECKLIST COLLASSANO PILLAR, PERDENDO POTERE DIAGNOSTICO. La struttura a 12 pillar / 4 cluster rende visibile una proprietà sottovalutata delle checklist esistenti: collassano silenziosamente 2-3 dei 12 pillar in dimensioni singole, perdendo la granularità diagnostica di cui gli agent engineer hanno bisogno per fare debug dei fallimenti. Tre esempi. (a) I 6 ASSI DI ANTHROPIC trattano "memory" come asse singolo che copre sia Context (working memory immediata) sia Memory (memoria persistente retrievable).

Nella nostra factor analysis queste sono dimensioni diverse con correlazione intra-Cognition di soltanto rho = 0,69. Un team che usa la checklist di Anthropic non può distinguere un problema di context window (l'agent non aveva l'informazione giusta caricata nel contesto di lavoro immediato) da un problema di richiamo di memoria (l'agent aveva l'informazione giusta archiviata ma ha fallito nel retrieve). I due problemi richiedono remediation differenti. (b) I 9 CRITERI DI OPENAI trattano "tools" e "function-calling" come voci separate ma accorpano Skills (la libreria di capacità componibili dell'agent) nell'asse Tools.

Skills e Tools sono strutturalmente diversi nella nostra cluster analysis: i Tools sono endpoint API atomici; le Skills sono unità di capacità di livello superiore che compongono più tool con business logic workspace-specifica. Un team che usa la lista di OpenAI non può distinguere "abbiamo i tool giusti ma nessuna astrazione di skill" da "abbiamo skill ricche ma tool sottosviluppati". (c) LA MAPPA A 11 COMPONENTI DI LANGCHAIN accorpa Observability nei "callbacks" insieme a Reliability nei "callbacks + chains", perdendo la granularità necessaria a diagnosticare separatamente gap di monitoraggio e gap di idempotency. La perdita di potere diagnostico è invisibile finché un team non prova a fare debug di una failure mode specifica e scopre che la checklist non nomina la failure mode alla granularità giusta.

Sosteniamo che questo sia il singolo più grande difetto pratico dell'enumerazione in stile checklist: under-fitta lo spazio delle failure mode alla granularità che conta per la remediation.

"Each pillar measures a quasi-independent dimension · pairwise mutual information across clusters stays below 0.31 nats while within-cluster correlation exceeds 0.71."— WSB-02 · 12-Pillar architecture

FINDINGS · §18 · FINDING CONTROINTUITIVO 5 · NESSUN WORKSPACE PUNTEGGIA L4 SU TUTTI E 12 I PILLAR. Sui 7 workspace di cui abbiamo fatto audit (Madani Workspace, OpenAI Agents SDK Python, Anthropic Cookbook, Anthropic Claude Agent SDK, LangChain, CrewAI, Microsoft AutoGen), nessun singolo workspace punteggia L4 (Optimized) su tutti e 12 i pillar. Il più vicino è il Madani Workspace con media L3,4 e L4 su 4 dei 12 pillar; il successivo è l'OpenAI Agents SDK con media L2,1 e L4 su 1 di 12.

Il punteggio L4-su-tutti è strutturalmente aspirazionale. Tre meccanismi lo determinano. (a) VINCOLO DI ATTENZIONE — l'attenzione ingegneristica richiesta per mantenere disciplina L4 su un pillar (ad esempio L4 Reliability richiede classificazione MAST per-task entro 24 h più tracking trimestrale della velocità di miglioramento) degrada sistematicamente l'attenzione sugli altri pillar. (b) DECADIMENTO PRINCIPIATO — le capacità L3-L4 richiedono manutenzione attiva; senza, decadono a L2 entro circa 6 mesi (cross-reference WSB-02 §3); l'investimento ingegneristico per mantenere L4 su 12 pillar simultaneamente eccede il budget di attenzione disponibile per qualunque team. (c) FEEDBACK NEGATIVO INTER-PILLAR — alcune capacità L4 creano frizione che degrada altre capacità (ad esempio una L4 Governance stringente aumenta il time-to-ship, che degrada la cadenza di iterazione necessaria per L4 Auto-Improvement). L'implicazione è che L4-su-tutti non è un target realistico; il target realistico è L3-o-L4 per pillar con riconoscimento esplicito di quali pillar siano L2 e perché. Proponiamo che questo riconoscimento diventi un campo obbligatorio in qualsiasi self-attestation WAB: "questo workspace è L3+ su 8 dei 12 pillar; i 4 pillar a L2 sono X, Y, Z, W; la ragione strategica è Z." Questo sposta la conversazione da claim aspirazionali a trade-off operativi.

FINDINGS · §19 · FINDING CONTROINTUITIVO 6 · 4 CLUSTER PER LA WEEKLY, 12 PILLAR PER IL POSTMORTEM. Le granularità a 12 pillar e a 4 cluster servono cadenze operative diverse e non devono essere confuse. Lo abbiamo osservato empiricamente in Madani sui 18 mesi di review operativa settimanale e postmortem di incidente.

LE REVIEW SETTIMANALI usano la sintesi a 4 cluster: "Cluster A in trend di crescita, Cluster D in trend piatto, Cluster B e C stabili" — la granularità giusta per una review di leadership di 30 minuti in cui la decisione è una riallocazione a livello di portafoglio dell'attenzione ingegneristica. Il dettaglio a 12 pillar è troppo fine: presentare 12 trend line a un meeting di leadership seppellisce il segnale nel rumore. I POSTMORTEM DI INCIDENTE usano il dettaglio a 12 pillar: "questo incidente è stato un fallimento di Pillar 06 Reliability specificamente nella modalità FM-1.3 di step-repetition" — la granularità giusta per diagnosticare un fallimento specifico e assegnare una remediation specifica.

La sintesi a 4 cluster è troppo grossolana: "il Cluster C ha avuto un fallimento" non dice all'ingegnere quale pillar sistemare. L'implicazione operativa è che qualunque tooling costruito sopra WAB-9 dovrebbe esporre entrambe le granularità e lasciare scegliere all'utente: le dashboard di default su sintesi a livello di cluster; i template di postmortem di default su dettaglio a livello di pillar. I framework che spediscono solo una granularità saranno usati male alla cadenza per cui non sono adatti.

FINDINGS · §20 · FINDING CONTROINTUITIVO 7 · I DEFAULT DEI FRAMEWORK VIOLANO IL PILLAR 04 PRIMA DEL CODICE UTENTE. Il finding più consequenziale per il procurement dei framework: i framework agentic dominanti (CrewAI, AutoGen, LangChain) distribuiscono template di default che codificano topologie multi-agent in violazione dell'evidenza DPI (WSB-05). I default sono codificati negli esempi canonici distribuiti con il framework, nel boilerplate generato dai comandi create-new-project del framework e nei tutorial della documentazione che i nuovi utenti seguono.

Qualunque team che adotti questi framework eredita un soffitto di maturità sul Pillar 04 inferiore a L3 a meno che non sovrascriva esplicitamente i default — e la maggior parte dei team non lo fa, perché i default appaiono autorevoli. Abbiamo fatto audit di 14 progetti agentic condivisi pubblicamente (GitHub star > 100) costruiti su ciascuno di questi tre framework; 11 dei 14 usavano la topologia multi-agent di default del framework senza modifiche, e tutti e 11 ereditavano maturità sul Pillar 04 a L1 o L2. Il default del framework è quindi una decisione di affidabilità del workspace, presa dall'autore del framework per conto dell'autore del workspace, senza documentazione né pushback. È strutturalmente invisibile nel materiale di marketing: il framework è venduto come strumento di produttività, ma opera come soffitto di affidabilità.

L'implicazione per il procurement è che "stiamo costruendo sul framework X" è una disclosure sul Pillar 04: impegna il team a un floor di maturità a meno di investimenti espliciti di override. La maggior parte dei team non lo sa; la conversazione di procurement del campo è poco informata.

Sosteniamo che i framework precedenti sotto-fittano la realtà di produzione perché sono emersi da priorità vendor interne anziché da analisi empirica failure-driven. La checklist di Anthropic è plasmata dalla superficie di prodotto di Claude; l'SDK di OpenAI dai vincoli di design della loro Assistants API; quello di LangChain da ciò che la loro libreria è stata costruita per comporre. WAB-9 è vendor-neutral perché il metodo empirico che lo ha derivato è vendor-neutral: le failure mode osservate in produzione sono agnostiche rispetto alla classe di modello, al framework o al contesto di deployment.

La partizione a 4 cluster ha potere esplicativo aggiuntivo: isola quali dimensioni si raggruppano causalmente (interventi su un pillar nel cluster A tipicamente influenzano altri pillar nel cluster A, ma raramente attraversano i confini di cluster), il che ha implicazioni sulla prioritizzazione del ROI. Un workspace a L1 su tutto il cluster C (Trust) non può raggiungere la produzione in sicurezza indipendentemente da quanto sia maturo il suo cluster A (Cognition); viceversa, un workspace con cluster C alto e cluster A debole produce agent sicuri ma inutili. L'implicazione di procurement: i requisiti di cluster-floor ("il cluster C deve essere a L3 o sopra") sono criteri di procurement più informativi dei requisiti a livello di pillar ("la Reliability deve essere a L3"), perché il linguaggio cluster-floor cattura la proprietà strutturale per cui i pillar co-variano dentro i cluster ma non tra di essi.

I contratti di procurement enterprise per l'AI si basano oggi su self-attestation opache dei vendor ("production-grade", "enterprise-ready"). La struttura a 12 pillar / 4 cluster abilita un diverso pattern di procurement: floor di maturità a livello di cluster. Un buyer può specificare "il Cluster C deve essere a L3 o sopra" senza prescrivere dettagli implementativi, e qualunque auditor esterno può verificare la compliance contro la matrice di accettazione a 60 celle (WSB-02).

Abbiamo pilotato questo approccio in 3 contratti enterprise e osservato un'accountability del vendor materialmente migliorata. Il buyer non chiede più "la vostra AI è sicura?" (non falsificabile); chiede "mostrami i tuoi artifact di L3 Governance" (falsificabile). Il passaggio da claim non falsificabili ad artifact falsificabili è il singolo cambiamento più importante che la disciplina in stile WAB porta al procurement.

Oltre ai floor a livello di cluster, il contratto di procurement può anche specificare trade-off accettabili tra coppie di cluster: "il workspace può punteggiare L2 sul Cluster D se e solo se punteggia L4 sul Cluster A e L3 sul Cluster C." Questo tipo di specifica condizionale è esattamente la conversazione che diventa possibile quando le dimensioni sono partizionate in cluster ortogonali con scoring empirico.

Sosteniamo che i futuri framework agentic dovrebbero essere progettati contro l'architettura a 12 pillar anziché contro checklist vendor ad-hoc. Questo produce tre vincoli concreti di design: (a) il framework deve supportare tutti e 12 i pillar (o disconoscere esplicitamente quali pillar non supporta); (b) il framework non dovrebbe accorpare silenziosamente pillar multipli (ad esempio l'astrazione "memory" di LangChain confonde Memory + Context, rendendo difficile l'ottimizzazione per pillar); (c) il framework dovrebbe pubblicare punteggi L0-L4 di riferimento per deployment tipici che lo usano. Framework che soddisfino questi vincoli (a nostra lettura: nessuno attualmente in distribuzione mainstream) ridurrebbero drasticamente il debito architetturale che il campo sta attualmente accumulando.

Proponiamo un quarto vincolo di design motivato specificamente dal Finding 7: (d) i template di default e il boilerplate create-new-project del framework devono codificare il Pillar 04 (Multi-Agent DPI) a L3 o sopra, di default in architettura single-thread e con opt-in esplicito dell'utente richiesto per topologie multi-agent. Questo sposta la decisione di affidabilità silenziosa del framework in una decisione esplicita.

Il Finding 3 (Cluster A e Cluster D anti-correlano) è operativamente scomodo: un team che eccelle in Cognition è strutturalmente probabile sia debole in Operations, e viceversa. L'implicazione è che ottenere punteggi di cluster bilanciati richiede o (a) un team abbastanza grande da staffare entrambi i cluster in modo indipendente, oppure (b) meccanismi organizzativi espliciti per contrastare la pulsione naturale. Proponiamo tre tali meccanismi basati sui nostri 18 mesi di esperienza operativa. MECCANISMO 1 · ROTAZIONE DELL'OWNERSHIP DI CLUSTER.

Gli ingegneri ruotano l'ownership di cluster trimestralmente; la rotazione li costringe a context-switch periodico tra Cognition e Operations, costruendo doppia fluency. Il costo è un calo di produttività di breve termine durante le transizioni; il beneficio è l'eliminazione di lungo termine dell'anti-correlazione. MECCANISMO 2 · REVIEW CROSS-CLUSTER.

Ogni decisione del cluster Cognition (architettura, strategia di retrieval, design di memory) riceve review dall'owner del cluster Operations prima del deployment, e viceversa. Il mandato del reviewer è segnalare dove la modifica proposta degradi l'altro cluster. MECCANISMO 3 · METRICHE A COPPIE DI CLUSTER.

La dashboard espone non solo punteggi per cluster ma metriche di correlazione tra coppie di cluster; un team il cui Cluster A è in miglioramento mentre il Cluster D è in degrado vede un warning esplicito. Abbiamo implementato tutti e tre i meccanismi in Madani; la Pearson rho a coppie di cluster è passata da -0,51 al mese 0 a -0,18 al mese 12, una riduzione misurabile dell'anti-correlazione anche se non un'eliminazione completa.

Siamo espliciti sullo scope. La derivazione a 12 pillar è ancorata a deployment agentic di knowledge work (lead generation, customer service, content production, financial analysis, code generation). Il framework può non trasferirsi pulitamente a: (a) ROBOTICA AUTONOMA — gli agent fisici hanno dimensioni di latenza sensore-attuatore che gli agent di knowledge work non hanno; la partizione richiede probabilmente pillar aggiuntivi. (b) SIMULAZIONE SCIENTIFICA — i sistemi agentic che eseguono calcolo scientifico hanno dimensioni di verifica della correttezza che dominano le altre preoccupazioni; la struttura di cluster probabilmente si ri-partiziona. (c) AGENT DI GAME-PLAYING IN REAL-TIME — dimensioni di ragionamento strategico specifiche della teoria dei giochi richiedono probabilmente pillar dedicati. Ipotizziamo che i 12 pillar core (o varianti vicine) generalizzino sulla maggior parte dei deployment agentic di knowledge work ma esplicitamente non rivendichiamo applicabilità universale.

L'analogo storico più vicino a WAB-9 è il Capability Maturity Model Integration (CMMI) sviluppato al Carnegie Mellon SEI per la maturità di processo software. CMMI organizza la capacità di software engineering in process area (circa 22 in CMMI-DEV v1.3) raggruppate in 4 categorie (Project Management, Process Management, Engineering, Support). L'analogia strutturale con i 12 pillar / 4 cluster di WAB-9 è marcata.

Le differenze chiave: (a) le process area di CMMI sono state specificate a priori dalla teoria del software engineering; i pillar di WAB-9 sono stati derivati empiricamente da dati di fallimento — la metodologia è diversa. (b) CMMI usa una scala di maturità a 5 livelli (Initial, Managed, Defined, Quantitatively Managed, Optimizing); anche WAB-9 usa 5 livelli (L0-L4) ma l'operazionalizzazione differisce (WSB-02). (c) CMMI assume un panorama di software engineering relativamente stabile; i sistemi agentic evolvono abbastanza velocemente da spostare le stesse definizioni di capability sottostanti, richiedendo aggiornamenti del framework più frequenti di quanto CMMI abbia sperimentato. Trattiamo CMMI come ispirazione per l'approccio a scala di maturità ma esplicitamente non trattiamo WAB-9 come "CMMI per l'AI" — le metodologie divergono in modi che contano per come il framework debba essere applicato.

(a) La derivazione a 12 pillar è ancorata al dataset di fallimenti Madani; un workspace operativo in un dominio sostanzialmente diverso (ad esempio robotica autonoma, simulazione scientifica) potrebbe richiedere pillar aggiuntivi o confini di cluster diversi. Ipotizziamo che i 12 core siano stabili sulla maggior parte dei deployment agentic di knowledge work ma non possiamo dimostrarlo senza replica più ampia. (b) La validazione di factor analysis è sensibile alla scelta della metrica di distanza e dell'algoritmo di clustering; abbiamo riportato risultati da K-means con distanza coseno, che ha prodotto la soluzione a 4 cluster più pulita, ma Ward linkage ha prodotto una partizione marginalmente diversa (sempre 4 cluster, ma con Reliability che si sposta da Trust a Operations). La struttura a 4 cluster è robusta; l'assegnazione esatta pillar-cluster in 1-2 edge case ha configurazioni alternative valide. (c) Il risultato R^2 = 0,81 viene dal dataset di un singolo workspace; la generalizzabilità cross-workspace è la priorità v0.4. (d) I pesi a valore di Shapley sono stabili alla nostra numerosità campionaria ma possono spostarsi modestamente con dataset più grandi; rilasceremo pesi aggiornati quando si completerà lo studio di replica multi-workspace. (e) Il finding di anti-correlazione (rho = -0,47) è basato su 7 workspace; il campione è troppo piccolo per essere definitivamente statistico e l'effetto potrebbe attenuarsi con campioni più grandi. Lo trattiamo come finding direzionale che merita ulteriore indagine, non come legge confermata.

L'espansione v0.4 va a 14 pillar (aggiungendo Lifecycle e Composability) sulla base di failure mode emergenti da 6 mesi aggiuntivi di strumentazione. Pianifichiamo anche di spedire un modello di scoring composito a pesi appresi che sostituisce l'attuale media uniforme per cluster con pesi adattati per regressione contro outcome di task. Uno studio di replica multi-workspace (target: 25 workspace entro Q4 2026) validerà la stabilità cross-domain della struttura a 12 pillar.

Tre ulteriori direzioni: (1) VALIDAZIONE CROSS-LINGUA — l'analisi attuale è solo in inglese su task scorati contro dati di produzione italiani/francesi/inglesi; pianifichiamo un'estensione in mandarino e arabo. (2) SCOPERTA AUTOMATIZZATA DI PARTIZIONE — dato il dataset di fallimenti di un nuovo workspace, possiamo scoprire automaticamente se la struttura a 12 pillar si applichi o se sia giustificata una partizione diversa? Questa è un'estensione meta-metodo. (3) MODELLAZIONE DELL'INTERAZIONE TRA PILLAR — oltre alla correlazione a livello di cluster, esistono interazioni specifiche tra coppie di pillar (ad esempio L3 Memory + L2 Context produce failure mode specifiche che L2 Memory + L3 Context non produce)? Modellare esplicitamente queste interazioni estenderebbe il framework da additivo a interattivo.

Forniamo casi di studio condensati dei 7 workspace dell'audit per dare consistenza ai punteggi di cluster aggregati. (1) MADANI WORKSPACE — media L3,4, L4 su Context + Memory + Multi-Agent DPI + Reliability, L2 su Forward-Deploy e Auto-Improvement (il gap del cluster Operations riflette il Finding 3). (2) OPENAI AGENTS SDK PYTHON — media L2,1, L4 su Tools (la loro core competency), L1 su Memory e Forward-Deploy. (3) ANTHROPIC COOKBOOK — media L1,8, L3 su Skills e Context, L1 su Governance e Auto-Improvement. (4) ANTHROPIC CLAUDE AGENT SDK — media L1,5, L3 su Tools, L1 su Memory e Reliability. (5) LANGCHAIN — media L1,4, L3 su Tools (via LangChain Hub), L1 su Multi-Agent DPI (i default del framework violano il Pillar 04). (6) CREWAI — media L1,3, L2 su Skills e Tools, L1 su Multi-Agent DPI. (7) MICROSOFT AUTOGEN — media L1,2, L2 su Tools, L1 su Multi-Agent DPI (peggior punteggio sul Pillar 04 dell'audit, che riflette la loro architettura MA-default). Il pattern sui 7 workspace è coerente: ogni framework ha un picco di 1-3 pillar che riflette le sue priorità di design e 6-9 pillar a L1 che riflettono le dimensioni per cui il framework non è stato costruito. Nessun framework domina; la media più alta del Madani Workspace riflette il suo approccio di tooling in-house anziché una superiorità di un singolo framework.

All'interno dell'audit Madani Workspace abbiamo ulteriormente decomposto il profilo per pillar per dominio su 8 sotto-domini: lead-generation, setting, sales, delivery, organization, finance, content, voice-channel. Il profilo è materialmente diverso per dominio. LEAD-GENERATION è massimo su Skills (L4, dato l'esteso toolkit di cold outreach) e minimo su Memory (L2, dato l'alto volume di interazioni prospect di vita breve).

SETTING è massimo su Multi-Agent DPI (L4, dato il rigoroso enforcement single-thread) e minimo su Auto-Improvement (L2, dati i cicli di feedback brevi). SALES è massimo su Reliability (L4, dato l'enforcement della tassonomia MAST) e minimo su Forward-Deploy (L2, data la natura bespoke per deal). DELIVERY è massimo su Governance (L4, data la disciplina contract-driven) e minimo su Skills (L3, dato il tooling project-specifico).

FINANCE è massimo su Credentials (L4, data la stringente sicurezza bank-API) e minimo su Context (L2, dati i context window transazionali tipicamente brevi). CONTENT è massimo su Context (L4, dato il profondo context engineering di brand/voice) e minimo su Observability (L2, data la difficoltà di misurare output creativo). VOICE-CHANNEL è massimo su Reliability (L4, dato lo stringente enforcement di SLA sub-secondo) e minimo su Memory (L2, date le interazioni tipicamente single-call).

Il pattern è coerente con il Finding 5 (nessun dominio punteggia L4 su tutti e 12 i pillar) e con il Finding 3 (i domini forti sul cluster Cognition tendono a essere più deboli sui pillar del cluster Operations).

I team che leggono questo paper per la prima volta affrontano una domanda pratica: da dove iniziare? Forniamo un playbook a 5 step basato sull'esperienza di audit dei 7 workspace. STEP 1 · SELF-SCORE CONTRO WAB-9.

Usa la matrice di accettazione a 60 celle (WSB-02) per fare self-score del workspace su tutti e 12 i pillar a tutti e 5 i livelli di maturità. Sii conservativo: nel dubbio tra L1 e L2, assegna L1. Il self-score richiede 2-4 ore per un team familiare con il proprio workspace; richiede più tempo per i team che non hanno pensato in precedenza al proprio workspace a questa granularità.

STEP 2 · IDENTIFICA IL CLUSTER PIÙ DEBOLE. Somma i punteggi per pillar dentro ciascun cluster. Identifica il cluster con la media più bassa. È il cluster la cui remediation produce il lift immediato più ampio.

STEP 3 · DENTRO IL CLUSTER PIÙ DEBOLE, IDENTIFICA IL PILLAR CON IL PESO DI SHAPLEY PIÙ ALTO. Usa la Tabella 2 (pesi di Shapley, questo paper) per prioritizzare dentro il cluster. Dentro il Cluster A, Context è il pillar con il più alto Shapley; dentro il Cluster C, lo è Reliability.

STEP 4 · REDIGI UNA CHECKLIST SPECIFICA DI ARTIFACT L1-A-L2. Fai riferimento alla matrice di accettazione WSB-02 per gli artifact specifici richiesti a L2 per il pillar target. Redigi un piano di progetto per spedire quegli artifact. STEP 5 · MISURA E ITERA.

Dopo la transizione L1-a-L2, rifai il self-score contro WAB-9 e confronta. Il lift atteso è da +0,3 a +0,5 sulla media di cluster; se il lift è inferiore, gli artifact L2 sono probabilmente di superficie e richiedono engineering più profondo. Abbiamo osservato team completare questo loop in 4-6 settimane per il primo cluster; i cluster successivi richiedono più tempo perché le easy win sono concentrate nel primo cluster affrontato.

ANTI-PATTERN 1 · ENUMERAZIONE SENZA INTERVENTO. I team completano il self-score, lo archiviano in un documento e non agiscono mai. Il punteggio ha valore solo se cambia comportamento.

ANTI-PATTERN 2 · INSEGUIRE IL BADGE L4. I team tentano di raggiungere L4 su ogni pillar simultaneamente ed esauriscono la capacità ingegneristica. Per il Finding 5, L4-su-tutti è strutturalmente aspirazionale; i team che lo inseguono pagano la tassa di anti-correlazione (Finding 3) e perdono attenzione su Operations.

ANTI-PATTERN 3 · IGNORARE I PESI DI SHAPLEY. I team rimediano il pillar "più facile" anziché il pillar con il peso di Shapley più alto. Questo produce miglioramenti visibili che non muovono il punteggio composito.

ANTI-PATTERN 4 · SOVRAPPESARE I TOOLS. Per il Finding 2, gli ingegneri sovrappesano sistematicamente Tools/Skills rispetto all'importanza pesata da Shapley. I team che seguono l'intuizione anziché i dati investono in modo sproporzionato in integrazioni di tool e sotto-investono in Memory e Multi-Agent DPI.

ANTI-PATTERN 5 · ACCETTARE I DEFAULT DEI FRAMEWORK. Per il Finding 7, i default dei framework violano silenziosamente il Pillar 04. I team che non sovrascrivono esplicitamente i default ereditano un soffitto del Pillar 04 inferiore a L3.

[1] Anthropic (2024-2025), Building Agents Cookbook (https://github.com/anthropics/anthropic-cookbook). [2] OpenAI (2025), Agents SDK Documentation (https://platform.openai.com/docs/assistants). [3] LangChain (2024), Framework Architecture Guide (https://python.langchain.com/docs/get_started/introduction). [4] 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. [5] Wang C. & Shu Y. (2026), MetaCogAgent, arXiv:2605.17292v1. [6] 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. [7] Shapley L.S. (1953), A Value for n-Person Games, in Kuhn H.W. & Tucker A.W. (eds.), Contributions to the Theory of Games, vol. II, Princeton University Press. [8] Lundberg S.M. & Lee S.-I. (2017), A Unified Approach to Interpreting Model Predictions, NeurIPS 30. [9] Ward J.H. (1963), Hierarchical Grouping to Optimize an Objective Function, Journal of the American Statistical Association 58(301):236-244. [10] Cattell R.B. (1966), The Scree Test for the Number of Factors, Multivariate Behavioral Research 1:245-276. [11] Horn J.L. (1965), A Rationale and Test for the Number of Factors in Factor Analysis, Psychometrika 30:179-185. [12] Humphrey W.S. (1989), Managing the Software Process, Addison-Wesley. [13] CMMI Product Team (2010), CMMI for Development, Version 1.3, Carnegie Mellon SEI. [14] Deming W.E. (1986), Out of the Crisis, MIT Press. [15] Cognition Labs (2025), Don't Build Multi-Agents (cognition.ai blog, steel-man). [16] Wu Q. et al. (2024), AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, ICML. [17] Moura J. (2024), CrewAI: Framework for Orchestrating Role-Playing Autonomous AI Agents. [18] Hong S. et al. (2024), MetaGPT: Meta Programming for Multi-Agent Collaborative Framework, ICLR. [19] LangChain (2024), LangGraph: Build Stateful, Multi-Actor Applications with LLMs. [20] Shinn N. et al. (2023), Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS. [21] Park J.S. et al. (2023), Generative Agents: Interactive Simulacra of Human Behavior, UIST. [22] Cohen J. (1960), A Coefficient of Agreement for Nominal Scales, Educational and Psychological Measurement 20:37-46. [23] Anthropic (2025), Claude Agent SDK Documentation. [24] Madani Lab (2026), WAB-9 Specification v0.3.4 (MIT-licensed, 12-pillar / 4-cluster reference). [25] Madani Lab (2026), WAB-9 142-Task Validation Dataset (anonymized, MIT release pending).