Agent loop, monitoring, escalation, human-in-the-loop

Un agente AI moderno è, meccanicamente, un anello di feedback: un LLM che osserva, decide, agisce e ripercepisce. Gli undici capitoli precedenti di questa Parte sono la cassetta degli attrezzi per progettarlo — e questo capitolo la apre e la consegna.

Perché questo capitolo

Un agente che gira in un harness fa una cosa sola, ripetuta. Legge il suo contesto e l’esito dell’ultima azione. Decide cosa fare. Chiama uno strumento. Il risultato torna nel contesto. Ricomincia.

Questo disegno — due frecce, un anello chiuso, una che porta l’azione e una che riporta il risultato — non è nuovo. È lo stesso disegno che Norbert Wiener (matematico statunitense del MIT, 1894-1964) mette al centro della cibernetica nel 1948, e che i primi capitoli di questa Parte hanno smontato pezzo per pezzo: errore, setpoint, guadagno, ritardo, varietà, omeostasi, black box.

La tesi di questo capitolo è che quella coincidenza non è un aneddoto, ma una risorsa. La cibernetica è la cornice concettuale più adatta che abbiamo per pensare gli agenti AI moderni — un modello linguistico messo in loop con strumenti, memoria, un ambiente e un utente. Non perché la cibernetica preveda gli LLM: è nata trent’anni prima e non sapeva nulla di reti neurali profonde.

La ragione è un’altra. La cibernetica ha passato decenni a studiare la classe di oggetti a cui l’agente appartiene: i sistemi che agiscono nel tempo, percependo l’effetto delle proprie azioni e correggendosi. Chi costruisce agenti oggi si trova davanti problemi — agenti che oscillano, che divergono, che ottimizzano la cosa sbagliata, che vanno supervisionati senza poterli supervisionare sempre — che hanno già un nome e un vocabolario maturo. Riconoscere quel vocabolario significa poter importare strumenti collaudati invece di reinventarli, peggio, sotto altri nomi.

Va detto subito, con la massima chiarezza, di che natura sarà questo capitolo. Non offre teoremi sugli LLM. Nessuno ha dimostrato un teorema di stabilità per un agente basato su un modello linguistico, e questo capitolo non fingerà il contrario. Quello che offre è una cornice: un linguaggio per fare le domande giuste e un insieme di principi di progetto.

La gran parte di quello che segue sono analogie strutturali dichiarate come tali e regole euristiche utili — non leggi. L’unico teorema vero che incontreremo, il good regulator theorem, è un teorema su sistemi formali astratti, e la sua applicazione agli agenti sarà marcata come analogia ispiratrice, non come prova. Tenere ferma questa onestà è parte del lavoro: una cornice spacciata per teorema fa più danni di nessuna cornice.

Questo è l’ultimo capitolo della Parte X, ed è pensato come il “cosa portarsi a casa”. Il capitolo che lo precede, Da feedback e controllo a MDP, Bellman, RL, è un ponte genealogico: ricostruisce chi discende da chi, dalla cibernetica al controllo ottimo al reinforcement learning. Questo è un ponte di design. L’oggetto non è una linea di discendenza storica, ma un artefatto da costruire — l’agente — e i concetti cibernetici visti come strumenti per progettarlo e per ragionarci sopra. Dove quel capitolo guarda al passato, questo guarda al banco di lavoro.

Contesto

Conviene fissare due punti prima di procedere, perché senza di essi il resto del capitolo rischia un cortocircuito.

Il primo punto è una distinzione di loop. In questa Parte e nella Parte VII compaiono due anelli di feedback diversi, su scale di tempo diverse, ed è facile confonderli. C’è il loop di addestramento: durante RLHF — la tecnica con cui si allinea un modello linguistico al feedback umano — un segnale di ricompensa modifica i pesi del modello. Quel loop è l’oggetto del capitolo precedente. E poi c’è il loop di runtime: a pesi ormai congelati, l’agente in esecuzione osserva, decide, agisce, ripercepisce. Quel secondo loop, e solo quello, è l’oggetto di questo capitolo. Quando qui si parla di “il loop dell’agente” si intende sempre il loop di runtime, il giro che l’agente compie mentre lavora su un compito, non il giro che lo ha addestrato.

Il secondo punto è una definizione operativa di agente. La useremo per tutto il capitolo, e conviene prenderla da chi gli agenti li costruisce. Anthropic, nel documento tecnico Building effective agents (Anthropic engineering blog, dicembre 2024), parte da un mattone che chiama augmented LLM: un modello linguistico potenziato con tre capacità — retrieval (sa cercare informazione), tool use (sa compiere azioni) e memoria (sa decidere cosa trattenere).

Su questo mattone Anthropic costruisce una distinzione netta. Un workflow è un sistema in cui modello e strumenti sono orchestrati da percorsi di codice predefiniti: la sequenza dei passi è decisa da chi scrive il programma. Un agente è un sistema in cui il modello dirige dinamicamente i propri processi e l’uso degli strumenti, mantenendo il controllo del percorso: la sequenza dei passi emerge mentre il compito procede.

La frase con cui Anthropic riassume cosa sia un agente autonomo è, per i nostri scopi, perfetta: “typically just LLMs using tools based on environmental feedback in a loop” — in italiano, semplicemente modelli che usano strumenti basandosi sul feedback dell’ambiente, in un anello.

Quella frase, letta da chi ha attraversato i capitoli di questa Parte, suona come una definizione cibernetica. “Strumenti” sono attuatori. “Feedback dell’ambiente” è retroazione. “In un loop” è l’anello chiuso. Il resto del capitolo non fa che svolgere, una alla volta, le conseguenze di questa lettura.

Il grafo dei collegamenti di questo capitolo è largo, perché il capitolo è un punto di raccolta. Verso l’interno della Parte X, richiama quasi tutti i capitoli che lo precedono: l’anello e il setpoint da Wiener: comunicazione e controllo in animali e macchine e Anatomia di un anello: errore, setpoint, guadagno, ritardo; le patologie del loop da Overshoot, ritardo, oscillazioni, divergenza; l’omeostasi e l’ultrastabilità da Ashby, omeostato e adattamento; la varietà da La legge della varietà necessaria.

Continua: l’opacità da Black box, input-output, identificazione del sistema; l’osservatore da Von Foerster: l’osservatore dentro il sistema; l’autonomia da Autopoiesi: i sistemi che si fanno da sé; la struttura multi-agente da Stafford Beer e il Viable System Model. Verso l’esterno, getta i fili verso le Parti applicative su agenti, harness e safety, che useranno questo vocabolario dandolo per acquisito. È, in questo senso, un capitolo a doppia faccia: chiude la Parte X raccogliendone gli strumenti, e apre le Parti che verranno consegnando loro un lessico.

L’intuizione

Prima di qualunque formalismo, guardiamo l’idea da due angoli distinti. Il primo è operativo: cosa fa, gesto per gesto, un agente al lavoro, e perché quel gesto è un anello. Il secondo è diagnostico: cosa cambia, nel modo di guardare un agente che fallisce, quando lo si guarda con gli occhi della cibernetica invece che con quelli del prompt engineering.

Primo angolo: il gesto dell’agente è un anello

Mettiti davanti a un agente di coding mentre lavora. Gli hai dato un compito: far passare una suite di test che oggi fallisce. Cosa fa, concretamente. Quattro gesti, ripetuti.

