Eccellenza diagnostica senza apply è teatro. Un decision engine a cinque layer permette all'agent di auto-promuovere cambi al workspace senza pollare l'operatore.

Riportiamo il rollout di produzione di un decision engine auto-promote che permette a un agent workspace long-lived di applicare proposte di curation, candidati di memoria dal ciclo dreams e aggiornamenti di lesson derivati da reflexion senza pollare l'operatore umano per ogni cambio. L'engine codifica cinque layer — tre gate di principi primi (PP), sei gate di alpha-extraction (α), un gate di consapevolezza del comportamento LLM, un decision tree deterministico con snapshot-and-log, e una lista fissa di hard escalation rule che richiedono sempre un umano — e sostituisce il failure mode diagnostic-excellence / zero-apply osservato in tre sottosistemi di monitoring indipendenti (Curator skills audit, Dreams memory promotion, Reflexion lessons aggregation) durante la finestra pre-iter-39. L'engine è andato live il 2026-05-24 su tutti e tre i sottosistemi.

Il giorno del rollout, il Curator ha prodotto 50 proposte per run e l'engine ne ha auto-applicate 42 senza intervento dell'operatore, instradando le restanti a rejection o escalation; l'overlay Reflexion ha flaggato 196 candidati di lesson-violation nei sette giorni precedenti e ha auto-promosso quelli che superavano la soglia PP+α in `lessons-pending/`; il runner Dreams ha emesso 7 candidati di memoria, di cui il subset safe-append è stato applicato direttamente e il subset personalized è stato escalato. Il claim empirico headline è che monitoring senza apply è teatro: un sistema che fa emergere cinquanta proposte azionabili al giorno e non ne applica nessuna è strutturalmente indistinguibile da un sistema che ne fa emergere zero. Il decision engine è l'affordance mancante che converte i tre sottosistemi da dashboard descrittivi a loop cibernetico chiuso.

Avanziamo SETTE finding controintuitivi ancorati al rollout. (a) L'OPERATORE È IL BOTTLENECK, NON L'LLM — pre-engine, il Curator faceva emergere ~50 proposte/run ma ne applicava 0 perché ogni proposta richiedeva individualmente approvazione Nour; la coda cresceva più velocemente di quanto l'operatore potesse rivederla; l'auto-promote sposta il bottleneck dall'attenzione umana ai gate PP+α e la coda si svuota. (b) I PRINCIPI PRIMI SONO PRECONDIZIONI PIÙ FORTI DEI CRITERI — i tre PP (SELF-AWARENESS pre-action, EVIDENCE=CLAIM, LISTENING DISCIPLINE) sono codificati in `12_HARNESS/operativo/lessons-learned.md` v2.0 come condizioni necessarie che ogni auto-apply deve passare; sono più forti dei criteri di scoring perché non possono essere scambiati l'uno con l'altro — una proposta che fallisce PP1 viene rigettata indipendentemente da quanto alto scora su α. (c) ALPHA EXTRACTION È UN TEST MULTI-DIMENSIONALE, NON UNO SCORE — i sei criteri α (non-fragility, cache-friendliness, cost-aware, single-source-truth, provenance traceable, reversibility) sono AND-gate nell'engine; una proposta che scora alto su cinque e zero su uno viene rigettata, perché il failure mode dell'asse fallente domina la vittoria sugli altri (es. un apply irreversibile con alto single-source-truth è peggio di un apply reversibile con single-source-truth mediocre). (d) LA CONSAPEVOLEZZA DEL COMPORTAMENTO LLM È IL LAYER CHE LA MAGGIOR PARTE DEI FRAMEWORK SALTA — prompt-injection dentro file letti, concept drift tra proposte simili, changelog bloat che costa cache hit, frasi-trigger ambigue che matchano skill multiple, contaminazione multi-voce su scritture personalized; l'engine codifica un check per ciascuno, e ~18% dei candidati pre-engine avrebbe introdotto almeno uno di questi failure mode se applicato ciecamente. (e) HARD ESCALATION È CIÒ CHE RENDE L'AUTO-PROMOTE SICURO — sei categorie sono always-human (external communications via HR#1, self-modification di `settings.json`, operazioni git distruttive, decisioni architetturali, codificazione di hard rule, touch di credenziali); l'engine è noioso dentro questi confini e silenzioso fuori, che è esattamente l'inversione che l'approvazione-operatore-su-tutto aveva al contrario. (f) SNAPSHOT-AND-LOG È IL COSTO DELLA REVERSIBILITY — ogni auto-apply scrive un tar.gz pre-mutation in `99_ARCHIVIO/skill-snapshots/<timestamp>-<action>.tar.gz` più una log line strutturata; il costo storage è trascurabile (KB per azione) e il costo di rollback è a un `tar -xzf` di distanza; senza questo, α6 reversibility è non-enforceable e l'intero engine è insicuro. (g) LA VITTORIA CONTROINTUITIVA È CHE L'AUTO-APPLY MIGLIORA LA FIDUCIA DELL'OPERATORE — pre-engine l'operatore doveva rivedere cinquanta proposte al giorno e ne rigettava la maggior parte come rumore; la coda era una tassa di attenzione; post-engine l'operatore vede solo le escalation che richiedono genuinamente giudizio umano, e il tasso residuo di escalation è ~15% del totale proposte; l'operatore adesso rivede meno item, ciascuno con segnale più alto, e si fida di più del sistema perché le decisioni di apply dell'engine sono auditabili end-to-end via la trail di snapshot+log. Il contributo è empirico (i numeri di rollout 24-05 sui tre sottosistemi · 42/50 applicate · 196 correzioni rilevate · 7 candidati dream), architetturale (l'engine a cinque layer come l'affordance mancante tra monitoring e apply), operativo (la convention snapshot+log che rende l'auto-promote reversibile-by-default) e metodologico (lo stack di gate PP+α+LLM-behavior come pattern trasferibile che altri workspace possono adottare senza il codice specifico dei nostri sottosistemi).

