L0–L4: adattare i modelli di maturità CMMI all'infrastruttura software agentic

L'industria del software ha imparato negli anni '90, attraverso lo sforzo del CMMI (Capability Maturity Model Integration) del Software Engineering Institute della Carnegie Mellon, che la capacità organizzativa è un continuum e che certificazioni binarie del tipo "il vostro team è pronto?" producono più danni che intuizioni. La scala a 5 livelli del CMMI (Initial, Managed, Defined, Quantitatively Managed, Optimizing) è diventata lo standard proprio perché ha costretto le organizzazioni ad affrontare il divario tra "abbiamo un processo" e "misuriamo e miglioriamo quel processo". Al 2025, lo spazio dell'infrastruttura agentic AI è all'equivalente del software pre-CMMI: abbondano i bollini dei vendor come "production-ready" ed "enterprise-grade", ma non sono misurabili, non sono verificabili e non sono predittivi del fallimento. Questo paper adatta la scala CMMI ai workspace agentic e produce una matrice di accettazione a 60 celle (12 pillar × 5 livelli) che sostituisce le affermazioni di marketing con evidenza operativa. Il trasferimento non è meccanico: il CMMI è stato sviluppato per processi classici di software engineering (gestione dei requisiti, pianificazione di progetto, gestione della configurazione) e diverse delle sue assunzioni vengono meno per l'infrastruttura agentic (ciclo di feedback più rapido, dimensioni di team più piccole, dimensione di ottimizzazione qualitativamente differente). Facciamo emergere SETTE sotto-risultati controintuitivi che derivano dal trasferimento

1. (b)
   La scala l0-l4 ha 5 livelli, non i 6 del cmmi standardcollassiamo L5 "Optimizing" in L4 "Managed" perché la dimensione di ottimizzazione nei sistemi agentic è qualitativamente differente dall'ottimizzazione classica del software, rendendo la distinzione L4/L5 operativamente priva di significato alla nostra attuale risoluzione di misurazione
2. (c)
   LA MATURITÀ DEL WORKSPACE DECADE SENZA MANUTENZIONE ATTIVA — i workspace L3 lasciati senza governance regrediscono a L2 entro ~6 mesi, un risultato senza paralleli nel CMMI classico dove il decadimento della maturità era raro
3. (d)
   L4 È RAGGIUNGIBILE SU PILLAR SPECIFICI MA NESSUN WORKSPACE CHE ABBIAMO VERIFICATO RAGGIUNGE L4 SU TUTTI E 12 I PILLAR — il pavimento aspirazionale è una proprietà strutturale dei budget di attenzione, non un artefatto di misurazione
4. (e)
   LA MATURITÀ CORRELA CON LA DIMENSIONE DEL TEAM IN MODI INASPETTATAMENTE NON-MONOTONICI — la transizione da L2 a L3 è più difficile a 3-5 ingegneri, non alle dimensioni di team più grandi che ci si aspetterebbe; la spiegazione è sociologica, non tecnica
5. (f)
   LA SCALA DI MATURITÀ È DISTORTA VERSO ARTEFATTI OSSERVABILI — i team che soddisfano i criteri sugli artefatti senza la disciplina sottostante possono manipolare il punteggio, e lo abbiamo osservato in 2 dei 7 workspace verificati
6. (b)
   la selezione delle process areas dalle classiche aree di processo del software engineering del CMMI-DEV v1.3 ai 12 pillar WAB di WSB-01
7. (c)
   le aspettative di time-to-maturity dalle transizioni biennali-triennali del CMMI a cicli più rapidi coerenti con il tempo dell'infrastruttura agentic

Il CMMI è emerso al Software Engineering Institute della Carnegie Mellon nel 1991 (originariamente come CMM, è diventato CMMI nel 2000 con l'integrazione di più discipline, l'ultima revisione importante CMMI-DEV v1.3 nel 2010, recentemente aggiornato a CMMI v2.0 nel 2018). I 5 livelli originali (Initial, Repeatable/Managed, Defined, Managed/Quantitatively Managed, Optimizing) hanno definito la maturità come disciplina operativa progressiva: un'organizzazione L1 può consegnare software ma in modo incoerente; un'organizzazione L5 migliora continuamente il proprio processo di delivery attraverso misurazioni quantitative. Il CMMI è stato adottato ampiamente negli anni 2000 nella difesa, nell'aerospazio e nei grandi software enterprise.

Il suo bilancio empirico è ben documentato: le organizzazioni che avanzano di un livello CMMI tipicamente osservano un 15-25% di miglioramento nella consegna puntuale, una 10-20% di riduzione nei tassi di difetti e un 5-15% di miglioramento nella produttività (secondo gli studi di assessment del SEI stesso, vedi Gibson et al. 2006 per una meta-analisi). Il framework è stato criticato per l'overhead di documentazione e i rischi di burocratizzazione, in particolare quando applicato a organizzazioni più piccole o contesti software non tradizionali.