Per prima cosa legge. Apre i file di test, legge i messaggi di errore dell’ultima esecuzione, guarda il codice intorno. Sta acquisendo lo stato del mondo in cui deve agire. Nel lessico cibernetico questo è il sensore: l’organo che misura la variabile di interesse. La variabile, qui, è qualcosa come “quanto siamo lontani dal compito finito”.

Poi valuta. Confronta quello che ha letto con quello che dovrebbe essere: i test passano o no? Quale comportamento manca? Questo confronto tra lo stato osservato e lo stato desiderato è, esattamente, il comparatore dell’anello cibernetico. La differenza che ne esce — la lista delle cose che ancora non vanno — è il segnale di errore.

Poi decide e agisce. Sulla base di quell’errore sceglie una mossa: modificare una funzione, aggiungere un controllo, riscrivere un blocco. Decidere la mossa è il ruolo del regolatore; eseguirla — la chiamata allo strumento che scrive il file — è il ruolo dell’attuatore. L’azione cambia il sistema controllato: il repository, il filesystem.

Infine ripercepisce. Rilancia i test, rilegge l’output. Il risultato dell’azione torna nel contesto come nuova osservazione, e l’anello si chiude. Gira finché i test passano, oppure finché scatta un limite — un tetto di iterazioni, un budget esaurito, un punto in cui l’agente si ferma a chiedere aiuto.

Questa è la prima intuizione, e va presa alla lettera: non c’è nessun pezzo del comportamento di un agente che cada fuori da questo anello. Pensare, pianificare, chiamare strumenti, leggere risultati — tutto sta dentro il giro osserva-valuta-agisci-ripercepisci. Un agente, meccanicamente, è un anello di feedback che gira.

C’è un mnemonico militare che a volte si usa per questo giro, l’OODA loop — Observe, Orient, Decide, Act — formulato dallo stratega dell’aeronautica statunitense John Boyd negli anni Settanta. È un prestito utile e nient’altro: va citato come mnemonico esterno, non come fonte cibernetica. Il lessico che useremo qui resta quello della Parte X — percezione, confronto con un riferimento, azione correttiva, retroazione — perché è quello che ci dà, gratis, tutti i capitoli che lo hanno già spiegato.

Secondo angolo: la diagnosi cambia con la lente

Il secondo angolo si vede meglio su un agente che fallisce, perché è lì che la cornice fa una differenza pratica.

Un agente sta lavorando male. Modifica un file, poi lo rimodifica, poi torna sui suoi passi; consuma iterazioni senza avvicinarsi al risultato. Davanti a questa scena, la lente più comune è quella del prompt: “il modello non è abbastanza bravo”, “il prompt va riscritto meglio”, “serve un modello più grande”. È una lente che porta a un solo tipo di azione — toccare il prompt o cambiare modello — e che spesso non spiega nulla.

La lente cibernetica guarda la stessa scena e fa domande diverse, una per ciascun ruolo dell’anello.

Il setpoint è chiaro? L’agente sa, in modo verificabile, quando il compito è finito, o sta inseguendo un bersaglio definito a parole in modo ambiguo? Il sensore funziona? L’agente riceve davvero il risultato di ogni sua azione prima di decidere la successiva, o agisce alla cieca? Il guadagno è tarato? A un errore piccolo l’agente risponde con una correzione piccola, o con una riscrittura massiccia che genera un errore opposto? C’è un ritardo nel ramo di feedback — un test così lento che l’agente agisce di nuovo prima di aver visto l’effetto della mossa precedente? L’agente ha un modello dell’ambiente sufficiente, o sta operando senza sapere com’è fatto il sistema su cui agisce?

Ognuna di queste domande è una diversa ipotesi di guasto, e ognuna porta a una correzione concreta che non c’entra nulla con “il modello è scarso”: esplicitare un criterio di “done” verificabile, dare feedback più veloce, chiedere modifiche più piccole, inserire un passo di verifica, arricchire il contesto. La cornice cibernetica trasforma un giudizio generico — “non funziona” — in una lista di ipotesi azionabili. Questa è la seconda intuizione, ed è la ragione pratica per cui la Parte X non è archeologia: è una checklist di debugging.

Terzo angolo: il livello che governa il livello

C’è un terzo modo di guardare la cosa, e riguarda non un singolo agente ma il sistema che lo contiene. Un agente che gira da solo è un anello. Un agente messo in produzione non gira mai davvero da solo: attorno a lui c’è un altro anello, più lento e più largo, che lo osserva.

Quel secondo anello è il monitoring. Mentre l’agente compie il suo giro stretto — osserva, decide, agisce — qualcuno o qualcosa osserva il giro stesso: conta le iterazioni, misura il budget consumato, controlla che l’agente non sia uscito dai binari, decide se lasciarlo proseguire, fermarlo o passare la mano a un umano. Questo è un anello di feedback che ha per “variabile controllata” il comportamento di un altro anello di feedback.

La cibernetica ha un nome per questa struttura: regolazione a più livelli, o anelli annidati. Il capitolo Stafford Beer e il Viable System Model la incontra come ricorsione — un sistema viabile contenuto dentro un sistema viabile. Il capitolo Ashby, omeostato e adattamento la incontra come distinzione tra il loop che corregge dentro una strategia e il loop che cambia strategia.

Vista così, l’architettura di un agente in produzione non è “un agente”; sono almeno due anelli incastrati: il loop operativo che fa il lavoro, e il loop di supervisione che governa il loop operativo. Tenere distinti i due livelli — sapere a quale dei due appartiene un certo componente — è il terzo angolo, e sarà il filo della sezione su monitoring ed escalation. Una buona parte degli errori di progettazione di un agente nasce dal collassare i due livelli in uno: dal chiedere al loop operativo di sorvegliarsi da solo, che è come chiedere a un termostato di accorgersi di essere rotto.

La meccanica

Mettiamo ora sotto la lente i ruoli dell’anello, uno alla volta, e poi i modi in cui l’anello si guasta. Useremo come scheletro un pseudocodice del loop agentico minimo, perché è il modo più rapido per vedere dove ciascun concetto cibernetico si incastra.

Lo scheletro del loop

stato = osserva_iniziale()        # sensore: contesto, task, ambiente
modello_ambiente = costruisci_modello(stato)
storia = []

while True:
    errore = valuta(stato, obiettivo)   # comparatore: distanza dal setpoint
    if criterio_di_stop(errore, storia):
        break                            # done, oppure budget/iterazioni esauriti
    azione = decidi(stato, errore, modello_ambiente)  # regolatore (l'LLM)
    if azione.rischiosa:
        attendi_approvazione_umana(azione)  # osservatore nel loop
    risultato = esegui(azione)           # attuatore: tool call
    stato = osserva(risultato)           # ripercezione: ground truth
    modello_ambiente = aggiorna(modello_ambiente, risultato)
    storia.append((azione, risultato))

Riga per riga, questo è un anello di feedback. osserva è il sensore. valuta è il comparatore, e produce errore — lo scarto tra dove siamo e dove dovremmo essere. criterio_di_stop è l’anti-divergenza, di cui diremo tra poco. decidi è il regolatore: nel caso dell’agente, è una chiamata all’LLM. esegui è l’attuatore, la chiamata allo strumento.

La riga stato = osserva(risultato) chiude l’anello: il risultato dell’azione rientra come nuova osservazione. La riga dell’approvazione umana è l’osservatore incluso nel loop, e torneremo su cosa significhi davvero. Nessuna di queste righe è decorativa: togline una, e l’anello smette di essere un anello.

