Agent factory: il loop che osserva, seleziona, esegue, verifica e impara

In breve. Il loop che uso nelle mie factory ha cinque fasi — osserva, seleziona, esegue, verifica, impara — e regge per un motivo solo: ogni fase ha il suo giudice, diverso da chi l'ha eseguita. Chi osserva non sceglie, chi esegue non verifica, chi impara non ricorda ma scrive test. È la tesi che ho ricavato da due factory e una manciata di episodi datati: due punti che coincidono, non un campione. Pubblicato il 5 ottobre 2026.

Perché cinque fasi e non una

Il primo loop che ho costruito aveva una fase sola: "sistema le cose". Un agente guardava il progetto al mattino, aggiustava qualcosa, scriveva che era tutto a posto. Funzionava finché gli credevo, e gli credevo sempre: era l'unica voce nel giro. Poi ho scoperto che la routine dei dati era ferma da 33 giorni sotto i suoi occhi, e ho capito che non avevo costruito un loop. Avevo costruito un monologo con un pubblico di una persona.

La storia completa è quella della fabbrica che ripara il software mentre dormiamo. Quello che mi interessa qui è il disegno che ne è uscito: spezzare il monologo in cinque fasi, e dare a ognuna un giudice esterno. La separazione è il meccanismo, non l'organizzazione del testo. Ogni fase che giudica se stessa diventa prima o poi il punto in cui il loop mente a se stesso, e mente nel formato più pericoloso: un verdetto, non un errore.

Il giro in una tabella, prima del dettaglio:

Fase	Cosa decide	Chi la giudica	Episodio che l'ha plasmata
Osserva	Cosa sta succedendo davvero	Una misura che una macchina sa leggere	33 giorni di silenzio
Seleziona	Cosa fare adesso	Una funzione deterministica	Il backlog da 21 righe
Esegui	Come farlo	Un posto di guida alla volta	Quattro riparazioni chiuse
Verifica	Se ha funzionato	Un attore fuori dalla sessione	14 verdi qui, 7 rossi lì
Impara	Cosa resta	Un test che rigioca il caso	Il secondo accento mancante

Osserva: la realtà prima delle opinioni

Osservare significa una cosa sola: registrare cosa succede senza interpretarlo. Il mio loop parte sempre da qui, e ogni sistema che ho costruito è partito da un livello che chiamo observe, dove guarda e basta. Sembra tempo perso, ed è il contrario: è l'unica fase che non può sbagliare per eccesso di prudenza, perché non tocca niente.

L'episodio che mi ha insegnato a osservarla così è il guasto silenzioso del 24 luglio: routine incastrata, nessun errore, me ne accorgo il 26 agosto. Quando ho guardato dentro, un'ora di audit su 115 file mi ha mostrato di tutto. La strategia con i numeri migliori era finta: leggeva una cache che non si aggiornava da due mesi. Nel registro ho trovato 18 giornate mai vissute, e un portafoglio da 71 titoli inchiodato a 0,00% mentre il mercato saliva. Altre due strategie non vedevano dati freschi da 78 giorni. Tutto il dettaglio è nel racconto della fabbrica: qui conta la regola che ne ho ricavato. Se un sistema non si accorge da solo di essersi fermato, chiamarlo autonomo è generoso: è incustodito.

La seconda lezione sull'osservare è arrivata dopo, ed è più sottile: osservare il fatto non basta, serve la scala del fatto. Il Governor che sorveglia i miei run ha scambiato un blocco umano globale per un'attesa locale, e il posto di guida è risultato libero dove doveva risultare occupato. I test erano verdi — 27 del Governor più una suite da 2959 — perché nessuno poneva la domanda sulla portata: vale qui o vale ovunque? L'ha trovato una peer review, con la CONCERN gov1:c5d56f63, e la correzione ha reso machine-readable lo scope del blocco. L'ho raccontata nel pezzo sul Governor che ha letto male: un'informazione senza scala scritta in un campo si capisce solo dal contesto, e il contesto lo capisce chi c'era; chi arriva dopo — quasi sempre una macchina — trova solo i campi.

Terza lezione, la più scomoda: a volte l'osservatore genera da solo il rumore che osserva. La mia sonda dei gap aveva un elenco di articoli attesi compilato a mano, con slug inventati mesi prima, e produceva arretrato ordinato per file destinati a non esistere mai con quei nomi. Me ne sono accorto solo perché i conti non quadravano con quello che vedevo. Ne parlo in Backlog Zero: il rumore fatto in casa è il più insidioso, perché ha la firma del sistema.

Seleziona: un lavoro alla volta, per regola scritta