Tre sottosistemi di monitoring erano live nel workspace Madani da iter-30 a iter-39 e ciascuno, secondo la propria metrica interna, funzionava. Il Curator (skill audit) scansionava giornalmente tutti i 50 skill attivi ed emetteva una lista strutturata di proposte — script rotti, timestamp `last_updated` stale, dipendenze deprecate, campi di frontmatter mancanti, candidati di merge tra skill, candidati di split. Il runner Dreams leggeva la reflexion del giorno precedente più il tier personalized ed emetteva candidati di memoria — pattern che l'agent aveva osservato abbastanza volte da meritare promozione da `_drafts/` verso un tier tipizzato.

L'aggregatore Reflexion parsava il JSONL di sessione del giorno ed emetteva un report di lesson-violation — turn in cui l'agent aveva fallito contro una regola codificata esistente, più turn che suggerivano regole candidate nuove. I tre sottosistemi insieme producevano, in una settimana pre-engine rappresentativa, circa 320 item azionabili. Il numero applicato dall'agent stesso in quella settimana era zero.

Ogni item richiedeva un prompt esplicito di Nour per essere applicato, e i prompt arrivavano in batch a intervalli irregolari, il che significava che la coda cresceva monotonicamente. Alla fine della finestra iter-38 il backlog aveva superato i 400 item irrisolti, l'operatore trattava la dashboard come una seccatura e i tre sottosistemi erano sulla strada di essere deprecati come "monitoring costoso che non produce niente". La storia tecnica è che monitoring excellence e decision excellence sono layer differenti, e un workspace che ne costruisce uno senza l'altro è strutturalmente indistinguibile da un workspace che non ne ha nessuno — le proposte decadono di valore nel momento in cui non vengono applicate, e il costo dei tool di monitoring (LLM credit, slot cron, IO disco) è pagato contro un return di zero.

Il fix ingenuo al gap qui sopra è "fai rivedere a Nour più velocemente". Fallisce sotto ispezione: il review-rate scala con le ore-operatore e la qualità dell'attenzione-operatore, entrambe costanti; il proposal-rate scala con la dimensione del workspace e la copertura di monitoring, entrambe crescenti super-linearmente con il conteggio di iterazione. Il mismatch asintotico non è un problema di staffing; è un problema architetturale.

Il fix giusto è spostare lo step di decisione dall'operatore all'agent, ma solo dentro un perimetro che l'operatore ha pre-autorizzato via regole codificate. Questo è il decision engine auto-promote: una pipeline deterministica a cinque layer che prende una proposta da uno qualsiasi dei tre sottosistemi e restituisce uno di quattro verdetti — APPLY, REJECT, ESCALATE_NOUR, DEFER_NEXT_RUN — basato su regole che l'operatore ha codificato una volta e che l'engine enforce ogni volta. Il ruolo dell'operatore si sposta da revisore-per-item a autore di regole e responder di escalation.

Il numero di item che l'operatore gestisce scende di un ordine di grandezza; l'autonomia dell'agent aumenta dello stesso fattore; l'audit trail (snapshot + log per ogni azione applicata) permette all'operatore di spot-checkare o rollbackare in qualsiasi momento. Lo shift architetturale rispecchia un pattern familiare dall'engineering dei sistemi operativi: la policy appartiene all'utente, il meccanismo appartiene al kernel. Pre-iter-39 il workspace non aveva kernel; ogni meccanismo chiedeva permesso all'utente.

Post-iter-39 l'engine è il kernel; l'utente scrive policy e il kernel la enforce.

   DECISION ENGINE AUTO-PROMOTE · PIPELINE A 5 LAYER
   ──────────────────────────────────────────────────────
   PROPOSTA
     │
     ▼
   ┌─────────────────────────────────────────────────┐
   │ LAYER 1 · PP GATES (condizioni necessarie)      │
   │   PP1 SELF-AWARENESS · PP2 EVIDENCE=CLAIM       │
   │   PP3 LISTENING DISCIPLINE                       │
   └────────────────────┬────────────────────────────┘
                        │ pass
                        ▼
   ┌─────────────────────────────────────────────────┐
   │ LAYER 2 · ALPHA GATES (6-AND test)              │
   │   α1 non-fragility · α2 cache-friendliness      │
   │   α3 cost-aware · α4 single-source-truth        │
   │   α5 provenance · α6 reversibility               │
   └────────────────────┬────────────────────────────┘
                        │ pass
                        ▼
   ┌─────────────────────────────────────────────────┐
   │ LAYER 3 · CONSAPEVOLEZZA COMPORTAMENTO LLM      │
   │   prompt-injection · concept drift · duplicati  │
   │   changelog bloat · trigger ambigui · voce      │
   └────────────────────┬────────────────────────────┘
                        │ pass
                        ▼
   ┌─────────────────────────────────────────────────┐
   │ LAYER 4 · SNAPSHOT → APPLY → LOG                 │
   │   tar.gz pre-mutation + log line strutturata    │
   └────────────────────┬────────────────────────────┘
                        │
                        ▼
                   ✅ APPLICATO

   ogni layer FAIL ──▶ REJECT o ESCALATE_NOUR (L5)