Una differenza con il termostato del capitolo Anatomia di un anello: errore, setpoint, guadagno, ritardo va fissata subito, perché è la differenza che spiega quasi tutte le altre. Nel termostato, comparatore e regolatore sono hardware fisso e deterministico, lo stato è un numero (la temperatura), l’errore è un numero, l’azione è un numero. Nell’agente, valuta e decidi sono lo stesso LLM, lo stato è una descrizione in linguaggio naturale, l’errore è una lista di cose che non vanno scritta a parole, e l’azione è testo — il nome di uno strumento e i suoi argomenti.

La topologia dell’anello è identica; la natura dei nodi no. Questo è il motivo per cui, in tutto il capitolo, “l’agente è un sistema cibernetico” è un’analogia strutturale e non un’equivalenza: la forma del loop coincide, la sostanza dei suoi componenti no. L’LLM-regolatore non ha una legge di controllo esplicita e non porta garanzie di stabilità; è una scatola addestrata, non un controllore progettato.

Il sensore: ground truth a ogni passo

Prima del setpoint conviene fermarsi sul sensore, perché un anello con un sensore difettoso non si salva con nessun altro accorgimento.

Anthropic, nel documento citato, insiste su un punto preciso: è cruciale che l’agente ottenga “ground truth” dall’ambiente a ogni step — il risultato reale di una tool call, l’output reale di un’esecuzione di codice — per valutare i propri progressi.

In termini cibernetici, questo è un requisito sul sensore: la retroazione deve riportare lo stato vero del sistema controllato, non una stima o una congettura dell’agente. È la condizione perché l’anello sia chiuso davvero.

È un punto meno ovvio di quanto sembri. Un agente, essendo un modello generativo, può “immaginare” l’esito di un’azione invece di osservarlo: può proseguire come se la modifica fosse andata a buon fine senza aver letto l’output. Quando lo fa, l’anello è formalmente aperto — c’è un’azione, ma non c’è retroazione — e un anello aperto non corregge nulla.

La regola di design che ne segue è semplice: ogni azione dell’agente deve essere seguita da un’osservazione reale del suo effetto, prima della decisione successiva. Il sensore non è un dettaglio dell’harness; è ciò che distingue un anello chiuso da una sequenza di mosse alla cieca.

Il setpoint, e perché è quasi sempre il problema

Un regolatore senza setpoint non regola niente: il setpoint è il valore di riferimento rispetto a cui si misura l’errore. Per l’agente, il setpoint è l’obiettivo del compito — la specifica di cosa significa “fatto”.

Qui c’è una asimmetria che vale la pena guardare in faccia. Il setpoint di un termostato è un numero: 20 gradi sono 20 gradi, e l’errore è definito senza ambiguità. Il setpoint di un agente arriva, quasi sempre, in linguaggio naturale: “sistema il bug”, “migliora questa funzione”, “scrivi i test”.

Una frase del genere è quasi sempre sottospecificata. “Sistema il bug” non dice quale comportamento è accettabile, quali test devono passare, cosa non si deve toccare, quale livello di rischio è ammesso. Il comparatore dell’agente sta dunque misurando lo scarto rispetto a un riferimento sfocato.

La conseguenza è sottile e importante. Un agente con un setpoint mal specificato non sbaglia il controllo: può benissimo essere un ottimo regolatore. Sbaglia il bersaglio. Converge in modo efficiente verso la cosa sbagliata.

Questa è la versione agentica di un problema che la wiki incontra altrove sotto il nome di reward hacking e specification gaming (la classe di guasti in cui un sistema ottimizza alla lettera un obiettivo mal posto; trattata nella Parte XVI, in preparazione), ed è parente del problema principal-agent discusso in Alignment come problema principal-agent: chi delega — il principal — non riesce a specificare l’obiettivo così bene da escludere ogni scorciatoia indesiderata da parte di chi esegue.

La lezione di design è netta e va contro un’intuizione comune. Una buona parte del lavoro di chi costruisce agenti non è migliorare il regolatore — il modello — ma definire bene il setpoint: criteri di accettazione verificabili, una suite di test che funga da definizione operativa di “done”, esempi negativi che dicano cosa non fare. Un setpoint vago è un guasto del loop tanto quanto un sensore rotto, e non si compensa con un modello più capace.

L’anti-divergenza: perché serve un criterio di stop

La riga criterio_di_stop non è un dettaglio implementativo: è un componente di sicurezza dell’anello. Anthropic, nel documento citato, raccomanda esplicitamente “stopping conditions (such as a maximum number of iterations) to maintain control” — condizioni di arresto, come un tetto di iterazioni, per mantenere il controllo.

Letto con la lente di questa Parte, un tetto di iterazioni è un anti-divergenza. Un anello di feedback può non convergere: il capitolo Overshoot, ritardo, oscillazioni, divergenza mostra come un loop possa oscillare senza fine o allontanarsi sempre più dal bersaglio. Un agente che gira non ha, di per sé, nessuna garanzia di fermarsi: può entrare in un ciclo, può continuare a “correggere” all’infinito.

Il criterio di stop è il vincolo esterno che limita l’orizzonte del loop e ne impedisce la corsa indefinita. Non rende l’anello stabile — non trasforma un loop divergente in uno convergente — ma ne limita il danno: è una rete, non una cura. Conviene tenere la distinzione netta, perché confondere “il loop non diverge più” con “il loop converge” è un errore comune: il tetto ferma la corsa, non garantisce che il compito sia stato risolto.

Le patologie del loop

Con lo scheletro in mano, le patologie tipiche di un agente diventano leggibili come patologie classiche di un anello di feedback. Il capitolo Overshoot, ritardo, oscillazioni, divergenza le ha già descritte in astratto; qui le riconosciamo nel comportamento concreto di un agente.

“Corregge troppo”: guadagno alto. Il guadagno è quanto un anello risponde a un errore dato. Un agente con guadagno alto vede un errore piccolo — un test che fallisce per un dettaglio — e risponde con una modifica massiccia: riscrive un intero file per un typo. La modifica massiccia introduce un errore opposto, a cui l’agente reagisce con un’altra modifica massiccia. L’anello non si assesta perché ogni correzione è sproporzionata allo scarto.

Oscillazione: il flip-flop. L’agente cambia A in B; un test fallisce; torna da B ad A; un altro test fallisce; torna da A a B. È il ciclo limite classico di un loop instabile: due stati che si rincorrono senza che l’errore complessivo scenda. Spesso nasce da setpoint in conflitto — due test che non possono essere soddisfatti dalla stessa modifica ingenua — che l’agente non riconosce come tali.

Loop: il ciclo a costo crescente. L’agente ripete la stessa sequenza di azioni — stessa lettura, stessa modifica, stesso comando — senza avanzare. È il caso degenere dell’oscillazione: non due stati che si alternano, ma una traiettoria che non si muove affatto, mentre il budget di token si consuma.

Ritardo nel ramo di feedback. L’effetto di un’azione non sempre è visibile subito: un test lento, un build, un deploy, un side effect che emerge solo più tardi. Il capitolo Overshoot, ritardo, oscillazioni, divergenza spiega che il ritardo tra azione e percezione del suo effetto è una causa classica di instabilità: il regolatore agisce di nuovo prima di aver visto il risultato della mossa precedente, e quindi corregge sulla base di informazione vecchia.