Con la realtà registrata, il loop deve scegliere cosa fare adesso. Questa è la fase che ho sottratto per prima ai modelli linguistici: a scegliere è una funzione deterministica, che decide sempre allo stesso modo a parità di condizioni e motiva ogni scelta. La strategia resta al modello; la coda di lavoro no.

Il selettore lavora a strati: avanza solo il primo strato che ha qualcosa da proporre — misure verificate che sbloccano lavoro, segnali osservati oggi, attese di evidence scadute, e per ultima la campagna backlog. Il backlog arriva per ultimo per disegno, non per modestia: una riga vecchia di settimane pesa meno di una misura di stamattina. È gerarchia epistemica. L'ho descritta dal lato del ritmo in "Non scrivo più prompt" e dal lato delle righe in Backlog Zero, dove racconto il giorno in cui il conteggio diceva 21 e le voci eseguibili erano poche. Il resto aspettava dipendenze, audit o evidence che non avevo.

C'è una regola del selettore a cui tengo in modo particolare: se la lettura di oggi arriva malformata, la selezione si ferma invece di scivolare in silenzio sul backlog. Da un'osservazione guasta non deve nascere lavoro inventato. È lo stesso principio che governa l'escalation all'umano: la mia factory si bloccava per girare all'owner domande da decidere in autonomia — code di integrazione, meccaniche interne, strati del selettore — e ogni sosta sembrava prudenza mentre era un difetto. A chiudere il buco sono arrivate due PR del framework, prima la #294 e poi la #309, con una regola sola: la domanda all'owner scatta solo quando c'è di mezzo qualcosa che cambia per chi usa il prodotto. Per tutto il resto decide il worker, dentro i guardrail, e lo registra come fatto. L'ho raccontato nei falsi gate owner, con la riga di diario che lo prova: una voce uscita dal blocco umano senza che nessun owner rispondesse.

Esegui: un confine, un posto di guida

L'esecuzione ha una regola sola, e la fa rispettare il registro, non il prompt: mentre un intervento è in volo su un punto, quel punto non ne accetta altri. Un confine causale alla volta. Scritta nel prompt, una regola dura quanto la memoria del modello; scritta nel registro, dura sempre.

Il giro completo — osserva, seleziona, esegue, verifica, registra — ha portato a termine quattro riparazioni su un progetto vero, le PR numero 4, 5, 6 e 7, dal primo all'ultimo passaggio senza un mio intervento. Quattro chiusure con la ricevuta di ogni passaggio: la sera in cui il primo giro si è chiuso, ho guardato i receipt e mi sono sembrati burocrazia. Poi ho contato. La storia è quella della fabbrica, e il numero resta piccolo di proposito: prova che il giro esiste e funziona, non fin dove regge.

Sull'esecuzione ho imparato anche la seconda metà del mestiere, quella che riguarda chi esegue quando gli esecutori sono tanti. In Arvo, l'app di coaching dove lavorano i miei agenti, i primi specialistici li ho messi a lavorare fianco a fianco: uno calcola la progressione, uno sceglie gli esercizi, uno genera gli allenamenti. Nel mio caso il passaggio si è fatto sentire tra tre e quattro agenti: code che si aspettavano a vicenda, lo stesso lavoro fatto due volte, con me in mezzo a smistare a mano. La risposta non è stata un agente più bravo, è stata un'organizzazione piccola: ruoli con input e output chiari, passaggi di consegne formali, un modello piccolo sotto (GPT-5-mini). Quando ho dovuto cambiare il criterio di scelta di un esercizio, ho ridisegnato un passaggio invece di riscrivere un agente. L'ho raccontato in "Ho smesso di costruire agenti": i ruoli sopravvivono, il motore si cambia.

Verifica: il verde vale solo dove verifica chi verifica

Questa è la fase che tiene su tutto il resto, e la regola sta in una riga: il verdetto su un lavoro arriva da fuori dalla sessione di chi l'ha fatto, sul codice davvero rilasciato. Chi esegue non certifica. Non è sfiducia, è la stessa separazione che in azienda tiene distinto chi spende da chi approva il budget. Il principio completo, con gli altri tre controlli che ho disegnato invece di togliere, è in "Autonomia non nasce eliminando il controllo".

L'episodio che mi ha insegnato a prenderla sul serio è quello dei test verdi bocciati: una suite da 14 passati su 14 in locale, eseguita nell'ambiente del verifier, ha dato 7 PASS contro 7 FAIL. Stesso codice, stessi test: a cambiare verdetto è stato solo l'ambiente. La colpa non era dei test fragili ma dell'ambiente implicito: directory di lavoro presa come default, revisione caricata mai riletta, criteri legati a componenti mai dichiarati. La correzione, descritta nel corpo della PR #323, ha attaccato ogni criterio ai componenti che lo misurano, e dopo la cura la suite passa con 3.216 verdi in entrambi gli ambienti. L'ho raccontato nel pezzo sul verifier che boccia: senza l'ambiente dichiarato, la prova resta un racconto.