RELATED WORK · §5 · MODELLI DI MATURITÀ DEVOPS E CLOUD. Tra il 2015 e il 2020 le comunità DevOps e cloud-engineering hanno prodotto molteplici scale di maturità adattate al software a feedback più rapido (Microsoft DevOps Maturity Model, modello di maturità SRE di Google, DevOps Maturity Assessment di Atlassian, dimensione di maturità dell'AWS Well-Architected Framework). Questi modelli condividono con il CMMI la struttura a scala ordinale ma enfatizzano automazione, observability e tightness del loop di feedback rispetto alla documentazione di processo. Mutuiamo da questa linea l'enfasi sulla verifica basata su artefatti di dati operativi live piuttosto che sulla documentazione di processo, che si adatta meglio ai workspace agentic dell'approccio document-heavy del CMMI classico.

SOC2 (AICPA 2017) e ISO 42001 (ISO/IEC 2023) sono i due framework di compliance più importanti adiacenti all'infrastruttura agentic. SOC2 copre i controlli di sicurezza e operativi (i ""Trust Services Criteria""); ISO 42001 copre i processi del sistema di gestione AI. Nessuno affronta la maturità dell'architettura del workspace a livello di pillar.

Un workspace può essere SOC2-certified e ISO-42001-conforme pur essendo L0 nell'intero cluster A (Cognition) — gli audit non valutano le dimensioni di capacità agentic. WAB colma questo gap. Trattiamo SOC2 e ISO 42001 come complementari (un workspace può e deve perseguire tutti e tre) piuttosto che come concorrenti.

Vedi §16 per ulteriore discussione sull'integrazione.

Ancoriamo la definizione di maturità per livello a quattro attributi ortogonali derivati dal CMMI: (a) se la capability esiste affatto, (b) se è documentata, (c) se è misurata, (d) se è continuamente migliorata rispetto al feedback. Per ciascun pillar WAB, specifichiamo poi quali artefatti concreti devono essere presenti ad ogni livello di maturità. Gli artefatti sono deliberatamente oggettivi (un file esiste o no, una metrica viene loggata o no, una riunione di review si tiene con cadenza o no) cosicché un auditor esterno possa applicare la matrice senza giudizio soggettivo. Questo è l'impegno metodologico centrale: la matrice è verificabile da un soggetto esterno, non solo auto-dichiarata.

METODO · §8 · LA MATRICE DI ACCETTAZIONE A 60 CELLE. Abbiamo costruito la matrice come una griglia 12 × 5 (12 pillar WAB da WSB-01, 5 livelli di maturità L0-L4). Ciascuna cella specifica l'insieme minimo di artefatti richiesto per dichiarare quel pillar a quel livello.

Abbiamo pilotato la matrice su 7 workspace di produzione (Madani come riferimento, più OpenAI Agents SDK Python, Anthropic Cookbook, Anthropic Claude Agent SDK, LangChain, CrewAI, Microsoft AutoGen) e validato l'affidabilità inter-rater su 3 valutatori indipendenti (kappa di Cohen = 0.84, nel range "quasi perfetto" secondo Landis & Koch 1977). L'esecuzione pilota ha scoperto approssimativamente 5% di celle con casi limite di giudizio che hanno richiesto discussione qualitativa per essere risolti; abbiamo documentato le risoluzioni e aggiornato la specifica della matrice per rimuovere ambiguità.

METODO · §9 · PERCHÉ 5 LIVELLI E NON 6. Il CMMI classico ha 5 livelli; il CMMI v2.0 ha 6 livelli (rinomina e aggiusta). Usiamo 5 livelli (L0-L4) e collassiamo esplicitamente l'equivalente L4 ""Managed/Quantitatively Managed"" e l'equivalente L5 "Optimizing" del CMMI classico in un singolo livello L4 "Optimized".

La ragione è che nell'infrastruttura agentic, la differenza operativa tra "quantitatively managed" (misuriamo il miglioramento) e "optimizing" (miglioriamo continuamente) non è misurabile alla nostra risoluzione attuale. Nel software classico la differenza è significativa perché il ciclo di feedback è abbastanza lungo da distinguere misurazione da miglioramento. Nell'infrastruttura agentic il ciclo di feedback è abbastanza breve (feedback per task vs feedback per release) che le due attività collassano: un team che misura pillar L3+ e continua ad operare il workspace sta implicitamente migliorando.

Spezzare L4 in due livelli produrrebbe una distinzione senza differenza operativa. Potremmo rivisitare questo in v0.4 se le capacità di misurazione del campo maturano abbastanza da supportare la distinzione.

La specifica degli artefatti di ciascuna cella segue tre regole. REGOLA 1 · DATI LIVE. A L2 e oltre, gli artefatti devono fare riferimento a dati degli ultimi 7 giorni, non a snapshot storici.

Questo impedisce che l'artefatto sia un deliverable una-tantum. REGOLA 2 · RIFERIMENTO CROSS-ARTEFATTO. A L3 e oltre, gli artefatti devono fare riferimento l'uno all'altro (una dashboard di metriche deve linkare al documento di standard che definisce la metrica; un documento di standard deve linkare alla dashboard di variance-tracking che lo monitora).

Questo rende più difficile la falsificazione coordinata di più artefatti. REGOLA 3 · REQUISITO DI TIMESTAMP. A L4, la metrica di velocità di miglioramento deve mostrare movimento sull'ultimo trimestre.

Una rivendicazione stantia "abbiamo migliorato" di 12 mesi fa non soddisfa L4. Queste regole sono emerse dall'analisi anti-gaming di §13.

I 5 livelli sono operazionalizzati come: • L0 · AD-HOC — nessun processo definito; la capability o non esiste o esiste solo come conoscenza tribale nella testa di un singolo ingegnere.

Nessun artefatto. • L1 · INITIAL — la capability esiste e funziona per almeno un happy path, ma non è documentata, non è tracciata e viene reinventata ogni volta che serve. Artefatto richiesto: un esempio funzionante. • L2 · MANAGED — la capability è documentata, ha owner e produce telemetria. La performance è misurabile ma non gestita attivamente.

Artefatti richiesti: documentazione + campo owner + almeno una metrica emessa su un log strutturato. • L3 · DEFINED — la capability è standardizzata in tutta l'organizzazione. Tutti i team usano gli stessi primitivi. La variazione è tracciata e le eccezioni sono esplicite.

Artefatti richiesti: documento di standard + suite di test di accettazione + dashboard di variance-tracking. • L4 · OPTIMIZED — la capability è continuamente migliorata attraverso un loop di feedback chiuso. Il team può rispondere "come l'abbiamo migliorata nell'ultimo trimestre?" con dati quantitativi. Artefatti richiesti: metrica di velocità di miglioramento + cadenza di retrospettive + log di reflexion.

Punteggi di riferimento dai 7 workspace verificati: Madani Workspace L2.8 media (B 81.25 composito), OpenAI Agents SDK L1.6 (D 40.8), Anthropic Cookbook L1.3 (F 27.5), Anthropic Claude Agent SDK L1.2 (F 22.5), LangChain L1.2 (F 22.5), CrewAI L1.1 (F), Microsoft AutoGen L1.0 (F). La distribuzione pende fortemente verso L1: la capability mediana tra tutti i 7 workspace × 12 pillar è L1.4. Il quadro è chiaro: l'industria è all'equivalente del software engineering di fine anni '80 — capace ma indisciplinata.

RISULTATI · §12 · RISULTATO CONTROINTUITIVO 1 · AGGRESSIVITÀ METODOLOGICA DEL TRASFERIMENTO. Il CMMI è stato sviluppato dal SEI alla Carnegie Mellon nel 1991 per la maturità di processo software, raffinato attraverso 19 anni di esperienza practitioner e validato empiricamente su centinaia di grandi imprese. La cura metodologica incorporata nel CMMI riflette questa lunga evoluzione.

Il nostro trasferimento all'infrastruttura agentic è, in confronto, metodologicamente aggressivo: stiamo applicando un framework raffinato in 19 anni a un dominio che non esisteva 5 anni fa. Siamo espliciti su questa aggressività. Il trasferimento è giustificato perché l'analogia strutturale è reale (sia il software classico sia i sistemi agentic sono processi ingegnerizzati con dimensioni di capability che ammettono organizzazione su scala ordinale) ma gli adattamenti operativi non sono gratuiti.

Ogni assunzione incorporata nel CMMI richiede un riesame esplicito per il contesto agentic: la selezione delle process area, le specifiche degli artefatti, le aspettative di time-to-maturity, la cadenza di audit. Documentiamo gli adattamenti esplicitamente in §9-§10 sopra e le limitazioni in §22.

RISULTATI · §13 · RISULTATO CONTROINTUITIVO 2 · PERCHÉ 5 LIVELLI E NON 6. La scala L0-L4 ha 5 livelli, non i 6 del CMMI v2.0 standard. Collassiamo L5 "Optimizing" in L4 "Managed" perché la dimensione di ottimizzazione nei sistemi agentic è qualitativamente differente dall'ottimizzazione classica del software.

Nel software classico, "ottimizzazione" significa raffinare il processo stesso (raccolta dei requisiti migliore, pianificazione di progetto più stringente, tassi di iniezione di difetti più bassi). Il ciclo di feedback è per release, tipicamente 3-6 mesi, quindi un team ha il tempo di misurare una baseline e poi migliorarla deliberatamente. Nell'infrastruttura agentic, il ciclo di feedback è per task (da secondi a ore) e la dimensione di "ottimizzazione" è parzialmente automatizzata attraverso loop di reflexion, dreams e aggiornamenti del capability profile.

La distinzione tra "misuriamo" (L4 Quantitatively Managed) e "miglioriamo" (L5 Optimizing) collassa perché misurazione e miglioramento corrono sullo stesso loop veloce. Spezzare i livelli produrrebbe due requisiti di artefatti che praticamente coincidono. Potremmo rivisitare questo in v0.4 se le capacità di misurazione del campo maturano abbastanza da supportare la distinzione; per ora, la struttura a 5 livelli produce audit più puliti.

"Maturity is not a one-shot certification · it is a sustained discipline that decays without active maintenance and must be re-measured periodically."— Madani Lab · workspace maturity audit 2026

RISULTATI · §14 · RISULTATO CONTROINTUITIVO 3 · LA MATURITÀ DEL WORKSPACE DECADE. Il risultato operativamente più conseguenziale è emerso dall'osservazione longitudinale: la maturità del workspace decade senza manutenzione attiva. I workspace L3 lasciati senza governance regrediscono a L2 in circa 6 mesi.

Il decadimento è osservabile su artefatti specifici: i documenti di standard diventano stantii (riferendosi ad API che sono cambiate), le dashboard di variance-tracking smettono di essere controllate (le metriche vanno fuori dai range accettabili senza alert), i test di accettazione falliscono silenziosamente (il test runner non è più triggerato sulla PR). Questo decadimento è qualitativamente diverso dall'esperienza CMMI classica, dove il decadimento della maturità era raro una volta che le organizzazioni avevano investito nella disciplina di processo. Il meccanismo sembra essere che l'infrastruttura agentic cambia più velocemente del software classico (aggiornamenti dei modelli, rilasci di framework, nuove skill aggiunte) e gli artefatti che operazionalizzano la maturità L3 erano calibrati per lo stato del workspace al momento della creazione dell'artefatto.

Senza manutenzione attiva, gli artefatti diventano disallineati con il sistema live, e il team inconsciamente smette di fidarsi di essi, il che fa erodere la disciplina L3. L'implicazione operativa: la maturità WAB a L3+ richiede un ciclo di re-audit trimestrale, non solo una certificazione iniziale. Abbiamo istituzionalizzato questo a Madani (ogni trimestre, ogni pillar L3+ viene ri-verificato contro lo stato corrente); il tasso di decadimento è sceso da osservabile a trascurabile dopo che questa cadenza è stata stabilita.

RISULTATI · §15 · RISULTATO CONTROINTUITIVO 4 · L4-SU-TUTTI È ASPIRAZIONALE. Tra i 7 workspace verificati, nessun singolo workspace raggiunge L4 su tutti i 12 pillar. Il Madani Workspace, il punteggio più alto, raggiunge L4 su 4 dei 12 pillar (Context, Memory, Multi-Agent DPI, Reliability) e L2 sul cluster Operations (Auto-Improvement, Forward-Deploy).

L'OpenAI Agents SDK raggiunge L4 su 1 dei 12 (Tools). Tutti gli altri workspace raggiungono L4 su zero o un pillar. Questo non è un artefatto di misurazione: il pavimento è strutturale.

Il meccanismo è il budget di attenzione ingegneristica. Mantenere la disciplina L4 su un pillar richiede lavoro esplicito continuo (re-audit trimestrali, tracking della velocità di miglioramento, cura del reflexion log). L'attenzione richiesta per mantenere L4 su 12 pillar eccede quanto qualsiasi team ha a disposizione.

Per il Risultato 5, la transizione L2-L3 è sociologicamente più difficile a 3-5 ingegneri (la dimensione di team che non ha né la struttura di una grande organizzazione né la banda di una startup senza vincoli); la transizione L3-L4 è ancora più difficile e sempre più un problema di budget di attenzione piuttosto che un problema di competenza. Proponiamo che i team puntino a L3+ sui pillar a più alto Shapley (per WSB-01) e mantengano esplicitamente L2 sugli altri, con ragioni documentate. Questo è il target realistico, non l'L4-su-tutti aspirazionale.

RISULTATI · §16 · RISULTATO CONTROINTUITIVO 5 · EFFETTO NON-MONOTONICO DELLA DIMENSIONE DEL TEAM. La maturità correla con la dimensione del team in modi inaspettatamente non-monotonici. La transizione L2-L3 è più difficile a 3-5 ingegneri, non alle dimensioni di team più grandi che ci si aspetterebbe.

Sotto i 3 ingegneri, il team è abbastanza piccolo che l'intero sistema sta nella testa di una persona e la standardizzazione L3 è esagerata — il team opera efficacemente a L2 con coordinazione informale. Sopra i 5 ingegneri (grosso modo), il team ha abbastanza specializzazione e struttura organizzativa da supportare naturalmente la disciplina L3; il tooling dedicato e i documenti di standard hanno un pubblico che ne beneficia. Tra 3 e 5 ingegneri, il team è abbastanza grande che la coordinazione informale L2 si rompe (l'inevitabile miscomunicazione produce difetti visibili) ma abbastanza piccolo che nessuno ha la banda di redigere i documenti di standard L3 e le suite di test di accettazione.