I rimedi sono cibernetici, e hanno un nome ciascuno. Abbassare il guadagno: chiedere all’agente modifiche piccole e incrementali, diff minimi, un cambiamento per volta. Ridurre il ritardo: dare feedback veloce — test rapidi, linter e type-check eseguiti subito invece che a fine lavoro. Introdurre smorzamento: inserire un passo di verifica esplicito tra un’azione e la successiva, così che l’agente non incateni mosse senza guardarne l’effetto. Limitare l’orizzonte: il tetto di iterazioni di cui sopra.

Nessuno di questi rimedi è una scoperta del 2024; sono il repertorio di chi progetta anelli di feedback da settant’anni. Il valore della cornice cibernetica, qui, non è inventare la soluzione ma riconoscere il problema: una volta che un comportamento dell’agente porta un nome — overshoot, oscillazione, ritardo — il rimedio appropriato è già scritto nel capitolo della Parte X che quel nome lo ha introdotto.

Il good regulator theorem, e cosa dice davvero

Arriviamo all’unico teorema vero del capitolo, e va maneggiato con cura. Nel 1970 Roger Conant e W. Ross Ashby (Ashby, psichiatra e cibernetico britannico, 1903-1972, già incontrato per l’omeostato) pubblicano sull’International Journal of Systems Science un articolo dal titolo Every good regulator of a system must be a model of that system — ogni buon regolatore di un sistema deve essere un modello di quel sistema. L’idea ha avuto fortuna: in teoria del controllo è stata ripresa con il nome di internal model principle (Francis e Wonham, 1976), secondo cui un controllore efficace deve contenere al proprio interno un modello del sistema controllato.

Prima di applicarlo, l’onestà storiografica impone una precisazione, perché il titolo dell’articolo è più forte di quello che la dimostrazione stabilisce. Il teorema mostra che ogni regolatore che sia, insieme, ottimale e massimamente semplice si comporta come immagine del sistema regolato sotto un omomorfismo — una mappa che può perdere informazione, non un isomorfismo.

E sono stati sollevati dubbi sul fatto che la dimostrazione formale sostenga davvero la formulazione del titolo: quello che si dimostra è, più modestamente, che alcuni buoni regolatori — quelli non inutilmente complessi — sono modelli del sistema, non che ogni buon regolatore lo sia. Quindi: il teorema è un teorema, su sistemi formali astratti. La sua applicazione agli agenti non è un teorema — è un’analogia di design, un principio ispiratore, e va dichiarata così.

Detto questo, l’analogia è feconda. Letta come principio di progetto, dice una cosa che chi costruisce agenti farebbe bene a tenere in vista: un agente che agisce bene in un ambiente ha bisogno, da qualche parte, di un buon modello di quell’ambiente. Non può regolare bene quello che non rappresenta.

In un agente moderno, quel modello dell’ambiente vive in tre forme, e conviene saperle distinguere — perché le tre forme si curano con strumenti diversi.

Vive nei pesi: la conoscenza del mondo che il modello ha assorbito in pretraining. È un modello generico, vasto ma non specifico dell’ambiente concreto in cui l’agente sta operando ora.

Vive nel contesto: un file di istruzioni come CLAUDE.md, una mappa del repository, lo schema degli strumenti disponibili, la memoria della sessione — tutto quello che dice all’agente com’è fatto l’ambiente in cui si muove. Questo è il modello che il progettista può scrivere e curare.

E vive nel modello costruito a runtime: quando un agente, prima di agire, esplora — legge file, lancia comandi diagnostici, ispeziona — si sta costruendo sul momento un modello dell’ambiente. Un agente che esplora prima di agire sta facendo, in termini cibernetici, identificazione del sistema: la stessa cosa di cui parla il capitolo Black box, input-output, identificazione del sistema, applicata dall’agente a se stesso e al proprio ambiente.

La lezione operativa segue diretta: una buona parte del context engineering e dell’harness design è, esattamente, procurare all’agente un buon modello dell’ambiente. Se quel modello è povero — contesto scarno, nessuna mappa del sistema, strumenti mal descritti — nessun regolatore, per quanto capace, regola bene. Il good regulator theorem, usato come slogan di progetto e non come dimostrazione, dice che la qualità del modello dell’ambiente è un fattore di prim’ordine, non un dettaglio.

Monitoring ed escalation: l’anello che governa l’anello

Riprendiamo il terzo angolo dell’intuizione e mettiamolo a fuoco, perché è la parte del capitolo che il titolo annuncia con le parole “monitoring, escalation, human-in-the-loop”.

Il loop operativo dell’agente — lo scheletro di pseudocodice di prima — fa il lavoro. Ma da solo non basta a un sistema messo in produzione, per la stessa ragione per cui un termostato non basta a una centrale termica: serve qualcuno che sorvegli il termostato.

Quel qualcuno è il loop di supervisione, un secondo anello di feedback la cui variabile controllata non è il compito, ma il comportamento del loop operativo. Ha la stessa anatomia di qualunque anello — sensore, comparatore, attuatore — ma applicata a un oggetto diverso: non il filesystem o il repository, bensì l’agente che li sta modificando. Vale la pena percorrere i suoi ruoli uno per uno.

Il sensore del loop di supervisione è il monitoring: la raccolta, mentre l’agente lavora, di segnali sul suo stato — numero di iterazioni compiute, token e denaro consumati, frequenza degli errori dei tool, ripetizione di azioni, tempo trascorso, comparsa di azioni rischiose.

Ognuno di questi segnali è la misura di una variabile essenziale del sistema, nel senso di Ashby: una grandezza che deve restare entro limiti. Il monitoring è il sensore che dice al loop di supervisione dove sono quelle variabili. Senza monitoring il loop di supervisione è cieco, esattamente come il loop operativo è cieco senza ground truth: in entrambi i casi è un anello senza sensore, cioè un anello aperto.

Il comparatore del loop di supervisione confronta quei segnali con delle soglie. Iterazioni sopra il tetto. Budget oltre il limite. Tre errori di tool consecutivi. Un’azione che tocca un’area protetta.

Quando una soglia viene superata, il comparatore produce un errore — non l’errore del compito, ma l’errore del processo: “questo loop non sta andando come dovrebbe”. È una distinzione che vale la pena tenere ferma: il loop operativo misura quanto manca al risultato, il loop di supervisione misura se il modo in cui ci si sta arrivando è sano.

L’attuatore del loop di supervisione ha un repertorio ristretto e potente, fatto di quattro mosse. Può fermare l’agente — la stopping condition come azione di controllo, non solo come limite passivo. Può degradare — togliere all’agente uno strumento pericoloso e lasciarlo proseguire con capacità ridotte. Può far ripartire il loop operativo da un checkpoint con un contesto diverso. E può escalare: passare la decisione a un osservatore umano.

Sono quattro modi di intervenire su un altro anello senza entrarci dentro: il loop di supervisione non riscrive il codice al posto dell’agente, agisce sui bordi del loop operativo — lo ferma, lo limita, lo riavvia, o chiama qualcuno. È controllo dall’esterno di una black box, nel senso esatto del capitolo Black box, input-output, identificazione del sistema.

L’escalation merita di essere guardata da vicino, perché è il punto in cui la legge della varietà necessaria detta il design. Un agente in produzione genera una varietà di situazioni enorme; un umano che supervisiona ha varietà altissima — capisce contesti che nessuna soglia codifica — ma non scala: non può guardare ogni passo di ogni agente.