Il gemello di quel caso riguarda l'orologio invece dell'ambiente. Il supervisore dei miei run calcolava il budget partendo dal createdAt dichiarato dall'agente stesso: l'ora la scriveva chi il budget avrebbe dovuto limitare. Con la PR #339 a dettare il budget è il recordedAt osservato dal kernel, e vale su entrambi i backend, dichiarando il fallback legacy dove l'osservazione è impossibile. La regola che ne ho ricavato, e che ora applico a ogni misura che governa qualcosa, è: nessun controllo deve poggiare su dati che il controllato può modificare. L'ho raccontata nel pezzo sull'orologio dell'agente, tenendo separati i fatti dalla PR e l'interpretazione mia.

Impara: dagli errori restano test, non ricordi

L'ultima fase è quella che rende ogni giro diverso dal precedente: convertire i fallimenti in regole durevoli con il loro test di regressione. Nel documento che governa il progetto, le regole 17–26 nascono tutte così: ognuna da un difetto visto davvero in esecuzione, ognuna col suo test. Non piovono dal cielo: ognuna è una cicatrice col suo referto.

Il meccanismo ha una soglia scritta in anticipo: quando lo stesso difetto si presenta due volte, scatta un gate generale. L'esempio più fresco è quasi imbarazzante nella sua piccolezza: prima un "così" senza accento, poi un "più" senza accento. L'ortografia non era coperta da nessun gate, così al secondo caso ne è nato uno deterministico, con i suoi test. E la regola che tengo più stretta è il rovescio della soglia: da una sola osservazione debole non nasce nessuna regola durevole. Senza, le coincidenze diventerebbero leggi, e il loop imparerebbe a inseguire il rumore. Ho raccontato entrambi i meccanismi nei marginal gains delle macchine: per le macchine, il guadagno composto è accumulo di invarianti, non somma di micro-vittorie.

Tengo separate le due scritture: da una parte cosa è successo, dall'altra cosa abbiamo imparato. Le strade escluse contano quanto le cause confermate: sapere cosa non funziona è metà del patrimonio. È il pezzo del loop che ho descritto dal lato del ritmo: ogni giro ben fatto lascia stato durevole, e il successivo parte da più in alto.

Dove finisce quello che ho visto

Parlo per una persona e due factory: la tesi dei cinque giudici è interpretazione mia, non un risultato misurato, e la marco come tale perché è onesto farlo. Non ho prove che il disegno tenga a scale organizzative che non ho visto, e non lo sostengo. Finora il mio loop ha riparato guasti nel codice, senza prendere decisioni di prodotto: tra "riparare da solo" e "decidere da solo" c'è un altro confine, con regole diverse, che non ho attraversato.

Il resto del quadro — cosa significa costruire l'azienda intorno a questi loop, con i limiti di quello che so — è in Building the Autonomous Company. Questa pagina è la sezione operativa: le cinque fasi, i giudici, gli episodi. Se parti da zero, comincia da observe e da una misura: sette giorni di osservazione registrata insegnano sul tuo lavoro più di qualsiasi corso.

Domande frequenti

Qual è la prima fase da costruire?

Observe, sempre. Un sistema che guarda e registra senza toccare niente non può rompere nulla e produce il diario da cui disegni tutto il resto. La misura che una macchina sa leggere viene subito dopo: senza, le altre quattro fasi girano sul vuoto.

Perché il selettore non può essere un modello linguistico?

Può, ma allora l'ordine di lavoro cambia con l'umore del modello e nessuno sa dire perché oggi si fa prima una cosa e domani un'altra. Una regola scritta decide sempre allo stesso modo a parità di condizioni, e la scelta si può rileggere. Le decisioni strategiche restano al modello; la coda no.

Il loop decide anche cosa fare, o solo come farlo?

Nel mio caso solo come farlo, e nemmeno tutto: gli esiti che contano li decido io, il sistema parcheggia esplicitamente i casi che non può risolvere e io giudico quelli. La linea tra "ripara da solo" e "decide da solo" è il confine che non ho attraversato, ed è dichiarato come tale.

Cosa distingue observe da closed loop?

Quante fasi girano senza intervento. In observe il loop guarda e basta; sale di un livello alla volta — selezione, esecuzione, verifica — e ogni livello va meritato con misure leggibili da una macchina. Partire dall'autonomia totale e aggiungere controlli dopo il primo incidente è la sequenza che vedo sbagliare più spesso.