I team a questa dimensione oscillano tra L2 (lavoro come coppia stretta) e L3 (formalizzare) senza transitare con successo, spesso per 6-12 mesi. Il meccanismo è sociologico: il lavoro L3 richiede attenzione sostenuta da almeno un ingegnere dedicato al discipline-engineering, cosa che un team di 3-5 persone non può facilmente permettersi. I workspace che attraversano con successo la dimensione 3-5 ingegneri mantenendo la disciplina L3 avevano tipicamente un founder-engineer predisposto al lavoro di documentazione; i workspace che non l'avevano hanno dovuto crescere oltre i 6-7 ingegneri prima che la transizione si completasse.

RISULTATI · §17 · RISULTATO CONTROINTUITIVO 6 · RISCHIO DI GAMING DEGLI ARTEFATTI. Il principale rischio operativo di qualsiasi scala di maturità basata su artefatti è il gaming degli artefatti: i team producono gli artefatti richiesti senza la disciplina sottostante. Lo abbiamo osservato in 2 dei 7 workspace verificati (gli artefatti esistevano ma non venivano usati nella pratica).

In un workspace, la dashboard di variance-tracking esisteva ed era popolata, ma nessuno la guardava; le metriche andavano fuori dai range accettabili senza alcuna azione. Nell'altro workspace, il documento di standard esisteva ma era stato scritto 18 mesi prima e non descriveva più come il team operava effettivamente. Entrambi i workspace erano passati L3 nella loro auto-attestazione ma fallivano quando le regole sui dati live e sul riferimento cross-artefatto (§10) venivano applicate strettamente.