La risposta cibernetica non è “supervisione totale” né “nessuna supervisione”, ma escalation selettiva: il loop di supervisione gestisce da solo le situazioni a varietà bassa e prevedibile (un budget sforato si gestisce con una regola), e chiama l’umano solo quando la situazione ha varietà alta o posta in gioco alta — un’azione irreversibile, un’ambiguità che nessuna soglia risolve, un dominio in cui l’errore costa molto. L’escalation è, in termini di Ashby, un modo di allocare la varietà scarsa dell’osservatore umano dove serve davvero.

Il human-in-the-loop è la forma più diretta di questa idea: l’osservatore umano non sta fuori dal sistema a controllarlo da lontano, ma è inserito dentro l’anello, in un punto preciso — la riga attendi_approvazione_umana dello pseudocodice. Prima che un’azione rischiosa venga eseguita, il loop si ferma e cede il controllo. È, alla lettera, la cibernetica di secondo ordine resa architettura: l’osservatore è un nodo del sistema, non un punto di vista esterno.

E va progettato come un nodo: gli si deve dare un buon sensore (informazione sufficiente per decidere — cosa sta per succedere, perché, cosa è reversibile e cosa no) e un attuatore chiaro (approva, rifiuta, modifica). Un checkpoint umano senza abbastanza informazione non è supervisione: è una firma cieca, e una firma cieca è peggio di nessun checkpoint, perché crea l’illusione del controllo.

Il pattern dei due anelli annidati ha una conseguenza di design che vale la pena enunciare per intero. Le proprietà che il loop operativo non può garantire da sé — non divergere, non sforare, non compiere azioni irreversibili senza approvazione — non vanno cercate dentro l’agente, ma costruite nel loop di supervisione che lo contiene.

Chiedere all’LLM-regolatore di essere, da solo, anche il proprio supervisore affidabile è chiedere alla stessa black box di sorvegliare se stessa. Il monitoring, l’escalation e il human-in-the-loop esistono perché quel secondo anello deve avere componenti separati, con varietà propria, e in parte umani. È la ragione per cui la supervisione non si ottiene scrivendo un prompt migliore: un prompt agisce dentro il loop operativo, e il punto è proprio che il controllo deve venire da un livello sopra.

Esempi

Quattro esempi eterogenei, per ancorare la cornice a casi concreti: un agente singolo letto come anello, un conto sulla varietà dei guardrail, un sistema multi-agente letto col Viable System Model, e un’escalation vista da vicino.

Esempio 1: un agente di coding letto come anello

Scenario reale. Un agente in un harness riceve il compito “fai passare la suite di test”. Seguiamo un’esecuzione che va male e leggiamola con il vocabolario della Parte X.

L’agente legge i test e i messaggi di errore: sensore. Capisce che manca la gestione di un caso limite: comparatore, e l’errore è “il caso limite non è gestito”. Scrive il codice: regolatore e attuatore. Rilancia la suite: ripercezione. Fin qui l’anello gira pulito.

Poi qualcosa si guasta. La suite è lenta — trenta secondi a giro. L’agente, invece di aspettare, incatena tre modifiche prima di vedere l’esito della prima: è un ritardo nel ramo di feedback, e ora l’agente sta correggendo sulla base di uno stato vecchio.

Quando finalmente l’output arriva, un test che prima passava ora fallisce. L’agente reagisce riscrivendo l’intera funzione: guadagno alto. La riscrittura rompe un terzo test. A questo punto l’agente cambia A in B, poi B in A: oscillazione, perché due test impongono vincoli che la modifica ingenua non concilia. Dopo venti iterazioni scatta il tetto: anti-divergenza.

Il punto dell’esempio non è l’esito, ma la diagnosi. Ogni guasto ha un nome cibernetico e una correzione corrispondente: rendere il feedback più veloce o forzare un test per volta (ritardo), imporre diff minimi (guadagno), far riconoscere all’agente i setpoint in conflitto prima di agire (oscillazione).

Nessuna di queste correzioni è “usa un modello migliore”. Un modello più capace probabilmente cadrebbe negli stessi tre tranelli, perché i tranelli non sono nel regolatore: sono nella struttura del loop in cui il regolatore è inserito. È la differenza pratica tra guardare l’agente e guardare l’anello.

Esempio 2: la varietà dei guardrail, in numeri

Esempio strutturale, sulla legge della varietà necessaria del capitolo La legge della varietà necessaria. La legge di Ashby dice che solo varietà può distruggere varietà: un regolatore può contrastare un insieme di disturbi solo se ha almeno tanti stati distinti quanti ne ha quell’insieme. La varietà è il numero di stati distinti che un sistema può assumere.

Applichiamola ai guardrail di un agente. Un guardrail — una allowlist di comandi, una sandbox, un classificatore di sicurezza — è un regolatore secondario, il cui compito è assorbire la varietà dei comportamenti indesiderati dell’agente.

Supponi che lo spazio dei comandi shell distinti che l’agente può emettere e che sarebbero pericolosi sia, in ordine di grandezza, $N$ casi. Supponi che la tua allowlist ne copra esplicitamente $k$ . La frazione di varietà pericolosa non assorbita dal guardrail è $(N - k)/N$ . Se $N$ è grande — lo spazio dei comandi distruttivi è vasto — e $k$ è una manciata di pattern scritti a mano, quella frazione è vicina a 1: il regolatore-guardrail è clamorosamente sottodimensionato per la legge di Ashby.

La legge dice anche quali sono le uscite, e sono solo tre. Ridurre $N$ : restringere l’ambiente — sandbox, permessi minimi, meno strumenti — così che le mosse pericolose possibili siano meno, e ce ne sia meno varietà da assorbire (è il tema di agent-permissions, in preparazione). Aumentare $k$ verso $N$ : alzare la varietà del regolatore, per esempio con un secondo modello che fa da giudice, o con un umano — costoso, e non sempre fattibile. Oppure attenuare la varietà alla fonte: Ashby osserva che un regolatore può agire come attenuatore di varietà, impedendo che la varietà pericolosa emerga del tutto.

La conclusione che la legge impone è scomoda: non esiste una lista di regole “abbastanza lunga”. Se la varietà dei modi di fare danno eccede strutturalmente quella del guardrail, la lista non basterà mai, e l’unica mossa solida è ridurre $N$ . È una conclusione controintuitiva per chi è abituato a pensare la sicurezza come accumulo di regole, ed è uno dei contributi più nitidi che la cibernetica porta al design degli agenti: la varietà si combatte con la varietà, non con la lunghezza degli elenchi.

Esempio 3: un sistema multi-agente letto col Viable System Model

Caso multi-agente. Un orchestratore lancia tre agenti worker su parti diverse di un repository. Per leggerlo, usiamo il Viable System Model di Stafford Beer (teorico del management britannico, 1926-2002), introdotto nel capitolo Stafford Beer e il Viable System Model. Il VSM dice che un sistema viabile ha cinque funzioni: S1 le operazioni, S2 il coordinamento che evita conflitti tra le operazioni, S3 il controllo interno che alloca le risorse, S4 l’intelligence rivolta all’ambiente e al futuro, S5 la policy e l’identità.

Mappiamo. I tre worker sono S1. L’orchestratore che assegna i compiti e gestisce il budget è S3. La parte che legge i requisiti e lo stato del repo e pianifica è S4. Le regole di sicurezza non negoziabili sono S5. E S2? Nel sistema descritto, S2 — il coordinamento anti-conflitto — non c’è.