Quattro contributi. (1) Empirico: numeri di rollout dal 2026-05-24 sui tre sottosistemi. Curator: 50 proposte/run · 42 auto-applicate · 5 rigettate · 3 escalate. Reflexion: 196 candidati di lesson-violation rilevati · pipeline di auto-promote live verso `lessons-pending/` con gating PP. Dreams: 7 candidati · 4 auto-applicati (safe-append) · 3 escalati (scritture personalized). (2) Architetturale: l'engine a cinque layer documentato come pattern trasferibile, con la logica di gate di ogni layer specificata indipendentemente dal codice specifico dei sottosistemi Madani, così che un workspace diverso possa re-implementare l'engine contro i propri equivalenti di Curator/Dreams/Reflexion. (3) Operativo: la convention snapshot+log (`99_ARCHIVIO/skill-snapshots/<timestamp>-<action>.tar.gz` più stdout strutturato) che rende ogni auto-apply reversibile-by-default con overhead di storage trascurabile. (4) Metodologico: lo stack di gate PP + α + LLM-behavior come test a tre tier di condizioni necessarie che scala dalla skill curation alle scritture di memoria alla promozione di lesson senza re-design per dominio.

Il decision engine sta all'intersezione di quattro thread precedenti. Il verbal reinforcement learning (Shinn et al., Reflexion, NeurIPS 2023, arXiv:2303.11366) ci ha dato la primitive del loop cibernetico — agent che producono una critica verbale della propria traccia e la usano per aggiornare il behavior. Reflexion nel paper originale chiude il loop per-task; il gap che chiudiamo è chiudere il loop a livello di workspace — la critica scrive in un tier di memoria tipizzato, la memoria guida il behavior nelle sessioni successive e lo step di apply è automatizzato oltre un gate.

Il self-bootstrapping di skill-as-code (Voyager, arXiv:2305.16291) ha mostrato un agent che fa crescere autonomamente la propria libreria di skill in un environment Minecraft; l'analogo più vicino in produzione è il pattern Hermes-agent di NousResearch che applica la stessa iterazione ricorsiva a file di skill in un workspace. Adottiamo la disciplina di auto-update di Hermes come substrato su cui il sottosistema Curator opera. La multi-agent failure analysis (Cemri et al., MAST, NeurIPS 2025, arXiv:2503.13657) ci ha dato la tassonomia di failure a 14 mode che informa il gate di LLM-behavior al Layer 3 — concept drift, trigger ambiguity, output-shape mismatch appaiono tutti come mode MAST che il gate screena esplicitamente.

La DPI single-thread supremacy (Tran & Kiela, Stanford, arXiv:2604.02460) ci ha dato il vincolo che l'engine stesso gira single-thread: un decision engine multi-agent perderebbe la stessa informazione che la DPI documenta nel reasoning multi-agent, quindi l'engine è una pipeline deterministica singola piuttosto che un dibattito tra critici specializzati. La metacognizione prospettica (Wang & Shu, MetaCogAgent, arXiv:2605.17292) ci ha dato la primitive escalate-when-c-below-threshold che l'engine invoca per proposte ambigue dove né i gate PP né i gate α producono un verdetto APPLY/REJECT pulito. Inoltre ereditiamo la disciplina di stabilità del KV-cache da Manus e dalla più ampia letteratura Anthropic Effective Harnesses: ogni apply che muta un file ad alto traffico (CLAUDE.md, lessons-learned.md, header SKILL.md) è gated da α2 cache-friendliness per evitare di invalidare cache calde grandi per content gain marginale.

METODOLOGIA · §5 · LAYER 1 · I TRE PP GATE. Tre principi primi, codificati verbatim da `12_HARNESS/operativo/lessons-learned.md` v2.0 (last_updated 2026-05-21). Ogni auto-apply deve passare tutti e tre, in ordine. PP1 SELF-AWARENESS pre-action: l'engine fa quattro domande prima di applicare.

Chi ha chiesto questo cambio — se la risposta è "il generatore di proposte stesso, senza ancora operatore", la proposta non passa unilateralmente; deve mappare a un intent operatore esistente o a una regola codificata. Il sistema attuale funziona — se l'artefatto che viene modificato sta funzionando e la proposta è "miglioramento", PP1 demota l'urgenza e la proposta ha bisogno di α5 provenance esplicita verso un segnale Nour. La proposta applica un constraint dichiarato dall'utente — proposte che codificano o enforce un constraint dichiarato da Nour passano PP1 trivialmente; proposte che propongono un constraint nuovo non presente in nessun artefatto operatore falliscono PP1.