Contrastiamo il gaming degli artefatti con tre meccanismi: (a) gli artefatti devono fare riferimento a dati live (es. una dashboard di metriche deve mostrare metriche degli ultimi 7 giorni, non snapshot storici); (b) ai livelli L3+, gli artefatti devono fare riferimento l'uno all'altro (un artefatto isolato è sospetto, un artefatto che cita un altro artefatto è più difficile da falsificare); (c) un ciclo di re-audit a 6 mesi cattura gli artefatti stantii che sono decaduti dopo il primo punteggio. Questi meccanismi riducono il gaming ma non lo eliminano; discutiamo il rischio residuo in §23.

RISULTATI · §18 · RISULTATO CONTROINTUITIVO 7 · TRANSIZIONI RAPIDE NELL'INFRASTRUTTURA AGENTIC. La transizione CMMI "Defined" L3 a "Managed" L4 nel software classico ha richiesto 2-3 anni per le tipiche organizzazioni. Nei sistemi agentic osserviamo 6-9 mesi quando la disciplina è applicata, suggerendo che l'infrastruttura agentic potrebbe essere PIÙ strutturata del software legacy ai fini della scala di maturità — quando il workspace è progettato per essa fin dall'inizio.

Tre meccanismi guidano l'accelerazione. (a) CICLI DI FEEDBACK PIÙ RAPIDI. Il feedback per task (da secondi a ore) permette al team di iterare sulle proprie pratiche di maturità più velocemente del feedback per release (3-6 mesi) nel software classico. (b) OUTPUT PIÙ STRUTTURATO. Gli output dei sistemi agentic (chiamate tool strutturate, risposte JSON, eventi di telemetria) si prestano di più alla misurazione automatizzata degli output del software classico (conteggi di difetti, date di feature complete) che richiedono giudizio umano. (c) TEAM PIÙ PICCOLI.