La conseguenza è prevedibile, e il VSM la prevede. Due worker, senza nulla che li coordini, modificano lo stesso file e si sovrascrivono a vicenda: un worker scrive, l’altro sovrascrive, il primo ripristina. È un’oscillazione, ma tra agenti invece che dentro un agente.

Il valore del VSM, qui, è diagnostico: non dice solo “c’è un bug”, dice quale funzione manca. Aggiungere un lock sui file, o una divisione esplicita e disgiunta del lavoro, significa costruire S2. Il VSM è una checklist per i sistemi multi-agente: solo S1 e S3 senza S2 produce conflitti; senza S4 il sistema è cieco al cambiamento dell’ambiente; senza S5 non ha un’identità stabile e ogni worker tira da una parte.

Va detta la classe del legame: questa è una analogia, una cornice diagnostica, non un’equivalenza — un sistema multi-agente non è un’azienda, ma le mancanze strutturali si leggono con la stessa griglia.

Esempio 4: un’escalation che funziona e una che no

Esempio operativo, sui due anelli annidati. Un agente di operations riceve il compito di liberare spazio su disco su un server: cancellare file temporanei vecchi.

Caso che funziona. Il loop operativo individua i candidati alla cancellazione. Il loop di supervisione ha una soglia: ogni operazione di cancellazione che tocca più di un certo numero di file, o che esce da una directory dichiarata sicura, fa scattare un’escalation.

L’agente propone di cancellare una directory che contiene anche file non temporanei; la soglia scatta; il loop si ferma alla riga attendi_approvazione_umana. All’umano arriva un sensore adeguato: la lista esatta dei file, la dimensione, il fatto che alcuni non corrispondono al pattern “temporaneo”, e l’avvertenza che la cancellazione è irreversibile. L’umano vede il problema, rifiuta, l’agente prosegue con un insieme più ristretto. Il loop di supervisione ha funzionato: ha riconosciuto la varietà alta della situazione e l’ha instradata all’osservatore con varietà sufficiente.

Caso che non funziona. Stesso agente, ma il checkpoint umano riceve solo “L’agente sta per eseguire un’operazione di cleanup. Approvi? [s/n]”. Il sensore dell’osservatore è povero: non sa quali file, non sa che alcuni non sono temporanei, non sa che è irreversibile.

L’umano, dopo la decima richiesta identica della giornata, approva senza guardare. È la firma cieca: il human-in-the-loop c’è sulla carta, ma il nodo-osservatore non ha l’informazione per regolare, e quindi non regola. Peggio: l’organizzazione crede di avere supervisione e non ce l’ha.

I due casi non differiscono per il modello né per il prompt. Differiscono per il design del loop di supervisione — quali soglie, quale informazione al checkpoint, quale repertorio di azioni. La lezione: l’escalation è efficace solo se l’osservatore inserito nell’anello riceve un sensore abbastanza ricco da decidere. Progettare il human-in-the-loop è progettare quel sensore.

Applicazioni pratiche

La cornice cibernetica non resta in cattedra: si traduce in scelte di harness e in pratiche di lavoro concrete.

Harness design. Quasi ogni componente serio di un harness per agenti ha un nome cibernetico. Le stopping condition sono anti-divergenza. Il feedback veloce — eseguire linter e type-check prima di proseguire — è riduzione del ritardo nel ramo di retroazione. Chiedere modifiche incrementali e diff minimi è abbassare il guadagno. I permessi minimi e la sandbox sono riduzione della varietà del sistema controllato. I checkpoint human-in-the-loop sono l’osservatore incluso nel loop.

Progettare un harness con questo vocabolario in mente significa sapere perché ciascun componente c’è, e cosa si rompe se manca. Un harness senza stopping condition lascia un anello che può divergere; uno senza feedback veloce introduce ritardo; uno senza permessi minimi lascia al guardrail una varietà da assorbire troppo grande. La cornice non aggiunge componenti nuovi: rende leggibile la funzione di quelli che ci sono già.

Debugging di un agente. È l’applicazione del secondo angolo dell’intuizione. Quando un agente fallisce, invece di fermarsi a “il modello è scarso” si passa la checklist: setpoint verificabile? sensore presente e feedback veloce? guadagno tarato? ritardo? modello dell’ambiente sufficiente? La diagnosi diventa una lista di ipotesi, ognuna con una correzione, e nessuna delle correzioni richiede di cambiare modello.

Code review di un sistema multi-agente. Passare la griglia del VSM su un’architettura multi-agente — ci sono operazioni, coordinamento, controllo, intelligence, policy? — fa emergere le funzioni mancanti prima che si manifestino come incidenti. Le mancanze più frequenti, nell’esperienza, sono S2 (coordinamento) e S5 (policy esplicita).

La cassetta degli attrezzi cibernetica per chi costruisce agenti

Tutto il capitolo si condensa in una checklist di domande operative. Ciascuna è ancorata a un capitolo della Parte X, così che la domanda sia anche un puntatore a dove approfondire. Questa è, letteralmente, la Parte X consegnata come strumento.

Setpoint. Il criterio di “done” è specificato in modo verificabile? Esiste un test o un giudice oggettivo, o l’obiettivo è una frase ambigua? — feedback-loop
Sensore. L’agente riceve ground truth a ogni passo, o agisce alla cieca? Il feedback è veloce o ritardato? — feedback-loop, stabilita-ritardi-oscillazioni
Guadagno. Le azioni dell’agente sono incrementali o massicce? A un errore piccolo corrisponde una correzione piccola? — stabilita-ritardi-oscillazioni
Anti-divergenza. C’è un tetto di iterazioni, di budget, di tempo? Cosa succede esattamente quando lo si raggiunge? — feedback-loop
Varietà. I guardrail hanno varietà sufficiente per i modi in cui l’agente può fallire? Si può ridurre la varietà del sistema controllato con una sandbox? — legge-varieta-necessaria
Modello dell’ambiente. L’agente ha un buon modello dell’ambiente in cui agisce? Dove vive quel modello: nei pesi, nel contesto, nell’esplorazione a runtime? — black-box-sistemi
Ultrastabilità. Se la strategia corrente non funziona, l’agente può cambiare strategia, o continua a sbattere contro lo stesso muro? — omeostasi-ashby
Osservabilità. La black box è sondabile? Cosa logghi, e cosa potrai ricostruire dopo un fallimento? — black-box-sistemi
Struttura multi-agente. Ci sono tutte le funzioni del VSM: operazioni, coordinamento, controllo, intelligence, policy? — sistemi-viabili-beer
L’osservatore. Chi valuta e progetta è dentro il sistema; le sue scelte plasmano l’agente. Ne stai tenendo conto? — second-order-cybernetics
Confine e autonomia. Dove passa il confine dell’agente? Ricordi che l’autonomia è operativa delegata, non costitutiva? — autopoiesi-maturana-varela

Dove si rompe

Una cornice è utile finché si conoscono i suoi limiti. Questa sezione è ampia di proposito, perché una cornice usata male produce più danni di nessuna cornice.

L’omeostasi e l’ultrastabilità: dove l’analogia si assottiglia

Il capitolo Ashby, omeostato e adattamento descrive l’omeostato: una macchina che mantiene le proprie variabili essenziali entro limiti vitali e che, quando una variabile esce dai limiti, si riconfigura — cambia i propri parametri interni — finché torna stabile. Ashby chiama questa proprietà ultrastabilità: stabilità non di una configurazione fissa, ma della capacità di trovarne una nuova quando l’ambiente cambia.

