Tutto parte da una constatazione brutale: Giobi è il collo di bottiglia di decine di attività che un agente AI potrebbe gestire autonomamente. Non tutte — alcune richiedono giudizio umano — ma molte sono diagnostiche, ripetitive, prevedibili. Il sito è down? Riavvia il container, verifica, notifica. Il certificato SSL scade? Segnala. Un cron è fallito? Riprova una volta. Roba che un sysadmin farebbe con gli occhi chiusi, e che un agente può fare altrettanto bene.
Il predecessore di Playbook — il sistema "Autonomous v1" — aveva provato a risolvere questo problema ed era morto di token burn. Un cron ogni cinque minuti che leggeva tutti gli issue del repository GitHub, spawnava Claude su ciascuno senza limiti di budget, e finiva per occupare 25 gigabyte di RAM con processi zombie. Quattro siti down per out-of-memory. La lezione era chiara: l'autonomia senza vincoli è un incendio.
Playbook non è un bot che "fa cose". È un contratto tra umano e agente AI. L'umano scrive le regole di ingaggio — cosa l'agente può fare, con quali limiti, in quali scenari — e l'agente opera dentro quei confini. Se l'evento non è coperto da nessuna regola, finisce nel feed degli eventi (Pulse) e basta. Nessuna iniziativa autonoma. Mai "trova qualcosa da fare".
Il vocabolario è stato costruito pezzo per pezzo durante il design, chiarendo ogni termine ambiguo prima di scrivere una riga di codice. Un play è uno scenario specifico dentro il playbook — "sito down", "errore spike", "issue GitHub con tag". Un run è l'esecuzione di un play: il processo che parte, lavora, restituisce un risultato. Un job è il concetto di piattaforma — qualsiasi processo asincrono, non solo quelli di Playbook. La distinzione è sottile ma importante: il job è l'infrastruttura, il run è il significato.
Il pezzo concettualmente più interessante è il checkpoint a gradiente. Nel dibattito sull'AI governance — dal Parlamento Europeo alle aziende tech — si parla di "human in the loop" come se fosse un interruttore: o l'umano c'è o non c'è. Playbook propone qualcosa di più sofisticato.
Un checkpoint è un punto in cui il processo si ferma o notifica prima di procedere. Ma non tutti i checkpoint sono uguali. Un checkpoint hard è bloccante: il processo si ferma e aspetta approvazione esplicita. Mandare un'email a un cliente, fare un deploy in produzione, modificare DNS — qui serve il pollice in su dell'umano. Un checkpoint soft notifica e prosegue: se l'umano non obietta entro un certo tempo, l'azione va avanti. Riavviare un container, pulire i log — roba reversibile dove il silenzio equivale al consenso.
Il terzo tipo è il più interessante: il checkpoint emergente. L'agente stesso si ferma perché riconosce di non essere sicuro. Non è nel play, non è nelle regole — è l'agente che valuta i propri limiti. E non è teoria: durante il primo test live, Haiku ha ricevuto un play "site_down" per un'entità di test inesistente. Non aveva contesto, non sapeva quale container riavviare. Si è fermato da solo, ha restituito status "paused" con la spiegazione: "rischio alto di azione sbagliata, attendo contesto". Nessuno glielo aveva detto esplicitamente. Il prompt includeva solo la frase generica "se il rischio ti sembra alto, fermati". Lui l'ha fatto.
Questo modello a tre livelli — hard, soft, emergente — è ciò che manca nel dibattito regolatorio. L'AI Act parla di "human oversight" in modo generico. Playbook lo rende operativo: l'oversight è proporzionale al rischio, dichiarato in anticipo, e verificabile a posteriori perché ogni checkpoint lascia una traccia.
Se Playbook fosse solo "l'umano scrive le regole, l'agente le esegue", sarebbe utile ma statico. Il salto concettuale è il Play Proposer: l'agente analizza gli eventi ricorrenti nel feed Pulse, identifica pattern non coperti da nessun play esistente, e propone nuovi play.
L'umano non deve pensare a tutto in anticipo. L'agente osserva che ogni martedì un certo cron fallisce e viene risolto manualmente con lo stesso comando. Dopo tre settimane, propone: "Ho notato questo pattern. Ecco un play che lo gestisce automaticamente. Vuoi attivarlo?" L'umano approva, modifica, o rifiuta. L'agente espande la propria autonomia solo con consenso esplicito.
Il cerchio si chiude: tre livelli di governance. Playbook scritti dall'umano (il contratto iniziale). Checkpoint a gradiente (oversight proporzionale al rischio). Play proposti dall'agente (espansione governata dell'autonomia). E tutto è auditabile — ogni play è un documento, ogni run ha una traccia, ogni proposta ha un esito registrato.
Un tema emerso con forza durante il design è il canale di comunicazione tra umano e agente. Discord era stato testato, un'app dedicata era stata costruita, c'era una dashboard. Troppi strumenti, troppa manutenzione. GitHub Issues funzionava già — accessibile da cellulare, con threading naturale — ma era soffocato dal rumore: alert automatici, security check, rinnovi falliti duplicati, report MainWP. Cento issue aperti, di cui solo una minoranza richiedeva attenzione umana.
La pulizia è stata drastica: 28 issue automatici chiusi in un colpo. Quelli che restano sono idee reali e task concreti. Il flusso diventa: Giobi apre un issue con un'idea o un problema e tagga @anacleto. Un webhook manda l'evento a Playbook. Il play "issue_triage" spawna Sonnet per analizzare il thread e il contesto dal brain. Sonnet commenta con una proposta strutturata. Giobi approva nel thread. Un secondo run esegue e chiude. La conversazione che normalmente avviene in chat — sincrona, effimera, dispersiva — diventa asincrona, tracciata, e recuperabile.
La sessione ha prodotto un sistema completo in una giornata: design e implementazione in un colpo.
Il Play Registry è una tabella PostgreSQL dove ogni play dichiara trigger, modello AI (Haiku per diagnosi veloce, Sonnet per ragionamento), contesto da caricare dal brain, azioni consentite, checkpoint con gradiente, e limiti rigorosi (massimo run al giorno, massimo token, timeout). Undici play registrati, di cui otto attivi.
L'Evaluator riceve un evento, calcola uno score di autonomia via Haiku su cinque criteri (reversibilità, rischio, verificabilità, chiarezza, indipendenza da giudizio umano), e matcha il play corrispondente. Se non c'è play, l'evento finisce in Pulse e basta.
Il Runner spawna il processo: un controller Laravel crea il job, lancia uno script Python in background che costruisce il contesto dal brain (progetto wiki, diary recenti), chiama claude -p col modello scelto, e aggiorna il job con risultato, durata, token usati. Tutto loggato su Pulse.
Il Checkpoint Handler non è un componente separato — è logica nel prompt. I checkpoint vengono iniettati come istruzioni esplicite per Claude: "dopo questa azione, fermati e restituisci status paused". Quando un job va in pausa, l'endpoint /playbook/resume permette di continuare portando il risultato precedente come contesto. È semplice, e funziona.
Il Job Monitor era già pronto nella piattaforma — un controller con tracking dei processi, rilevamento automatico di PID morti, polling via API. Scoperta utile che ha evitato duplicazione.
L'integrazione GitHub Issues collega un webhook a un workflow n8n che filtra per menzioni @anacleto e chiama l'Evaluator. La dashboard su one.giobi.com/playbook mostra il Play Registry e i job recenti in una vista dark coerente col resto del sistema.
Otto play attivi coprono gli scenari più frequenti: sito down, container unhealthy, disco pieno, certificato SSL in scadenza, cron fallito, spike di errori, triage issue GitHub, processing meeting da Read.ai, e rinnovo domini fallito. Tre play sono in stato "proposal" — il sistema sa che esistono ma non li esegue finché non vengono attivati.
La migrazione più significativa è stata quella del workflow Read.ai: 147 meeting processati negli ultimi 30 giorni attraverso un brain-bridge che spawnava Claude senza limiti. Ora passa per Playbook, con Sonnet come modello, checkpoint hard prima di scrivere nel brain, e budget controllato. Stessa funzione, governance radicalmente diversa.
Il Play Proposer è il pezzo mancante — il moonshot. L'agente che analizza i pattern in Pulse e propone nuovi play. Non è priorità v1: serve prima che il sistema giri per qualche settimana e accumuli dati su cui ragionare.
C'è un tema tecnico da risolvere: i processi spawnati con claude -p non hanno permessi sui tool interattivi (Bash, file system). Ogni play dovrà dichiarare esplicitamente quali tool sono consentiti — un altro livello di whitelist che rafforza il concetto di contratto.
E c'è il paper per Federica Teocchi al Parlamento Europeo. Il framework checkpoint-gradiente-proposer è esattamente il tipo di contributo concreto che manca nel dibattito sull'AI Act. Non teoria, non compliance da avvocati. Un modello operativo con codice funzionante, dati reali, e un agente che si ferma da solo quando non è sicuro. L'issue #249 aspetta.
Playbook è la risposta a una domanda semplice: come fai a fidarti di un agente AI? Non dandogli accesso illimitato — lezione imparata dalla v1, con 25 giga di RAM bruciati da processi zombie. Non tenendolo in gabbia — lezione imparata dal collo di bottiglia quotidiano. Ma negoziando un contratto esplicito, con regole scritte, checkpoint proporzionali al rischio, e la possibilità per l'agente di proporre l'espansione della propria autonomia.
L'umano resta sovrano. Ma non deve essere presente a ogni singola decisione. Solo a quelle che contano.