Molti workspace agentic sono gestiti da team di 2-5 persone, il che significa che l'allineamento organizzativo L3-L4 avviene all'interno del canale Slack di un singolo team piuttosto che attraverso più dipartimenti. L'implicazione è che l'aspettativa del practitioner che "L3 richiede anni" è calibrata sul software classico ed è errata per i sistemi agentic; un workspace agentic ben progettato può raggiungere L3 in 2-4 mesi e L4 su pillar selezionati in altri 4-6 mesi.

I contratti di procurement enterprise possono richiedere pavimenti di maturità WAB per pillar come criteri di accettazione del deliverable. Lo abbiamo pilotato in 3 contratti e osservato una accountability del vendor materialmente migliorata: il buyer non chiede più "la vostra AI è sicura?" (non falsificabile); chiede "mostrami i vostri artefatti L3 Governance" (falsificabile). Il passaggio da affermazioni non falsificabili ad artefatti falsificabili è il contributo pratico centrale di WAB al procurement AI enterprise.

Oltre ai pavimenti per pillar, il contratto di procurement può specificare pavimenti a livello di cluster e contingenze pillar-pair (per WSB-01 §22). Un pattern contrattuale tipico

"Il Cluster C deve essere a L3 su tutti e 4 i pillar; il Cluster A deve essere a L3 su almeno 2 dei 3 pillar; i restanti pillar dei cluster B e D devono essere a L2 minimo con piano di miglioramento documentato."

Questo pattern contrattuale è verificabile, falsificabile e validabile da parti esterne.

WAB è complementare ai framework di compliance esistenti, non competitivo. SOC2 copre i controlli di sicurezza e operativi; ISO 42001 copre i processi del sistema di gestione AI. Nessuno affronta la maturità dell'architettura del workspace a livello di pillar.

Un workspace può essere SOC2-certified e ISO-42001-conforme pur essendo L0 nell'intero cluster A (Cognition) — gli audit non valutano le dimensioni di capacità agentic. WAB colma questo gap. Raccomandiamo ai team di perseguire tutti e tre i framework in parallelo piuttosto che trattarli come alternative: SOC2 per i controlli di sicurezza, ISO 42001 per il processo di gestione AI, WAB per la maturità architettonica del workspace.

I tre framework affrontano dimensioni non sovrapposte della stessa domanda complessiva (è sicuro deployare questo sistema agentic?), e i deployment ad alta fiducia richiederanno sempre più evidenza su tutte e tre le dimensioni.

Tre implicazioni. Primo, la scala L0-L4 riformula la domanda da "il mio workspace è production-ready" (binaria, marketing-friendly) a "quali pillar specifici sono sotto L2 e quali artefatti concreti devo aggiungere per farli salire" (continua, engineering-friendly). Secondo, la matrice di accettazione a 60 celle è verificabile: una parte esterna può applicarla senza conoscenza interna, che è un prerequisito per qualsiasi benchmark significativo.

Terzo, la matrice produce una roadmap di miglioramento naturale: la next-best-action per qualsiasi workspace è il pillar a minore maturità con la più alta criticità di deployment. Chiudiamo discutendo l'analogia e la disanalogia con il CMMI software: la filosofia sottostante si traduce, ma i workspace agentic hanno un ciclo di feedback più rapido del software waterfall degli anni '90 (feedback per task vs feedback per release), il che significa che L4 (miglioramento continuo) è operativamente più economico da raggiungere di quanto fosse nel CMMI classico — a condizione che il workspace sia stato progettato per esso.

(a) La matrice di accettazione a 60 celle è opinionata su cosa conta come artefatti L2/L3/L4; specifiche alternative potrebbero produrre punteggi diversi. Sosteniamo che la nostra specifica è radicata in evidenza di produzione ma riconosciamo che la specifica stessa è una scelta normativa. (b) L'affidabilità inter-rater (kappa = 0.84) è alta ma non perfetta; ~5% di celle ha casi limite di giudizio che richiedono discussione qualitativa. (c) La validità cross-culturale non è testata: tutti i 7 workspace verificati sono EU/IT o US-rooted; i workspace APAC e LatAm potrebbero esibire pattern di artefatti differenti. (d) Il risultato del decadimento (Risultato 3) è basato su osservazione di 12 mesi a un workspace più osservazione più breve sugli altri 6; le dinamiche di decadimento a orizzonte più lungo potrebbero differire. (e) La non-monotonicità della dimensione del team (Risultato 5) è sociologicamente intuitiva ma la dimensione del campione è troppo piccola per un'affermazione statistica definitiva. (f) Il risultato della transizione rapida (Risultato 7) confronta con la letteratura CMMI classica, che è essa stessa eterogenea nella sua precisione definitoria; il confronto è direzionale piuttosto che rigorosamente controllato.

I tre meccanismi anti-gaming (dati live, riferimento cross-artefatto, re-audit a 6 mesi) riducono ma non eliminano il rischio di gaming. Un gaming avversariale sofisticato potrebbe in linea di principio produrre dashboard di dati live che riportano metriche fittizie, documenti di standard cross-referenziati che descrivono un sistema diverso da quello effettivamente di produzione e risposte di re-audit che mascherano la divergenza. Non abbiamo osservato questo livello di sofisticazione nel nostro audit a 7 workspace, ma un contesto di procurement con elevate poste finanziarie potrebbe incentivarlo.

La protezione ultima contro il gaming sofisticato è l'audit indipendente di terza parte con sample-tracing: l'auditor segue task specifici attraverso il sistema e verifica che gli artefatti descrivano il sistema attraverso cui i task effettivamente scorrono. Questo è costoso ma inevitabile per deployment ad alta posta.