L’analogia con l’agente è attraente. Le “variabili essenziali” sarebbero i vincoli che l’agente deve mantenere: non rompere la build, non sforare il budget di token, restare nella working directory, non uscire dal compito. L’omeostasi semplice sarebbe il loop di feedback che riporta dentro i limiti — un test fallisce, l’agente corregge.

L’ultrastabilità sarebbe il livello sopra: quando la strategia corrente non riporta dentro i limiti, l’agente cambia strategia — prova un approccio diverso, decompone il compito, chiede aiuto. Pattern come Reflexion e la self-correction, discussi in Metacognizione e self-correction negli agenti, sono tentativi di dare agli agenti qualcosa come l’ultrastabilità.

Ma è qui che l’analogia va dichiarata per quello che è, e dove si assottiglia. Gli LLM-agenti hanno un’ultrastabilità parziale e inaffidabile. Spesso non si accorgono nemmeno di essere fuori dai limiti, perché non hanno un buon “sensore” delle proprie variabili essenziali: continuano a lavorare mentre il budget è già sforato o la build è già rotta da tre iterazioni. E quando si accorgono, spesso si riconfigurano male — cambiano strategia in modo controproducente, o oscillano tra strategie.

L’omeostato di Ashby ha una garanzia: per costruzione, esplora le riconfigurazioni finché ne trova una stabile. Un agente non ha quella garanzia. L’ultrastabilità, applicata agli agenti, è un obiettivo di design e una metafora utile — non una proprietà che si possa dare per acquisita. Questa è anche la ragione, in termini cibernetici, per cui il loop di supervisione esiste: la riconfigurazione che l’agente non sa fare da sé — accorgersi che la strategia non funziona e fermarsi — viene delegata al livello che lo contiene.

La cibernetica non dà teoremi sugli LLM

È il limite più importante, e va ripetuto perché il capitolo, nonostante l’avvertenza iniziale, può essere letto male. Tutto quello che qui è stato chiamato “principio”, “lezione di design”, “checklist” è materiale euristico. La cibernetica fornisce un linguaggio per pensare gli agenti e un repertorio di mosse di progetto collaudate su altri sistemi. Non fornisce garanzie.

Non esiste un teorema di stabilità per un agente basato su un LLM, non esiste un criterio formale che dica quando un loop agentico converge, e questo capitolo non ne ha dimostrato nessuno. Chi cerca garanzie deve guardare altrove — alla control theory della Parte XI, e anche lì con la consapevolezza che le garanzie valgono sotto ipotesi (linearità, dinamica nota, rumore limitato) che un LLM-regolatore in genere non soddisfa. Il valore di una cornice senza teoremi non è nullo: una cornice giusta dice dove guardare, quali domande fare, quali rimedi provare per primi. Ma va usata sapendo che è quello — una guida per il giudizio, non una rete di sicurezza matematica.

Le confusioni tipiche

Alcuni fraintendimenti ricorrono, e conviene nominarli.

Scambiare l’analogia per equivalenza. “L’agente è un sistema cibernetico” è un’analogia strutturale forte sulla topologia del loop. Non è un’identità. L’LLM-regolatore non ha legge di controllo esplicita né garanzie; lo stato non è uno scalare; l’errore non è un numero. Chi legge l’analogia come equivalenza finisce per aspettarsi dagli agenti proprietà — convergenza, stabilità — che la cibernetica garantisce solo per i sistemi che soddisfano le sue ipotesi.

Confondere i due loop. Il loop di runtime di questo capitolo non è il loop di addestramento di RLHF del capitolo Da feedback e controllo a MDP, Bellman, RL. Sono due anelli distinti, su scale di tempo diverse: uno gira mentre l’agente lavora, l’altro è girato una volta per addestrarlo.

Mescolarli porta a frasi che sembrano profonde e non vogliono dire nulla. E va aggiunto un terzo anello, per completezza: il loop di supervisione descritto in questo capitolo non è nessuno dei due — è un anello di runtime come quello operativo, ma annidato sopra di esso. Tre anelli, tre scale di tempo: addestramento, esecuzione, sorveglianza dell’esecuzione.

Trattare il good regulator theorem come prova. Il teorema è su sistemi formali, ha le nuance dette sopra, e la sua applicazione agli agenti è un’analogia ispiratrice. “Ogni agente capace ha necessariamente un modello del mondo” non è qualcosa che il teorema dimostri per gli LLM.

Scambiare autonomia operativa per autonomia costitutiva. Un agente sceglie i passi, non il fine. Su questo la prossima sezione si sofferma, perché è la confusione che ha le conseguenze più serie.

Credere che più supervisione umana sia sempre meglio. La legge della varietà dice il contrario in modo preciso: l’umano è un regolatore ad altissima varietà, ma non scala. Un umano non può seguire la varietà di mille agenti in parallelo.

La conseguenza non è “meno supervisione”, ma supervisione selettiva: l’osservatore umano viene chiamato sui rami ad alta varietà e alto rischio, non su tutto. L’escalation è una scelta di allocazione di varietà. La firma cieca dell’esempio 4 è cosa succede quando si ignora questo: troppi checkpoint saturano l’osservatore e lo rendono inutile proprio quando servirebbe.

Credere che esista il guardrail “abbastanza completo”. Come mostra l’esempio 2, se la varietà dei comportamenti indesiderati eccede strutturalmente quella di una lista fissa, nessuna lista basterà. La mossa solida è ridurre la varietà del sistema controllato, non allungare la lista.

L’agente non è autopoietico, ed è un sistema controllato

Resta la confusione più importante, e merita una sezione propria, perché tocca la questione di cosa un agente sia.

Il capitolo Autopoiesi: i sistemi che si fanno da sé presenta il concetto di Humberto Maturana e Francisco Varela (biologi cileni, autori negli anni Settanta di una teoria dei sistemi viventi). Un sistema autopoietico è un sistema che produce e rigenera continuamente i propri componenti e il proprio confine; è organizzativamente chiuso e si specifica da sé. Un essere vivente è autopoietico, e definisce i propri scopi dall’interno.

Un LLM-agente non è autopoietico, e su quattro punti precisi. Non produce i propri componenti: i pesi, l’harness, gli strumenti, l’infrastruttura sono dati dall’esterno e mantenuti da altri. Non definisce i propri scopi: il setpoint arriva da fuori — dall’utente, dal prompt. Non ha un confine auto-prodotto: dove finisce l’agente e dove comincia l’ambiente è una decisione di design, non qualcosa che l’agente generi da sé. Ed è organizzativamente aperto ed eteronomo: la sua legge gli viene da fuori.

Un agente è, nel lessico complementare a quello di Maturana e Varela, un sistema allopoietico — costruito da altri per uno scopo esterno, come una macchina. Vale la pena marcare che questa non è una novità degli LLM: vale per ogni artefatto. Un termostato non è autopoietico, e nemmeno un compilatore. La precisazione serve solo perché gli agenti, parlando in linguaggio naturale e mostrando comportamento flessibile, invitano più di altri artefatti all’errore di attribuzione.

La conseguenza è una distinzione netta, e va capita bene perché non è un giudizio sulla capacità. Un agente può essere capacissimo e restare un sistema controllato, non autonomo nel senso forte. L’autonomia che gli attribuiamo quando diciamo “agente autonomo” è un’autonomia operativa delegata: l’agente può scegliere i passi, l’ordine delle azioni, le mosse intermedie. Non è un’autonomia costitutiva: l’agente non sceglie il fine, e non si auto-produce.