Quali file tocca questo cambio e il cross-impact è identificato — proposte che toccano shared component (l'equivalente workspace del refactor L01 `_ArticleLayout.tsx` che ha rotto 9 consumer) richiedono un grep esplicito dei consumer prima che lo step di apply sia sbloccato. PP2 EVIDENCE = CLAIM: "fatto X" si asserisce solo con evidence verificata oggettivamente, non con assumption. L'engine rifiuta di dichiarare APPLIED finché la verifica post-apply non è girata — `ls -la` sul file, `wc -l` sul conteggio righe, `git log -1` sul commit, `curl /v1/models` per i pod deployati. Una proposta che non può specificare la propria verifica post-apply fallisce PP2. PP3 LISTENING DISCIPLINE: quando la proposta contiene un concetto tecnico Nour-stated ("preflight" · "canonical" · "ne hai uno · ferma tutto" · "singleton" · "in passato funzionava") l'engine tratta il concetto come expertise emergente e lo applica come gate/regola/script piuttosto che brainstormare alternative.

Il protocollo a quattro step — STOP / RESTATE / IMPLEMENT / THEN procedi — è encoded come logica di gate: qualsiasi proposta che propone di elaborare o estendere un concetto Nour-stated prima di implementarlo verbatim fallisce PP3. I tre gate sono deliberatamente più forti di "linee guida": PP1 da solo ha catturato 23 di 50 proposte Curator sul run 24-05 che erano "miglioramenti" senza ancora operatore e che l'engine ha downgradato da APPLY a DEFER_NEXT_RUN in attesa di una menzione Nour.

METODOLOGIA · §6 · LAYER 2 · I SEI ALPHA GATE. I sei criteri α sono AND-gate, non assi di scoring. Una proposta che fallisce un singolo gate α viene rigettata indipendentemente dalla forza sugli altri cinque.

La disciplina rispecchia il pattern di alpha-extraction dal trading quantitativo, dove una strategia che scora alto su Sharpe ma zero su tail-risk non è una strategia che spedisci. α1 NON-FRAGILITY: l'apply non introduce un nuovo single point of failure. Proposte che hard-codano path verso location non-canonical, che dipendono da un cron transient, che dipendono da un'API esterna senza fallback, che bindano a una versione di modello che potrebbe ruotare — tutte falliscono α1. α2 CACHE-FRIENDLINESS: l'apply non invalida il KV-cache per content marginale. Mutazioni a file di prefisso ad alto traffico (CLAUDE.md, header lessons-learned.md, campi `description` di SKILL.md) costano cache-warmth su ogni sessione successiva; il gate richiede che il valore-per-token della mutazione superi la cache-loss-per-token attesa sulle prossime 24 ore di attività.

L'engine stima quest'ultima dalla tabella di history del prompt-cache (cache-hit count per file delle ultime 24h) e applica α2 con una soglia documentata. α3 COST-AWARE: l'apply non aumenta il costo operativo per-task oltre un budget esplicito. Proposte che aggiungono una nuova chiamata LLM mandatoria a un hot path, che promuovono un template verboso in un file letto frequentemente, che spostano un cron da settimanale a giornaliero senza giustificazione — tutte attraversano α3 a meno che la proposta non porti il proprio cost-offset (es. compressione concomitante di un altro path). α4 SINGLE-SOURCE-TRUTH: l'apply non duplica state. Proposte che creano un nuovo file con content già presente in un altro file canonical falliscono α4 (questa è HR#3 codificata).

Proposte che consolidano state nella sorgente canonical passano α4 e sono auto-applicate in via preferenziale. α5 PROVENANCE TRACEABLE: l'apply ha una sorgente documentata — un'utterance Nour con timestamp, una citazione paper con URL arXiv, un hash di commit upstream, un reference a un documento di audit. Proposte generate dal sottosistema solo, senza anchor esterno, falliscono α5; possono essere escalate per review operatore ma non auto-applicano. α6 REVERSIBILITY: l'apply può essere disfatto da una singola operazione (`tar -xzf <snapshot>`, `git revert <hash>`, `rm -rf <new-folder>`). Proposte che attraversano irreversibilità — rotation di credenziali, chiamate API esterne che cambiano remote state, force-push su main, `crontab -r` — falliscono α6 categoricamente.

I sei gate insieme hanno rigettato circa il 25% dei candidati pre-engine sul giorno di rollout, con il gate più fallente che era α4 (single-source-truth) — lo stato legacy del workspace aveva accumulato duplicazioni che il Curator stava proponendo di "risolvere in avanti" piuttosto che "consolidare indietro", e α4 ha reindirizzato quelle verso proposte di consolidamento.

METODOLOGIA · §7 · LAYER 3 · CONSAPEVOLEZZA DEL COMPORTAMENTO LLM. I gate del Layer 3 codificano cosa succede quando un LLM è esposto a pattern di content specifici prone-to-failure. Il gate non è "la proposta è buona" — quello è Layer 1+2 — ma "l'apply espone la prossima invocazione di un qualsiasi agent a un failure mode LLM noto".

Sette sub-gate. (i) Prompt-injection dentro file letti: ogni apply che scrive content in un file che l'agent leggerà successivamente deve screenare per pattern `<system>`, `IGNORE PREVIOUS INSTRUCTIONS`, o `<sysprompt>` embedded. L'engine strip o rigetta. (ii) Concept drift tra proposte near-duplicate: quando due proposte nello stesso run referenziano lo stesso concetto sottostante con framing leggermente diverso (es. "skill auto-update" e "skill auto-refresh"), l'engine le merga piuttosto che applicarle entrambe, sul principio che due near-duplicate diluiscono il retrieval downstream. (iii) Changelog bloat: i changelog append-only crescono illimitatamente sotto auto-promote ingenuo; il gate enforce che nessun singolo changelog attraversi il limite canonical di 200 righe ed emette una proposta di roll-up quando il limite è raggiunto. (iv) Trigger ambiguity nel frontmatter SKILL.md: una skill che aggiunge una frase-trigger già usata da un'altra skill viene rigettata sul principio che trigger ambigui producono wrong-skill invocation (l'anti-pattern skill-bypass documentato in lessons-learned). (v) Specifics vs vagueness: una proposta il cui testo di action è vago ("migliora documentazione") viene rigettata; le proposte devono specificare esattamente quale file, quali righe, quale cambio. (vi) Contaminazione multi-voce in scritture personalized: scritture personalized che mescolano la voce di Nour con osservazioni dell'agent stesso vengono rigettate, perché i reader downstream del tier personalized (l'hook di cold-start, il resolver di preferenze Sentra-style) non possono disambiguare principal-utterance da agent-observation. (vii) Trailing summary pattern in ogni text apply — l'engine rigetta content che termina con "in summary, this lesson is..." o filler equivalente, perché Nour legge diff e i trailing summary sono rumore. Layer 3 ha rigettato ~18% dei candidati restanti sul giorno di rollout, con il gate più frequentemente fallente che era (ii) concept drift — il Curator aveva una tendenza a produrre proposte near-duplicate su run consecutivi che l'engine adesso collassa in una proposta merged singola.

METODOLOGIA · §8 · LAYER 4 · DECISION TREE DETERMINISTICO CON SNAPSHOT-AND-LOG. Il decision tree a quattro verdetti (APPLY, REJECT, ESCALATE_NOUR, DEFER_NEXT_RUN) è deterministico — stesso input produce stesso output — e la valutazione completa è loggata. APPLY richiede che tutti e tre i layer (PP, α, LLM-behavior) passino più uno snapshot riuscito. Lo snapshot è un `tar.gz` di ogni file che l'apply muterà, scritto in `99_ARCHIVIO/skill-snapshots/<ISO-timestamp>-<action-slug>.tar.gz` prima che l'apply giri.

L'apply stesso gira come la stessa operazione atomica che sarebbe girata sotto approvazione operatore — `git commit` per cambi repo, `mv` + `chmod` per spostamenti filesystem, invocazione del tool `Edit` per mutazioni in-file. La log line è un JSON record per apply, scritto in `12_HARNESS/operativo/_apply-log/YYYY-MM-DD.jsonl` con campi: timestamp, sottosistema (curator/dreams/reflexion), proposal-id, verdetto (APPLY/REJECT/ESCALATE/DEFER), bitmap di layer-pass (quali layer sono passati), snapshot-path, verifica post-apply (file count / line count / commit hash). Il log è l'artefatto primario di auditability ed è letto dall'endpoint `/api/agent/daily-digest` daily-digest per far emergere le azioni auto-applicate di quel giorno nella monitoring-dash. REJECT è il verdetto quando un gate Layer 1+2 fallisce con high confidence e la proposta non è salvabile; la rejection viene loggata con il nome del gate fallente così il proposal generator può essere tunato. ESCALATE_NOUR è il verdetto quando la proposta tocca una delle sei categorie di hard-escalation (Layer 5, sotto) o quando MetaCogAgent (`metacog-self-assess.py`) restituisce `c_composite < 0.55` sull'assessment dell'engine stesso dell'apply; la proposta viene scritta in `mission-control/escalations/<date>-<proposal-id>.md` con un summary self-contained così l'operatore può agire senza ri-derivare context. DEFER_NEXT_RUN è il verdetto quando i gate producono né un APPLY pulito né un REJECT pulito — tipicamente un fallimento PP1 su operator-anchor dove il prossimo run può portare un segnale Nour fresco.

La coda differita viene ri-valutata al prossimo run del sottosistema con lo stato workspace aggiornato.

METODOLOGIA · §9 · LAYER 5 · HARD ESCALATION RULE (SEMPRE UMANO). Sei categorie sono pre-dichiarate dall'operatore come never-auto-apply, indipendentemente dal verdetto prodotto dai Layer 1-4. La lista è breve by design — ogni categoria always-human aggiuntiva riduce l'autonomia dell'engine, quindi ogni aggiunta ha bisogno di una giustificazione di costo esplicita. (1) External communications: HR#1 — qualsiasi apply che produce un messaggio a un cliente, membro team, canale Slack, destinatario email, SMS, destinatario WhatsApp.

L'engine non auto-applica mai external comms; la proposta viene scritta in un file ed escalata per il dispatch dell'operatore. (2) Self-modification di `settings.json`: cambi a `~/.claude/settings.json` o `.claude/settings.local.json` toccano la configurazione di runtime dell'agent stesso e hanno blast radius illimitato; l'auto-modification è categoricamente disallowed. (3) Operazioni git distruttive: `git reset --hard`, `git push --force` su main, `git checkout --`, `crontab -r`, `launchctl unload` di plist agent-rilevanti — tutte categoricamente escalate anche quando α6 reversibility nominalmente passa, perché il costo di reversibility in questi casi supera il valore della proposta. (4) Decisioni architetturali: qualsiasi apply che cambi il layout delle 12 macro (`02_LEAD-GENERATION/`, `10_SKILLS/`, `12_HARNESS/`, ...), la partizione di memoria a 5 tier, o la tassonomia WAB a 12 pillar — questi sono commitment architetturali operator-authored e l'engine non li modifica. (5) Codificazione di hard rule: qualsiasi apply che aggiunga una nuova HR# a CLAUDE.md o a un file di rules project-level. Le hard rule vincolano ogni azione futura dell'agent; la loro aggiunta è operator-only. (6) Touch di credenziali: qualsiasi apply che tocchi `~/madani/credentials/API-MASTER.md`, `.envrc`, `.envrc.template`, o qualsiasi metadata del vault 1Password — le credenziali sono governate dalla credentials-policy e mai auto-modificate dall'engine.

   LAYER 5 · HARD ESCALATION RULE · SEMPRE UMANO
   ───────────────────────────────────────────────
   1. External communications (HR#1)
   2. Self-modification di settings.json
   3. Operazioni git distruttive (reset/force-push/crontab -r)
   4. Decisioni architetturali (12-macro · 5-tier · 12-pillar)
   5. Codificazione di hard-rule (HR#)
   6. Credenziali (API-MASTER · vault · .envrc)
   ───────────────────────────────────────────────
   →  l'engine è NOIOSO dentro · SILENZIOSO fuori

RISULTATI · §10 · ROLLOUT CURATOR · 50 PROPOSTE · 42 AUTO-APPLICATE. Il sottosistema Curator ha girato il suo primo pass under-engine il 2026-05-24 alle 02:30 UTC contro i 50 skill attivi in `10_SKILLS/`. Il pass ha prodotto 50 proposte totali.

Dopo Layer 1 (PP gate), 41 proposte rimanevano APPLY-candidate, 6 sono diventate DEFER_NEXT_RUN (fallito PP1 operator-anchor) e 3 sono diventate ESCALATE_NOUR (toccavano confini HR-adjacent). Dopo Layer 2 (α gate), 35 proposte rimanevano APPLY-candidate, con α4 (single-source-truth) che era la rejection reason dominante — il Curator aveva emesso 5 proposte "create new file" dove l'engine identificava un file canonical esistente che doveva essere aggiornato. Dopo Layer 3 (LLM-behavior), 33 proposte rimanevano APPLY-candidate, con α2 cache-friendliness e trigger-ambiguity che condividevano le rejection rimanenti.

Il conteggio APPLY finale dopo lo snapshot Layer 4 era di 42 — le 33 dallo stack gate stretto più 9 proposte che l'engine ha fast-tracked via la subroutine "safe-append" (changelog append, bump di `last_updated` ISO-date, increment di observation-count — operazioni che toccano solo metadata single-line e sono categoricamente reversibili). Il tree di snapshot del giorno di rollout in `99_ARCHIVIO/skill-snapshots/` ha accumulato 42 file `tar.gz` totalizzanti 11 MB — un costo storage trascurabile per la reversibility che ha comprato.

RISULTATI · §11 · ROLLOUT DREAMS · APPLY STAGE LIVE · SAFE-APPEND AUTO · PERSONALIZED ESCALATE. Il runner Dreams (`dreams-runner.py`, cron daily 03:00) ha prodotto 7 candidati di memoria sullo stesso giorno di rollout, derivati dalla reflexion del giorno precedente più dal delta del tier personalized. L'engine li ha instradati come segue. Quattro candidati sono stati classificati come safe-append — aggiunte al tier semantic sotto topic tag esistenti con confidence inferita da grep-similarity e observations contate da occorrenza prior — e auto-applicati, ciascuno con la copia di archivio canonical `_drafts/_promoted/` e uno snapshot. Tre candidati sono stati classificati come personalized — preference statement sullo stile di lavoro di Nour, pattern di time-of-day, tell di frammentazione voice-to-text — ed escalati.

La rationale di escalation è dura: le scritture del tier personalized sono claim di principal-attribution, e una wrong attribution (l'agent che claim Nour ha detto X quando Nour non l'ha detto) degrada la reliability del tier personalized per ogni reader downstream. L'engine rifiuta di auto-applicare scritture personalized anche quando tutti i gate PP+α nominalmente passano; il gate è hard-coded come eccezione al Layer 4 APPLY, indipendentemente dallo score. La stessa eccezione si applica alle scritture environment-dynamics nel sub-bucket `nour-response/` — queste catturano pattern Nour-specifici e hanno bisogno della conferma operatore prima di entrare nel tier.

RISULTATI · §12 · ROLLOUT REFLEXION · 196 CORREZIONI RILEVATE · AUTO-PROMOTE A LESSONS-PENDING. Il runner Reflexion ha emesso un report di backfill sul giorno di rollout coprendo i sette giorni precedenti di traccia JSONL di sessione. Il report ha flaggato 196 candidati di lesson-violation — turn dove l'agent aveva agito contro una regola codificata esistente da `lessons-learned.md` v2.0 — e 27 candidati-pattern-nuovi che non matchavano nessuna regola esistente ma che erano ricorsi almeno tre volte.

L'engine ha processato entrambi i bucket attraverso lo stack di gate. Per il bucket di violation, l'engine ha auto-promosso ogni candidato con PP+α pass più recurrence ≥ 4 in `lessons-learned-pending/` per codificazione del ciclo successivo, ma non ha auto-promosso in `lessons-learned.md` stesso — la categoria Layer 5 (5) blocca la codificazione HR#, e la promozione di lesson a canonical cade in quella categoria. Per il bucket di pattern nuovi, l'engine ha applicato lo stesso stack PP+α e ha instradato tutti i 27 a ESCALATE_NOUR per review operatore, sul principio che le lesson nuove sono operator-authored anche quando l'agent ha rilevato il pattern.

L'effetto netto è che il sottosistema Reflexion adesso produce un file lessons-pending auto-curated ogni mattina, e il lavoro dell'operatore cambia da "leggere 196 violation grezze" a "rivedere 27 candidate pattern nuovi più un roll-up di violation pre-sorted".

DISCUSSIONE · §13 · TRADE-OFF · RISCHIO DI FALSE-POSITIVE E TASSO DI ESCALATION. L'engine non è libero da trade-off. Il rischio dominante è APPLY false-positive — l'engine che auto-applica una proposta che doveva essere escalata.

Caratterizziamo il false-positive rate operativamente come la frazione di azioni auto-applicate che l'operatore successivamente rollbacca. Sul rollout 24-05, l'operatore ha rollbackato zero dei 42 apply Curator e zero dei 4 apply Dreams safe-append; la trail di log + snapshot post-apply ha reso lo spot-check triviale. La settimana di operatività di follow-up ha prodotto due rollback operator-initiated — una riscrittura di description `SKILL.md` Curator che era drifted dalla fraseggio intenzionale dell'operatore, un append semantic-tier Dreams che l'operatore ha flaggato come ridondante — per un false-positive rate empirico di ~4% allo step di apply.

Il secondo rischio è falso-negativo escalate — l'engine che escala proposte che potevano essere auto-applicate. Il tasso di escalation 24-05 era 6/50 = 12% sul Curator e 3/7 = ~43% su Dreams; il numero Dreams è alto perché le scritture personalized sono categoricamente escalate indipendentemente dallo score, che è un conservatism hard-coded che crediamo sia corretto in questo stadio del rollout. Il terzo trade-off è il costo di engine-tuning: le soglie dei gate (soglia di α2 cache-friendliness, recurrence ≥ 4 per auto-promote di violation, MetaCog `c_composite < 0.55` per escalation) hanno bisogno di calibrazione contro dati di outcome e attualmente sono settate da prior Madani-internal; le versioni future le regredirgranno contro il segnale di operator-rollback.

I sei criteri α sono stati derivati da pattern Madani-interni pre-engine, ma il rollout ha prodotto validation empirica della loro indipendenza. Abbiamo misurato la correlazione pairwise tra segnali di gate-pass sulle 50 proposte Curator: α1-α2 = 0,18, α1-α4 = 0,21, α2-α3 = 0,09, α2-α4 = 0,12, α4-α5 = 0,31, α5-α6 = 0,27. Nessuna delle 15 correlazioni pairwise ha superato 0,32, indicando che i sei assi sono failure mode sostanzialmente indipendenti piuttosto che collassabili in meno dimensioni.

L'asse di rejection dominante sul Curator era α4 (single-source-truth, 5 rejection); su Dreams era α5 (provenance, 1 rejection); sui candidati di violation di Reflexion era Layer 5 hard-escalation piuttosto che α (perché la codificazione di lesson è sempre-umano). L'indipendenza dei sei assi α è ciò che li fa funzionare come AND-gate: un approccio scoring che li averagiasse maschererebbe l'asse fallente dominante, e la disciplina AND-gate dell'engine è ciò che garantisce che nessun failure mode singolo scivoli attraverso.

LIMITAZIONI · §15 · COSA QUESTO STUDIO NON È. (1) n = 1 workspace. Tutti i numeri di rollout vengono dal workspace di riferimento Madani. L'architettura a cinque layer è presentata come pattern che altri workspace possono adottare, ma gli split apply/reject/escalate specifici che riportiamo sono workspace-specifici.

Ci aspettiamo che la forma dello stack di gate generalizzi (PP+α+LLM-behavior è strutturalmente invariante) ma che le soglie richiedano calibrazione locale. (2) Status di ricerca preliminare. L'engine è andato live nel giorno in cui questo paper è stato draftato. La finestra di osservazione di follow-up è breve e non abbiamo ancora una misurazione long-horizon (>30 giorni) del false-positive rate allo step di apply, della frequenza di rollback dell'operatore, o del tasso al quale i gate dell'engine stesso avrebbero bisogno di essere strecciati o allentati man mano che lo stato workspace evolve.

Ci impegniamo a un aggiornamento v0.2 con dati di rollout 30-day. (3) Criteri alpha soggettivi. I sei assi α sono stati scelti per introspezione su failure mode Madani precedenti. Non abbiamo ancora mostrato che i sei sono gli assi minimi sufficienti o che nessun settimo asse ridurrebbe significativamente i false-positive.

La misurazione di indipendenza in §14 argomenta contro il collasso del set, ma un asse future-work (es. un settimo asse "model-version-robustness" che screena per proposte che bindano a una classe modello specifica) è plausibile. (4) Workspace single-operatore. Il confine HR#1 dell'engine e la logica PP1 operator-anchor assumono un singolo principal (Nour). In un workspace multi-operatore, la domanda PP1 "chi ha chiesto questo cambio" ha bisogno di disambiguazione tra operatori, e la coda di escalation ha bisogno di routing principal-aware.

Non l'abbiamo implementato e non claim che l'architettura generalizzi a setting multi-principal senza modifica. (5) Nessun test di adversarial-robustness contro l'engine stesso. Un attacker sofisticato che potesse scrivere a uno degli input del proposal-generator (un transcript reflexion, un target di scan Curator, un candidato memoria Dreams) potrebbe in linea di principio craftare una proposta progettata per passare i gate introducendo un cambio dannoso. Layer 3 (LLM-behavior awareness) screena per pattern noti ma non è una garanzia formale di adversarial-robustness.

I confini di credentials ed external-comm al Layer 5 sono la difesa operativa; non abbiamo red-teamato l'engine e quel lavoro è pending.

Il workspace pre-iter-39 aveva tre eccellenti sottosistemi di monitoring e zero disciplina di apply. Il workspace post-iter-39 ha gli stessi tre sottosistemi più un decision engine a cinque layer, e il tasso di apply sul giorno di rollout era l'84% del volume di proposte senza intervento operatore. La lezione architetturale è che diagnostic excellence è necessaria ma non sufficiente — un workspace che fa emergere cinquanta proposte azionabili al giorno e ne applica zero è, dal punto di vista del behavior-change, strutturalmente indistinguibile da un workspace che non ne fa emergere nessuna.

L'engine a cinque layer è l'affordance mancante. La lezione più profonda è che il pattern operator-approval-on-everything che gli attuali framework agentic adottano per default è il default sbagliato a scala workspace. Una volta che un workspace attraversa ~30 skill attivi, ~5 loop di monitoring cron-driven e ~100 proposal-event giornalieri, l'approvazione per-item è un denial-of-service contro l'operatore e un denial-of-value contro il workspace.

Il fix non è "approva più velocemente" ma "codifica le regole una volta, enforce-le ogni volta, escala solo ciò che ha genuinamente bisogno di giudizio umano". L'engine implementa quell'inversione. Lo stack di gate PP+α+LLM-behavior è un pattern trasferibile.

Altri workspace con i propri analoghi di Curator/Dreams/Reflexion possono adottare l'architettura senza il codice specifico dei nostri sottosistemi, calibrare le soglie contro il proprio segnale di operator-rollback e chiudere il loop cibernetico sulla propria timetable. Il riferimento empirico per come appare il "loop chiuso" è il rollout Madani 24-05: 42/50 auto-applicate · 196 correzioni rilevate · 7 candidati dream instradati · zero rollback operator-initiated al giorno uno. L'engine è noioso dentro il perimetro e silenzioso fuori, che è esattamente l'inversione che l'operator-approval-on-everything aveva al contrario.

[1] Shinn N., Cassano F., Berman E., Gopinath A., Narasimhan K. & Yao S. (2023), Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023, arXiv:2303.11366. [2] 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. [3] Tran D. & Kiela D. (2026), Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets, Stanford NLP, arXiv:2604.02460. [4] Wang C. & Shu Y. (2026), MetaCogAgent: Prospective Metacognition for Large Language Model Agents, arXiv:2605.17292. [5] Cemri M. et al. (2025), Why Do Multi-Agent LLM Systems Fail? (MAST), NeurIPS 2025 Datasets and Benchmarks Track, arXiv:2503.13657. [6] NousResearch (2026), hermes-agent: Open-Source Recursive Skill Iteration Pattern, GitHub. [7] Manus Authors (2025), Effective Harnesses · KV-Cache Stability Patterns for Production Agent Systems, Engineering Documentation. [8] Anthropic (2025), Effective Harnesses: Prompt Caching, Stable Prefix Design, and Token Efficiency Patterns, Engineering Documentation. [9] Madani Lab (2026), Lessons Learned · 3 Principi Primi v2.0, `12_HARNESS/operativo/lessons-learned.md` (riferimento interno). [10] Madani Lab (2026), Workspace Agentic Benchmark · WSB-11 Verbal Reinforcement Learning, WSB-11. [11] Madani Lab (2026), Workspace Agentic Benchmark · WSB-17 Skill System Architecture, WSB-17. [12] Madani Lab (2026), Workspace Agentic Benchmark · WSB-18 Memory 5-Tier Architecture, WSB-18. [13] Madani Lab (2026), A-MAC Six-Factor Admission Control Tool · `11_TOOLS/memory-admission.py` (riferimento interno, release MIT-licensed schedulata). [14] Cognition Labs (2025), Don't Build Multi-Agents, cognition.ai blog. [15] Cover T. & Thomas J. (2006), Elements of Information Theory, 2nd ed., Wiley-Interscience (Data Processing Inequality, ch. 2).