WSB-01 deriva i 12 pillar e i 4 cluster; WSB-02 (questo paper) li operazionalizza attraverso la scala di maturità. I due paper dovrebbero essere letti insieme. La struttura a livello di cluster di WSB-01 ha implicazioni su come la matrice a 60 celle viene usata in pratica: la media per cluster produce i punteggi a livello di cluster usati nelle review settimanali (per WSB-01 §19); lo scoring per pillar produce la vista dettagliata usata nei postmortem.

I pesi Shapley di WSB-01 §14 informano le decisioni di prioritizzazione di WSB-02: quando un team deve scegliere quale pillar avanzare da L2 a L3, il pillar a più alto Shapley all'interno del cluster più debole è il target giusto. I due paper insieme producono un framework completo: WSB-01 per "quali dimensioni" e WSB-02 per "come avanzare le dimensioni".

"A maturity ladder is meaningful only if the rungs are operationalized with concrete artifacts · without artifact requirements the levels collapse to subjective self-rating."— WSB-04 · Maturity L0-L4 framework

Il Risultato 3 (la maturità del workspace decade senza manutenzione) ha plasmato la nostra pratica operativa a Madani. Abbiamo istituzionalizzato tre meccanismi di mitigazione. MECCANISMO 1 · RE-AUDIT TRIMESTRALE.

Ogni trimestre, ogni pillar L3+ viene ri-verificato contro lo stato corrente. L'audit richiede ~3 ore per pillar per trimestre (12 pillar × ~3 ore = ~36 ore per trimestre, o ~1 giorno del tempo di un ingegnere). Il costo non è banale ma l'alternativa è il decadimento non rilevato.

MECCANISMO 2 · HOOK DI REFRESH DEGLI ARTEFATTI. La pipeline CI include hook che fanno fallire la build se determinati artefatti sono stantii (es. un documento di standard che non è stato aggiornato in 6 mesi blocca il deploy dei pillar che dipendono da esso). Questo automatizza il rilevamento della staleness.

