Control tower read-only
Una control tower passiva correla eventi e anomalie per la revisione, senza diventare un secondo orchestratore o una dipendenza del lavoro.
In breve
Sezione intitolata “In breve”Una control tower read-only mostra quale lavoro è attivo, dove si è fermato e quale risultato attende revisione. La proprietà decisiva è l’assenza di un canale di comando: se cambia priorità o riavvia worker, diventa un secondo orchestratore.
append di eventi ───────┐WORKER ──────────── log strutturati ────────┼──► LETTORE ──► VISTA metadati del run ───────┘
VISTA - - - - - - - - nessun comando - - - - - - - -► WORKERIl disegno è asimmetrico: i worker emettono segnali durante il contratto di delega, il lettore li correla e il supervisore agisce soltanto dal normale canale di coordinamento.
Schema minimo degli eventi
Sezione intitolata “Schema minimo degli eventi”OpenTelemetry tratta tracce, metriche e log come segnali da correlare (Observability primer). Una tower agentica può partire da uno schema minimo, purché serva la revisione.
| Campo | Funzione | Regola di minimizzazione |
|---|---|---|
occurred_at |
ordina gli eventi e misura attese | precisione proporzionata alla diagnosi |
run_ref |
collega segnali dello stesso incarico | riferimento effimero e pseudonimo, mai credenziale |
kind |
distingue avvio, uso strumento, esito e arresto | vocabolario chiuso e documentato |
phase |
colloca l’evento nel ciclo del lavoro | nessuna trascrizione del ragionamento |
subject |
indica la famiglia di capacità coinvolta | nome funzionale, non percorso o comando completo |
outcome |
separa successo, errore, attesa e dato assente | non dedurre «successo» dall’assenza di errore |
elapsed_ms |
evidenzia blocchi e regressioni | preferire aggregati quando il dettaglio non serve |
Lo schema esclude prompt completi, output integrali e configurazioni. «Read-only» descrive il potere della torre, non la sicurezza dei dati raccolti.
Confini di autorità
Sezione intitolata “Confini di autorità”| La torre può | La torre non può |
|---|---|
| correlare eventi provenienti da più sorgenti | inviare nuovi incarichi |
| segnalare un run senza eventi recenti | interrompere o riavviare un worker |
| distinguere esito dichiarato e prova disponibile | promuovere un risultato a «verificato» |
| mostrare che una sorgente di telemetria è assente | inventare lo stato mancante |
| seguire automaticamente il lavoro più recente | cambiare priorità o perimetro del lavoro |
Nell’architettura a tre piani, l’osservazione resta una capacità laterale; worker e coordinamento conservano le proprie responsabilità.
Fail-open non significa fallire in silenzio
Sezione intitolata “Fail-open non significa fallire in silenzio”In una prima variante locale, l’hook creava il feed ma non gli inoltrava l’envelope degli eventi. La variante sostitutiva falliva per una causa diversa: l’ambiente non avviava direttamente lo script scelto. Il worker continuava perché entrambi i passaggi erano fail-open; la tower, però, era cieca.
L’avvio tramite interprete esplicito e una micro-esecuzione headless hanno infine dimostrato l’arrivo di eventi reali. La lezione è più generale:
Una pipeline di osservazione fail-open deve avere un proprio segnale di salute. Altrimenti protegge il lavoro dal blocco, ma rende indistinguibili «nessuna attività» e «osservatore guasto».
La vista distingue quindi evento presente, evento assente e sorgente non disponibile. Un pannello vuoto non è una conclusione.
Perché append locale prima di un webhook
Sezione intitolata “Perché append locale prima di un webhook”La prima versione ha preferito un flusso append-only best-effort a un webhook sincrono. Queste sono proprietà progettuali da provare, non garanzie intrinseche del file system:
- la scrittura ha un timeout breve e non attende che un listener sia vivo;
- il writer non usa lock applicativi condivisi; atomicità e interleaving degli append concorrenti vanno testati nel runtime reale;
- startup e I/O hanno un budget limitato: il fail-open evita attese senza limite, non promette latenza zero;
- rotazione, permessi e disco pieno producono un segnale di salute distinto, perché il feed può non riuscire a registrare il proprio guasto;
- gli eventi già persistiti possono essere riletti dopo un riavvio della vista.
HTTP può servire più macchine, ma introduce disponibilità, autenticazione, code e retry. È stato rimandato finché il beneficio non giustificherà queste responsabilità.
È stata scartata anche una console capace di «sbloccare» i worker: ogni azione manuale diventerebbe stato nascosto fuori dal protocollo di delega.
Cosa mostrare a chi revisiona
Sezione intitolata “Cosa mostrare a chi revisiona”Una vista utile presenta una sequenza ridotta:
- incarico ricevuto;
- fase corrente e ultima attività osservata;
- capacità invocata, esito e durata;
- deliverable dichiarato;
- prova disponibile, mancante o respinta.
La distinzione fra risultato dichiarato e prova appartiene al protocollo di delega. La torre espone un’eventuale contraddizione — per esempio stato positivo ma file assente — senza risolverla d’autorità.
Anche gli alert separano fatto e interpretazione: «nessun segnale nella finestra attesa» non equivale ancora a «worker bloccato».
Una torre passiva può esporre informazioni sensibili e suggerire che attività equivalga a progresso. Servono accesso limitato, retention breve e revisione dei campi.
Non sostituisce i test: mostra che un controllo è stato eseguito, non che osservasse la proprietà corretta. Resta necessaria una verifica indipendente.
Voci correlate
Sezione intitolata “Voci correlate”- OpenTelemetry: Observability primer, fonte primaria per il lessico dell’osservabilità e dei segnali; non prescrive una control tower agentica read-only.
- NIST AI Risk Management Framework, riferimento per supervisione, rischio e responsabilità; non definisce questo confine di autorità.
- Architettura, incidente e scelte di trasporto derivano da un’integrazione privata, ricostruita senza pubblicare percorsi, log, identificativi o configurazioni dell’ambiente originale.