Questa distinzione smonta due errori opposti nello stesso colpo. Smonta l’idea che gli agenti siano “quasi vivi” o sul punto di diventarlo — non sono sulla traiettoria dell’autopoiesi, sono un altro tipo di sistema. E smonta l’idea che abbiano scopi propri da temere o assecondare — il loro scopo è, costitutivamente, quello che è stato loro assegnato. Il tema dell’attribuzione indebita di stati mentali e propri scopi alle macchine è trattato in antropomorfismo-rischi (Parte II, in preparazione); qui basta la conclusione strutturale: l’agente è un anello controllato, e il controllo, in ultima analisi, sta fuori da lui.

L’osservatore è dentro: non esiste valutazione neutra

Un’ultima incrinatura, più sottile, viene dal capitolo Von Foerster: l’osservatore dentro il sistema. Heinz von Foerster (fisico e cibernetico austriaco-americano, 1911-2002) distingue una cibernetica di primo ordine — che studia i sistemi osservati — da una di secondo ordine, che studia i sistemi che osservano e include l’osservatore nel sistema. Non esiste osservazione neutra da una posizione esterna.

Applicato agli agenti, questo significa che chi progetta, valuta e supervisiona un agente non è fuori dal sistema agentico: ne fa parte. L’eval che scrivi definisce cosa conta come “buono” e quindi plasma quello che l’agente diventerà — è la dinamica per cui una metrica, diventando un target, smette di misurare quello che misurava. Il prompt di sistema che scrivi è una tua teoria implicita del compito. La scelta di cosa loggare decide cosa potrai mai vedere di un fallimento. Il loop human-in-the-loop è, alla lettera, l’osservatore incluso nel loop di controllo.

La conseguenza non è paralizzante, ma va presa sul serio: non esiste una valutazione “oggettiva” di un agente condotta da una posizione esterna e neutra. Il valutatore è parte del sistema valutato, e deve renderne conto — nelle eval, nei criteri, nelle scelte di logging. Questo è il filo che porta dritto alle Parti su valutazione e human factors.

Cosa portarsi a casa dalla Parte X

La Parte X si chiude qui, e conviene dire in chiaro cosa consegna. Non consegna un metodo per costruire agenti affidabili — quel metodo non esiste, e nessun capitolo di questa wiki lo possiede. Consegna un linguaggio.

Dopo aver attraversato questa Parte, un agente non è più una scatola misteriosa che a volte funziona e a volte no. È un anello di feedback, con un sensore che può essere buono o difettoso, un setpoint che può essere chiaro o sfocato, un guadagno che può essere alto o basso, un ritardo che può far oscillare, una varietà che il guardrail può o non può assorbire, un modello dell’ambiente che può essere ricco o povero, un loop di supervisione che lo contiene o gli manca. Ognuno di questi termini è una domanda azionabile, e ognuno ha dietro un capitolo che lo ha spiegato.

È poco e tanto insieme. È poco perché non sono garanzie. È tanto perché un problema che ha un nome è un problema su cui si può lavorare, e un sistema descritto con il vocabolario giusto è un sistema che si può discutere, rivedere, migliorare. Le Parti applicative che seguono — agenti, harness, human factors, safety — non ripartiranno da zero: erediteranno questo lessico e lo daranno per acquisito.

Collegamenti

Da feedback e controllo a MDP, Bellman, RL — il capitolo gemello, e il contrasto da tenere fermo: quello è un ponte genealogico (chi discende da chi, fino a RL), questo è un ponte di design (l’agente come artefatto da costruire). Loop di addestramento contro loop di runtime.
Anatomia di un anello: errore, setpoint, guadagno, ritardo — la fonte di tutto il vocabolario del loop agentico: sensore, comparatore, errore, setpoint, guadagno. Senza questo capitolo, le sezioni “La meccanica” e la checklist non hanno fondamenta.
Overshoot, ritardo, oscillazioni, divergenza — descrive in astratto le patologie che qui leggiamo nel comportamento concreto di un agente: corregge troppo, oscilla, entra in loop, agisce su informazione vecchia.
La legge della varietà necessaria — il principio dietro il design dei guardrail e della supervisione: il regolatore deve avere abbastanza varietà, e l’umano-supervisore non scala.
Ashby, omeostato e adattamento — omeostasi e ultrastabilità come modello degli agenti che mantengono vincoli e si riconfigurano, con l’avvertenza che negli agenti l’ultrastabilità è parziale.
Black box, input-output, identificazione del sistema — l’agente come scatola opaca, e il fatto che il controllo passa dai bordi (ambiente, permessi, contesto) e non dall’interno.
Stafford Beer e il Viable System Model — la griglia S1-S5 con cui leggere i sistemi multi-agente e trovare le funzioni mancanti.
Von Foerster: l’osservatore dentro il sistema — chi progetta e valuta un agente è parte del sistema; non esiste eval da una posizione esterna neutra.
Autopoiesi: i sistemi che si fanno da sé — l’argomento per cui un LLM-agente non è autopoietico: è un sistema controllato ed eteronomo, non autonomo nel senso forte.
Perché la teoria dei sistemi serve per capire agenti e deployment — il ponte gemello della Parte precedente; questo capitolo ne è la prosecuzione naturale, dal vocabolario dei sistemi a quello del feedback.
Alignment come problema principal-agent — il setpoint mal specificato di questo capitolo è una faccia del problema principal-agent: chi delega non riesce a specificare l’obiettivo abbastanza bene.
Metacognizione e self-correction negli agenti — i pattern di self-correction come tentativo di dare agli agenti qualcosa come l’ultrastabilità di Ashby.

I fili verso le Parti applicative restano aperti come plain text, perché quei capitoli non sono ancora scritti: agente-definizione e agent-loop-patterns (Parte XXXVIII, fondamenti degli agenti); human-in-the-loop, approval-patterns e agent-permissions (Parte XLI, harness engineering); agent-observability (osservabilità degli agenti); orchestrazione e multi-agent (sistemi multi-agente); reward-hacking-specification-gaming (Parte XVI); control-theory-intro e ponte-control-agenti (Parte XI). Tutti useranno il vocabolario di questo capitolo dandolo per acquisito.

Per andare oltre

R. C. Conant, W. R. Ashby, Every good regulator of a system must be a model of that system (International Journal of Systems Science, vol. 1 n. 2, 1970). Il paper del good regulator theorem. Da leggere con in mente la nuance: la dimostrazione è più modesta del titolo.
Anthropic, Building effective agents (Anthropic engineering blog, dicembre 2024). La definizione operativa di agente usata in questo capitolo: augmented LLM, agent contro workflow, loop con environmental feedback, stopping condition, checkpoint umani.
W. R. Ashby, An Introduction to Cybernetics (Chapman & Hall, 1956; disponibile online). Il testo da cui vengono la legge della varietà necessaria e l’omeostato. Capitoli 11 e 13 per i temi di questo capitolo.
S. Beer, Brain of the Firm (2a ed., Wiley, 1981). L’esposizione di prima mano del Viable System Model, utile per chi vuole portare la griglia S1-S5 oltre il livello diagnostico di questo capitolo.
H. Maturana, F. Varela, Autopoiesis and Cognition: The Realization of the Living (D. Reidel, 1980). La fonte sull’autopoiesi e sulla distinzione tra sistemi autonomi ed eteronomi, alla base dell’argomento per cui un agente non è autopoietico.