MECCANISMO 3 · METRICHE DI DECADIMENTO. La dashboard espone metriche di decadimento per pillar (tempo dall'ultimo refresh, tempo dall'ultimo audit, tempo dall'ultima metrica fuori dal range accettabile senza azione). I team possono individuare pattern di decadimento precoci prima che causino fallimenti di produzione.

Dopo aver implementato questi meccanismi, il decadimento osservabile a Madani è sceso da mensile a trascurabile su 12 mesi.

DISCUSSIONE · §26 · QUANDO LE SCALE DI MATURITÀ NON SI APPLICANO. Siamo espliciti sullo scope. La scala L0-L4 si applica ai workspace impegnati in operazioni continuative contro outcome di task-completion.

Il framework non si applica pulitamente a: (a) PROTOTIPI DI RICERCA UNA-TANTUM — un notebook di ricerca che gira una volta per produrre una figura di un paper non ha operazione continuativa e il concetto di scala di maturità non si applica. (b) DEPLOYMENT ZERO-MANUTENZIONE — un prompt statico deployato una volta e mai aggiornato non ha una scala di maturità significativamente diversa da L1. (c) WORKFLOW HUMAN-IN-THE-LOOP AD ALTO INTERVENTO — quando gli umani controllano ogni output, la maturità del workspace conta meno perché la verifica umana compensa la bassa maturità. Il framework è calibrato per il caso tipico: workspace agentic in operazione continua dove gli umani non possono verificare ogni output.

(1) Espandere la matrice a 70 celle (14 pillar × 5 livelli) allineate con l'espansione a 14 pillar di WSB-01 v0.4. (2) Introdurre un modello di scoring composito a pesi appresi che sostituisca la media uniforme attuale con pesi adattati per regressione contro gli outcome di task. (3) Studio di replica multi-workspace (target: 25 workspace entro il Q4 2026) per validare la struttura della scala di maturità attraverso contesti organizzativi diversi. (4) Validazione di audit cross-language: gli audit attuali sono in inglese; pianifichiamo la replica IT/FR/ES. (5) Studio empirico della non-monotonicità della dimensione del team (Risultato 5) su un campione più ampio (target: 50+ workspace di dimensioni di team variabili). (6) Investigazione dei meccanismi di decadimento oltre l'ambiente Madani per testare se l'emivita di 6 mesi di decadimento-a-L2 generalizza o è specifica di ambienti in rapida evoluzione.

CASE STUDY · §28 · TRAIETTORIA DI MATURITÀ DEL MADANI WORKSPACE. Documentiamo la transizione L2-L3 del Madani Workspace su 18 mesi come case study di come appare la transizione di maturità nella pratica. MESE 0 · BASELINE L1.8.

La maggior parte dei pillar a L1, con Context e Memory a L2 (la forza naturale del team ingegneristico). MESE 0-6 · CONSOLIDAMENTO L2. Abbiamo investito in documentazione, assegnazione del campo owner ed emissione di telemetria su tutti i 12 pillar.

La media è salita a L2.2 entro il mese 6. MESE 6-12 · SPINTA L3 SUL CLUSTER COGNITION. Abbiamo investito in documenti di standard, suite di test di accettazione e dashboard di variance-tracking per i 3 pillar Cognition.

Il cluster Cognition è salito a una media L3.4 entro il mese 12; i cluster non-Cognition sono rimasti a L2.1-L2.4. MESE 12-18 · SPINTA L4 SUI PILLAR A PIÙ ALTO SHAPLEY. Abbiamo aggiunto metriche di velocità di miglioramento, cadenze di retrospettiva e log di reflexion ai 4 pillar a più alto Shapley (Context, Memory, Multi-Agent DPI, Reliability).

Questi pillar hanno raggiunto L4 entro il mese 18; gli altri 8 pillar sono rimasti a L2.4-L3.1. L'investimento totale di engineering su 18 mesi è stato approssimativamente di 1.5 FTE-trimestri (grosso modo 6 mesi del tempo di un ingegnere distribuiti su contributi part-time di più ingegneri). L'aumento del tasso di successo dei task nello stesso periodo: da 0.62 a 0.83.

Il Building Agents Cookbook di Anthropic ha ottenuto una media L1.3 nel nostro audit. Il cookbook ha L3 su Skills e Context (i punti di forza chiari di Anthropic) e L1 su Governance, Credentials e Auto-Improvement. Il gap riflette il posizionamento del cookbook: è una risorsa di apprendimento, non un workspace operativo, e molte delle discipline che L2-L4 misurano (telemetria, variance tracking, log di reflexion) sono fuori scope per il contenuto di cookbook.

Non interpretiamo il punteggio L1.3 come una critica al prodotto Anthropic; lo interpretiamo come evidenza che il cookbook serve uno scopo diverso dai workspace che è inteso ad insegnare. I team che usano il cookbook per fare il bootstrap del proprio workspace dovrebbero aspettarsi di aggiungere le discipline operative che il cookbook stesso non modella.

AutoGen ha ottenuto una media L1.0 — la più bassa nell'audit. Il framework ha L2 su Tools e L1 su tutti gli altri pillar. Il gap dominante è Multi-Agent DPI (L1), che riflette l'architettura MA-default di AutoGen che viola l'evidenza DPI (WSB-05).

Il framework ha anche L1 su Memory, Auto-Improvement e Forward-Deploy — lo stesso pattern di "demo-strong, production-weak" che abbiamo osservato in diversi framework. Come per Anthropic Cookbook, interpretiamo il punteggio L1.0 come evidenza che AutoGen è un framework per costruire prototipi piuttosto che per spedire workspace di produzione; i team che usano AutoGen in produzione dovrebbero aspettarsi di investire sostanzialmente in discipline operative che il framework non fornisce.

I team che leggono questo paper affrontano una domanda pratica: come applicare la matrice nel proprio workspace. Forniamo un playbook a 5 step basato sul case study Madani (§28). STEP 1 · AUDIT DI BASELINE.

Applicare la matrice a 60 celle allo stato corrente del workspace. Essere conservativi: nel dubbio tra L1 e L2, dare punteggio L1. Documentare evidenza specifica per ogni cella.

L'audit richiede 2-4 ore per un team familiare. STEP 2 · IDENTIFICARE IL CLUSTER A MEDIA PIÙ BASSA. Calcolare le medie per cluster.

Il cluster con la media più bassa è il primo target di remediation (più grande potenziale di lift immediato). STEP 3 · ALL'INTERNO DEL CLUSTER TARGET, SCEGLIERE IL PILLAR A PIÙ ALTO SHAPLEY (per WSB-01). All'interno del cluster Cognition, è Context; all'interno del cluster Trust, è Reliability; ecc.

STEP 4 · STILARE UNA CHECKLIST SPECIFICA DI ARTEFATTI L1-L2. Fare riferimento alla matrice a 60 celle per gli artefatti specifici richiesti. Stilare un piano di progetto per spedire quegli artefatti.

STEP 5 · MISURARE E ITERARE. Ri-valutare il workspace dopo la transizione L1-L2. Il lift atteso è da +0.3 a +0.5 sulla media del cluster.

Se il lift è più piccolo, gli artefatti sono probabilmente superficiali e richiedono un'ingegnerizzazione più profonda.

CASE STUDY · §31a · AUDIT LANGCHAIN. LangChain ha ottenuto una media L1.2 nel nostro audit. Il framework ha L3 su Tools (attraverso il ricco LangChain Hub di integrazioni) e L1 sulla maggior parte degli altri pillar.

Il pattern riflette il posizionamento di LangChain come framework componibile library-first: dà agli sviluppatori potenti Tool e primitivi ma non offre alcuna guida opinionata sulla disciplina a livello di workspace. Il gap dominante è Multi-Agent DPI (L1), che riflette i pattern di grafo di default di LangGraph che violano l'evidenza DPI (WSB-05) incoraggiando le topologie multi-agent come esempio naturale. Memory è L1 (il framework fornisce primitivi di memoria ma nessuna disciplina su quando usare quale); Reliability è L1 (nessuna chiave di idempotenza, nessuna infrastruttura di replay); Forward-Deploy è L1 (il deployment è lasciato interamente al team consumer).

Un team che costruisce su LangChain in produzione dovrebbe aspettarsi di aggiungere discipline operative che colmano 8+ dei 12 gap dei pillar, che è un investimento di engineering non banale.

CASE STUDY · §31b · AUDIT CREWAI. CrewAI ha ottenuto una media L1.1. Il framework ha L2 su Skills (l'astrazione crew/role è ben sviluppata) e L2 su Tools, con L1 su tutti gli altri 10 pillar.

I gap dominanti rispecchiano quelli di AutoGen e LangChain: Multi-Agent DPI L1 (l'astrazione crew è essa stessa un MA-default), Memory L1, Reliability L1, Auto-Improvement L1. Il framework è la scelta demo-friendly più forte tra i tre (l'astrazione crew è intuitiva e shippabile per prototipi) ma offre la disciplina meno production-ready. I team che usano CrewAI per deployment di produzione spesso scoprono che la demo iniziale facile maschera un debito operativo profondo che diventa costoso da ritirare in seguito.

CASE STUDY · §31c · AUDIT ANTHROPIC CLAUDE AGENT SDK. Il Claude Agent SDK ha ottenuto una media L1.2. L'SDK ha L3 su Tools (l'uso nativo dei tool di Claude è ben ingegnerizzato) e L1 sulla maggior parte degli altri pillar.

Il pattern è coerente con l'audit dell'Anthropic Cookbook: la superficie del prodotto enfatizza capacità di modello e tool lasciando la disciplina a livello di workspace al team consumer. Il punteggio L1 su Memory (nessun primitivo di memoria opinionato), Reliability (nessuna idempotenza o replay) e Forward-Deploy (nessuna impalcatura di deployment) riflette scelte di design per mantenere l'SDK minimale. I team che costruiscono sull'SDK in produzione dovrebbero aspettarsi di aggiungere infrastruttura di Memory e Reliability come primo investimento L2-L3.

CASE STUDY · §31d · AUDIT OPENAI AGENTS SDK. L'OpenAI Agents SDK (Python) ha ottenuto una media L1.6 — la seconda più alta tra i workspace non-Madani. L'SDK ha L4 su Tools (la storia di function-calling e tool-use è matura) e L2 su più pillar inclusi Skills, Observability e Governance (la piattaforma fornisce infrastruttura di telemetria e policy).

I punteggi L1 su Memory, Forward-Deploy e Auto-Improvement riflettono i gap di copertura dell'SDK. Il punteggio complessivo relativamente alto riflette l'investimento di OpenAI nell'infrastruttura di piattaforma che supporta di default la maturità L2. I team che costruiscono sull'SDK possono raggiungere L3 su pillar selezionati più velocemente dei team che partono da framework meno sviluppati, sebbene il platform-lock-in del framework crei preoccupazioni di Portability (L1).

DISCUSSIONE · §31e · IL TRADEOFF PIATTAFORMA VS LIBRERIA. Il confronto tra i case study fa emergere un tradeoff strutturale tra framework di tipo piattaforma (OpenAI Agents SDK) e framework di tipo libreria (LangChain, CrewAI, AutoGen). I framework di piattaforma forniscono una maturità di baseline L2 sui pillar del cluster Trust (Governance, Observability, Credentials) perché l'infrastruttura della piattaforma gestisce queste dimensioni.

I framework di libreria lasciano queste dimensioni al team consumer. Il tradeoff: i framework di piattaforma vincolano il team alle decisioni specifiche della piattaforma (che limita la Portability) mentre i framework di libreria richiedono più lavoro di engineering ma preservano la flessibilità. Non esiste una risposta universalmente giusta, ma i team dovrebbero essere consapevoli che la scelta ha implicazioni dirette sul punteggio di maturità.

Un team che vuole raggiungere L3+ sul cluster Trust velocemente può beneficiare di un framework di piattaforma; un team che vuole Portability sopra L2 può preferire un framework di libreria con più investimento di engineering.

ANTI-PATTERN 1 · PUNTARE A L4 SU OGNI PILLAR. Per il Risultato 4, questo è strutturalmente aspirazionale e il tentativo esaurisce la capacità di engineering. Puntare a L3 sui pillar a più alto Shapley; mantenere esplicitamente L2 sugli altri.

ANTI-PATTERN 2 · ATTESTAZIONE SENZA EVIDENZA. I team auto-attestano senza produrre gli artefatti di dati live. L'audit fallisce quando viene applicata strettamente la regola dei dati live.

ANTI-PATTERN 3 · ARTEFATTI STANTII. Documenti di standard scritti 18 mesi fa; dashboard create e mai aggiornate. Il ciclo di re-audit a 6 mesi li cattura, ma solo se il ciclo è istituzionalizzato.

ANTI-PATTERN 4 · IGNORARE IL DECADIMENTO. Team che raggiungono L3 e poi "celebrano il completamento" e smettono di mantenere gli artefatti. Per il Risultato 3, questo porta a regressione a L2 entro 6 mesi.

Lo status L3 è lavoro continuo, non un milestone. ANTI-PATTERN 5 · TRATTARE WAB COME CONCORRENTE DI SOC2/ISO. I framework affrontano dimensioni non sovrapposte; i deployment ad alta fiducia hanno bisogno di tutti e tre.

[1] CMMI Product Team (2010), CMMI for Development, Version 1.3, Carnegie Mellon Software Engineering Institute. [2] Humphrey W.S. (1989), Managing the Software Process, Addison-Wesley. [3] Paulk M.C. et al. (1995), The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley. [4] Crosby P.B. (1979), Quality Is Free: The Art of Making Quality Certain, McGraw-Hill. [5] Deming W.E. (1986), Out of the Crisis, MIT Press. [6] ISO/IEC (2023), 42001 Artificial Intelligence Management System. [7] AICPA (2017), SOC 2 Trust Services Criteria. [8] Gibson D.L., Goldenson D.R., Kost K. (2006), Performance Results of CMMI-Based Process Improvement, SEI Technical Report CMU/SEI-2006-TR-004. [9] Landis J.R. & Koch G.G. (1977), The Measurement of Observer Agreement for Categorical Data, Biometrics 33:159-174. [10] Cohen J. (1960), A Coefficient of Agreement for Nominal Scales, Educational and Psychological Measurement 20:37-46. [11] 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. [12] Wang C. & Shu Y. (2026), MetaCogAgent, arXiv:2605.17292v1. [13] 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. [14] CMMI Institute (2018), CMMI Model V2.0, ISACA. [15] ISO/IEC (2004), 15504 Software Process Assessment (SPICE). [16] Forsgren N., Humble J., Kim G. (2018), Accelerate: The Science of Lean Software and DevOps, IT Revolution Press. [17] Beyer B. et al. (2016), Site Reliability Engineering: How Google Runs Production Systems, O'Reilly. [18] Curtis B., Hefley B., Miller S. (2002), People CMM: A Framework for Human Capital Management, Addison-Wesley. [19] Anthropic (2024-2025), Building Agents Cookbook. [20] OpenAI (2025), Agents SDK Documentation. [21] LangChain (2024), Framework Architecture Guide. [22] Wu Q. et al. (2024), AutoGen, ICML. [23] Moura J. (2024), CrewAI. [24] Madani Lab (2026), WAB Acceptance Matrix v0.3.4 (60 cells, MIT-licensed). [25] Madani Lab (2026), WAB-9 Specification v0.3.4.