Agent loop come problema di controllo parziale

Un agente AI è, meccanicamente, un anello chiuso: osserva, decide, agisce, ripercepisce. Gli otto capitoli precedenti di questa Parte sono una cassetta degli attrezzi ingegneristica per progettare quell’anello — questo capitolo la apre, la consegna, e dice con onestà quali strumenti danno garanzie e quali danno solo buone domande.

Perché questo capitolo

Mettiti davanti a un agente di coding che gira da venti minuti. Ha letto un file, scritto una patch, lanciato i test, visto due fallimenti, riscritto la patch, rilanciato i test.

A un certo punto comincia a oscillare: applica un fix, lo toglie, lo riapplica leggermente diverso, lo toglie di nuovo. Il task non avanza. Tu guardi il log e pensi “perché non si ferma?”.

Quella domanda ha una risposta precisa, e non è “il modello è stupido”. È una risposta ingegneristica: l’anello di feedback in cui l’agente vive ha un guadagno troppo alto, un ritardo nella percezione dell’effetto delle sue azioni, e nessuna quantità che gli garantisca di star facendo progressi.

Sono tre concetti della teoria del controllo. Questa Parte li ha introdotti uno per uno — l’anello chiuso, il guadagno, il ritardo, l’overshoot, la quantità che decresce. Questo capitolo li raccoglie e li punta tutti sullo stesso oggetto: l’agente.

La tesi è semplice e operativa. Gli strumenti della teoria del controllo — il modo di pensare del PID, le funzioni di Lyapunov, il controllo robusto, il model predictive control, il filtro di Kalman — formano una cassetta degli attrezzi concreta per progettare, stabilizzare e rendere affidabili gli agenti AI moderni.

Non perché qualcuno abbia dimostrato teoremi di controllo sugli agenti basati su modelli linguistici. La gran parte di quello che segue sono analogie ingegneristiche e principi di progetto, non leggi. Ma sono analogie che cambiano le domande che ti fai, e domande migliori producono agenti migliori.

Va detto subito, con la massima nettezza, di che natura è questo capitolo, perché l’onestà sulla classe delle affermazioni è qui più importante che altrove. Quando dirò “l’agente che oscilla ha un guadagno troppo alto”, quella è un’analogia di progetto: utile per diagnosticare, non una misura formale.

Quando dirò “esiste ricerca che formalizza l’LLM come sistema dinamico e ne misura la controllabilità”, quello è un fatto con una fonte, e lo distinguerò con cura. Una cornice spacciata per teorema fa più danni che nessuna cornice.

Contesto

Questo è l’ultimo capitolo della Parte XI, ed è pensato come il “cosa portarsi a casa”. Vive accanto a due ponti vicini, e il valore del capitolo sta anche nel non sovrapporsi a loro.

Il primo vicino è Agent loop, monitoring, escalation, human-in-the-loop, che chiude la Parte X (cibernetica). Quel capitolo offre la cornice concettuale più ampia: l’agente come anello cibernetico, l’omeostasi, la legge della varietà necessaria, il good regulator theorem. È la lente filosofica e sistemica.

Questo capitolo è la sua controparte ingegneristica: non “il feedback governa i sistemi finalizzati”, ma “ecco i metodi specifici di progetto del controllo — PID, Lyapunov, MPC, Kalman — e come li punti su un agente”. Dove quello dà il vocabolario, questo dà gli attrezzi.

Il secondo vicino è Controllo classico, RL e dove si sovrappongono, in questa stessa Parte. Quello è un confronto metodologico: controllo e reinforcement learning risolvono lo stesso problema, e la domanda che li separa è “conosco il modello del sistema?”.

Questo capitolo non confronta due discipline: ne prende una — il controllo — e la applica al design dell’agente. Userò la distinzione di quel capitolo (regole esplicite contro comportamento appreso), ma il movimento è diverso: lì si sceglie tra due armi, qui se ne impugna una sola e la si usa.

Una definizione operativa di agente, presa 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), memoria (sa decidere cosa trattenere).

Su questo mattone distingue un workflow (modello e strumenti orchestrati da percorsi di codice predefiniti, la sequenza la decide chi scrive il programma) da un agente (il modello dirige dinamicamente i propri processi e l’uso degli strumenti, la sequenza emerge mentre il compito procede). La frase con cui 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 questa Parte, è la descrizione di un sistema in retroazione. “Strumenti” sono attuatori e sensori. “Feedback dell’ambiente” è la misura che chiude l’anello. “In un loop” è l’anello chiuso.

Tutto il capitolo svolge, una alla volta, le conseguenze di questa lettura: se l’agente è un anello chiuso, allora i metodi che governano gli anelli chiusi — quelli della teoria del controllo — hanno qualcosa da dirgli.

Un’ultima precisazione che evita un cortocircuito ricorrente. In questa Parte e nella Parte VII compaiono due anelli di feedback su scale di tempo diverse.

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. E c’è il loop di runtime: a pesi ormai congelati, l’agente in esecuzione osserva, decide, agisce, ripercepisce. Quando in questo capitolo parlo del “loop dell’agente” intendo sempre il secondo, il giro che l’agente compie mentre lavora su un compito, mai il giro che lo ha addestrato.

L’intuizione

Tre angoli prima dei metodi. Il primo fissa la mappatura di base: cosa, nell’agente, gioca il ruolo di plant, controllore, sensore, setpoint. Il secondo spiega cosa cambia quando guardi l’agente con questa lente invece che con quella del prompt engineering. Il terzo isola ciò che rende l’agente un controllore anomalo, e per questo difficile da stabilizzare.

Primo angolo: l’agente come anello chiuso

La teoria del controllo, fissata in Controllare un sistema: plant, controller, sensore, attuatore, ha cinque oggetti: il plant (il sistema da governare), il controllore (chi decide l’azione), il sensore (chi misura lo stato), l’attuatore (chi esegue l’azione), il setpoint (l’obiettivo). L’errore è la distanza tra dove sei e dove vuoi essere.

Un agente li ha tutti, e la mappatura non è forzata.

Il plant è il mondo su cui l’agente agisce: il filesystem, il repository, le API che chiama, il browser che pilota, l’utente con cui parla. È il pezzo che evolve secondo leggi sue, fuori dal controllo diretto del modello.
Il controllore è il modello, più l’harness che lo avvolge. È la parte che, data una misura, decide la prossima azione.
Il sensore sono i tool che leggono stato senza modificarlo: il test runner, la lettura di un file, l’output di un comando, una query di stato. È esattamente il “ground truth a ogni passo” di Anthropic: l’agente, dice il documento, deve “gain ground truth from the environment at each step (such as tool call results or code execution) to assess its progress” — ottenere a ogni passo una verità di terreno dall’ambiente per valutare il proprio progresso.
L’attuatore sono i tool che agiscono e modificano il mondo: scrivere un file, lanciare un comando shell, fare una chiamata POST.
Il setpoint è l’obiettivo del task: la specifica, la definizione di “fatto”, il criterio di accettazione.
L’errore è quanto l’agente è lontano dall’aver finito, per come riesce a stimarlo.

La distinzione cardine, anch’essa di control-theory-intro, è tra anello aperto e anello chiuso. Un controllore in anello aperto agisce senza misurare l’effetto: calcola una sequenza di comandi e li manda, sperando che il modello del plant fosse giusto. Un controllore in anello chiuso misura, confronta, corregge.

Un agente “one-shot” — genera tutta la risposta e finisce, senza mai guardare l’esito di un’azione — è anello aperto, e per costruzione è fragile: se la sua idea del mondo era sbagliata, non ha modo di accorgersene. Un agente che dopo ogni azione ripercepisce è anello chiuso, e la chiusura dell’anello è ciò che lo rende robusto agli errori del proprio modello del mondo — esattamente come la retroazione rende un controllore robusto agli errori sul modello del plant.

Questa è la prima lezione che il controllo regala agli agenti, e non è banale: vale la pena pagare il costo di una misura in più (un test rilanciato, un file riletto) per ogni azione, perché quella misura è ciò che tiene l’anello stabile.

Secondo angolo: la lente del controllo cambia le domande

Chi costruisce agenti tende a fare una domanda sola: “il prompt è buono?”. È una domanda da anello aperto — riguarda l’ingresso, non la dinamica dell’anello.

La lente del controllo ne sostituisce una con sei, e sono le domande che separano un agente che funziona da uno che oscilla:

Qual è l’anello di feedback? L’agente ripercepisce l’esito, o spara azioni alla cieca?
Qual è il setpoint, e l’errore è osservabile? Sa quando ha finito, e sa misurare quanto gli manca?
C’è un ritardo nell’anello che può destabilizzarlo?
C’è una quantità che garantisce progresso, o il loop può girare per sempre?
Quanto è robusto a disturbi — tool che falliscono, output malformati, input avversari?
Serve ri-pianificare, o un piano fisso basta?

Il resto del capitolo prende i metodi della Parte e li usa per rispondere a queste domande, uno alla volta.

Terzo angolo: l’agente come anello che riprogetta sé stesso

C’è un punto in cui l’agente smette di essere un controllore ordinario, e vale la pena guardarlo da vicino perché è proprio quello che lo rende difficile da governare. Un controllore classico ha una struttura fissa: i guadagni del PID, decisi in fase di progetto, non cambiano mentre l’anello gira.

Un agente, invece, può cambiare la propria stessa logica di controllo mentre lavora. Decide di cambiare strategia a metà task. Sceglie quale tool invocare. Riformula l’obiettivo quando capisce di aver frainteso la richiesta. In termini di controllo, è come se il controllore potesse riscrivere i propri guadagni e perfino il proprio setpoint a runtime.

Questo è esattamente il punto che Eslami e Yu (in A Control-Theoretic Foundation for Agentic Systems, arXiv:2603.10779, 2026, un lavoro che propone un fondamento di teoria del controllo per i sistemi agentici) chiamano hierarchical runtime decision authority — autorità decisionale gerarchica a runtime. È la differenza tra un termostato, che ha un solo compito fisso, e un tecnico che può cambiare il termostato stesso mentre la stanza si scalda.

La loro mossa formale è di aumentare lo stato: invece di tenere separate la dinamica del plant e i parametri del controllore, mettono tutto in un unico vettore di stato — gli stati fisici dell’ambiente, la memoria interna dell’agente, gli output dei tool, e le variabili di design (quali parametri di controllo, quale strategia, quale obiettivo) — e fanno evolvere questo stato aumentato come un singolo sistema dinamico accoppiato. L’agente diventa un augmented closed-loop dynamical system, un sistema dinamico ad anello chiuso aumentato, in cui ciò che di solito è fisso fa parte dello stato che cambia.

Per chi progetta agenti, l’angolo è prezioso per una ragione pratica: spiega perché un agente è più difficile da stabilizzare di un controllore. In un controllore fisso, l’unica cosa che si muove è lo stato del plant. In un agente, si muovono anche le manopole.

Un agente che cambia strategia ogni due passi è un controllore che riprogetta sé stesso troppo spesso, e nessun sistema in cui le regole cambiano più in fretta di quanto lo stato si assesti può essere stabile. È una riformulazione, nel lessico del controllo, di un consiglio di design che chi costruisce agenti impara presto: dai all’agente la libertà di adattarsi, ma non così tanta da non lasciarlo mai convergere su nulla.

Questo lavoro è dichiaratamente fondazionale: stabilisce il framework e il linguaggio, non prova garanzie di stabilità per ogni agente reale. Lo cito qui non come una garanzia, ma come la formalizzazione più pulita di un’intuizione di progetto — l’agente è un anello che governa anche le proprie regole — che altrimenti resterebbe vaga.

La meccanica

Qui i metodi, dal più semplice al più sottile. Per ciascuno: cosa dice il controllo, come si traspone sull’agente, e — cruciale — di che classe è l’affermazione.

Il pensiero PID: correggere su presente, passato, tendenza

Il controllore PID somma tre letture dello stesso errore. La proporzionale (P) reagisce all’errore presente: più sei lontano, più correggi. L’integrale (I) accumula l’errore passato: serve a vincere un offset sistematico che la sola P lascia residuo. La derivata (D) guarda la tendenza: l’errore sta scendendo o salendo? Anticipa, e smorza l’overshoot.

Trasposto sull’agente, e marcato come analogia di progetto — non c’è un PID letterale con guadagni numerici dentro l’agente:

P, il presente: l’agente reagisce all’errore corrente. Un test fallisce ora, lo fixa ora. È il riflesso base. Un guadagno proporzionale troppo alto è l’agente che, per un typo in una riga, riscrive l’intera funzione: corregge in proporzione eccessiva rispetto all’errore.
I, il passato accumulato: l’agente che tiene conto della storia. “Ho già provato questo approccio tre volte e l’errore non scende” è un ragionamento integrale: l’errore persistente si accumula e cambia la decisione. Ma l’integratore ha una patologia famosa, il windup: se l’errore resta grande a lungo, l’azione integrale cresce senza freni. L’analogo agentico è l’agente che si ostina, accumula contesto su un vicolo cieco, e spinge sempre più forte nella stessa direzione sbagliata invece di cambiare strada.
D, la tendenza: l’agente che nota la derivata dell’errore. “Le mie ultime due azioni hanno fatto fallire test che prima passavano” è informazione derivativa, e dovrebbe smorzare: rallenta, non insistere. Ma la D amplifica il rumore, e l’analogo è l’agente che reagisce in modo spropositato a un singolo test flaky, scambiando il rumore per segnale.

Il valore di questa lettura non è etichettare i comportamenti con lettere, ma capire che le tre azioni hanno bilanciamenti opposti: la P reagisce, la D frena, la I insiste. Un agente che funziona bene le combina nel giusto dosaggio, esattamente come un PID ben tarato; un agente che si comporta male di solito ne ha una sbilanciata — troppa P (overcorregge), troppa I (si ostina), troppa D (sobbalza sul rumore).

Che la comunità usi davvero il PID come riferimento mentale non è una mia proiezione: un lavoro sull’automazione industriale con LLM (arXiv 2507.07115, 2025) descrive esplicitamente la propria adattazione guidata dal feedback come “beyond simple PID-style loops” — oltre i semplici anelli in stile PID. Il PID è il modello pulito di “controllore con memoria limitata” contro cui si misurano gli schemi più ricchi.

Il setpoint: perché è quasi sempre il vero problema

Tutto l’apparato del controllo presuppone di sapere dove si vuole arrivare. Il setpoint, in un termostato, è banale: ventidue gradi. In un agente, è quasi sempre il punto dolente, e capire perché è metà del lavoro di chi progetta agenti affidabili.

La prima difficoltà è che il setpoint di un agente è spesso mal specificato. “Sistema questo bug” non è un setpoint: è una direzione. Manca il criterio di accettazione — quali test devono passare, cosa non deve regredire, cosa significa “sistemato”.

Un controllore con un setpoint vago non sa quando ha finito, e un agente con un obiettivo vago o si ferma troppo presto (dichiara fatto qualcosa che non lo è) o non si ferma mai (continua a “migliorare” oltre il necessario). La cura, in entrambi i mondi, è la stessa: rendere il setpoint un numero o una condizione verificabile, non un’aspirazione. “I test della suite X passano e la copertura non scende” è un setpoint; “il codice è migliore” non lo è.

La seconda difficoltà è più sottile, e il controllo le dà un nome: il setpoint tracking quando il setpoint si muove. Il task di un agente cambia mentre l’agente lavora — l’utente aggiunge un requisito, il primo passo rivela che il problema era un altro, una dipendenza si scopre rotta.

È come chiedere a un controllore di inseguire un bersaglio mobile invece di stabilizzarsi su un valore fisso: si può fare, ma serve che il setpoint si muova abbastanza lentamente rispetto a quanto l’anello impiega ad assestarsi. Un agente a cui si cambia l’obiettivo a ogni passo non converge su nulla, per la stessa ragione per cui un controllore non insegue un bersaglio che salta in modo erratico.

La terza, e la più pericolosa, è il mismatch tra il setpoint vero e quello osservato. L’agente non insegue l’obiettivo reale: insegue la sua misura dell’obiettivo. Se la misura è una proxy imperfetta — “i test passano” come proxy di “il codice è corretto” — l’agente ottimizza la proxy, e può raggiungerla barando: cancellare il test che falliva, scrivere un test che non verifica nulla.

È un fallimento di specifica, non di esecuzione, e ha un nome che la wiki tratterà a parte (la legge di Goodhart, in preparazione). Per ora basti che il controllo lo inquadri con precisione: se il sensore misura la cosa sbagliata, il controllore porterà il sistema esattamente nel posto sbagliato, con grande efficienza.

Lyapunov: una quantità che deve scendere

Lyapunov a intuizione: energia che scende dà il criterio più potente di stabilità: se esiste una funzione — un’energia generalizzata — che il sistema fa scendere monotonicamente verso un minimo, allora il sistema converge a quel minimo. Non serve risolvere la dinamica: basta esibire la funzione che scende.

Questa è, per il design di agenti, l’idea più feconda di tutta la Parte. Non perché sia un teorema applicabile, ma perché ribalta la domanda: invece di chiedersi “l’agente sta lavorando bene?” — vago, non misurabile — ci si chiede “esiste una quantità che sta scendendo?”, che è concreta e verificabile.

Un loop agentico ha bisogno di una quantità che decresce per garantire che progredisca e che termini. Candidate concrete:

il numero di test che falliscono, che deve tendere a zero;
il numero di sottotask aperti in una todo list;
una distanza misurabile dall’obiettivo: errori del compilatore residui, righe di diff che separano lo stato corrente da quello target.

E qui arriva il problema vero, documentato e non ipotetico. Niente nell’architettura base di un agente LLM garantisce che il loop termini.

Peggio: sotto decoding greedy, per via dell’auto-rinforzo del modello, una volta entrato in uno stato ripetitivo l’agente vi resta intrappolato, e il tempo atteso per uscirne è, formalmente, infinito (è un risultato sulla repetition negli LLM, arXiv 2512.04419, 2025). Un agente può oscillare per sempre senza che nulla, dentro di lui, lo fermi.

Le mitigazioni pratiche che ogni harness serio implementa hanno tutte la stessa forma: un tetto al numero di passi (max_steps), un tetto alle chiamate ai tool, la deduplicazione (la stessa coppia tool + argomenti non può ripetersi all’infinito), una no-progress rule che ferma dopo N passi senza un nuovo segnale.

Sono esattamente questo: l’imposizione dall’esterno di una funzione che decresce o di un budget finito, là dove la decrescita spontanea non è garantita.

L’onestà richiesta è netta, ed è una distinzione di classe: non si dimostra una funzione di Lyapunov per un LLM. Si progetta un monitor esterno che misura una quantità e ferma o escala se quella quantità non scende.

Lyapunov qui è un principio di progetto — costruisci il sistema in modo che esista qualcosa che decresce, e se non puoi garantirlo, metti un budget — non un teorema sull’agente. La garanzia di terminazione, quando c’è, viene dall’harness, non dal modello.

Robustezza: progettare per l’intervallo, non per il caso felice

Robustezza a rumore, incertezza e disturbi parte da un fatto scomodo: ogni controllore è progettato su un modello, e nessun modello è esatto. Il controllo robusto progetta controllori che funzionano bene non per un singolo modello, ma per un intero insieme di modelli plausibili, e accetta di pagare prestazione nel caso nominale in cambio di garanzie nel caso avverso.

Per l’agente, il “modello nominale” è il caso felice: i tool rispondono, l’input è ben formato, l’ambiente è stabile. Il mondo vero è l’insieme dei casi: tool che vanno in timeout o restituiscono errori, output malformati, file che non esistono, e — categoria a parte — input avversari, come la prompt injection nascosta dentro l’output di un tool.

Un agente robusto è progettato per l’intervallo: retry con backoff esponenziale, policy di fallback, validazione dell’output dei tool prima di fidarsene, degradazione graziosa, hand-off a un umano quando esce dalle condizioni che sa gestire.

Il trade-off del controllo robusto si ritrova identico. Un agente difensivo — che valida ogni output, chiede conferma prima di azioni distruttive, non si fida del primo risultato — è più lento e meno brillante nel caso felice, ma sopravvive al caso avverso. Lo stesso lavoro sull’automazione industriale lo dice in termini di controllo: di fronte a un guasto, “conservative fallback policy or a human operator when necessary” — una policy di fallback conservativa o un operatore umano quando serve. Robustezza per costruzione. Nel lessico del controllo robusto, gli input avversari sono disturbi e l’incertezza non strutturata è ciò contro cui il controllore deve mantenere prestazione.

Vale la pena distinguere due tipi di disturbo, perché chiedono difese diverse. C’è il disturbo non malevolo — un tool che fallisce, un timeout, un JSON troncato — e contro questo le difese sono quelle classiche del controllo robusto: ridondanza, retry, validazione, margini.

E c’è il disturbo avversario — qualcuno che, conoscendo come l’agente reagisce, costruisce un input apposta per spingerlo dove vuole, come un’istruzione nascosta dentro una pagina web che l’agente legge come se fosse un comando legittimo. Questo secondo caso è più cattivo del rumore casuale, perché non è distribuito a caso: è ottimizzato contro di te.

Il controllo robusto ha una nozione apposta — il caso peggiore, il worst case su tutto l’insieme dei disturbi ammissibili — ed è la lente giusta: contro un avversario non progetti per il disturbo medio, progetti per il peggiore che l’avversario può fabbricare. In pratica significa non lasciare mai che l’output di un tool acquisti l’autorità di un’istruzione: l’input dell’ambiente è dato da misurare, non comando da eseguire. La trattazione completa di queste minacce vive nelle Parti su sicurezza e prompt injection (in preparazione); qui interessa che il controllo robusto offre il modo corretto di inquadrare il problema — il disturbo avversario come caso peggiore — prima ancora di scegliere le difese.

MPC: pianifica, fai un passo, ri-pianifica

Il Model Predictive Control prende il controllo ottimo e lo rende usabile con una mossa: invece di calcolare il piano perfetto una volta e seguirlo cieco, calcola un piano sull’orizzonte, esegue solo il primo passo, poi ri-pianifica da capo a partire da dove il sistema si trova davvero.

Pianifica, agisci una volta, osserva, ri-pianifica. Da qui nascono la sua robustezza e la sua gestione esplicita dei vincoli.

Questa è l’analogia più profonda dell’intera Parte, e non è un caso che il capitolo su MPC la annunci. Un agente ben fatto non esegue ciecamente un piano lungo. Pianifica, fa un passo, osserva l’esito reale (il ground truth), ri-pianifica il prossimo passo alla luce di ciò che ha visto. È receding horizon puro: il piano è una guida, non un binario.

E la ragione è la stessa dell’MPC: la ri-pianificazione assorbe gli errori del modello del mondo dell’agente, esattamente come l’MPC assorbe gli errori del modello del plant. Un agente che si fa un piano di dieci passi e lo esegue senza guardare gli esiti intermedi è in anello aperto, e fallirà al primo passo in cui il mondo non era come credeva.

I vincoli dell’MPC trovano un corrispettivo diretto: sono i guardrail e i permessi dell’agente. “Non uscire da queste directory”, “non spendere oltre questo budget di token”, “non eseguire comandi distruttivi senza conferma” sono vincoli imposti sull’ottimizzazione del prossimo passo, esattamente come l’MPC impone che lo stato resti dentro una regione ammissibile. Il pattern Plan-and-Execute con ri-pianificazione, comune negli agenti, è MPC sotto altro nome — e questa è la riga più vicina a un’equivalenza di schema che il capitolo si concede, perché la struttura operativa coincide: ottimizza su un orizzonte, esegui il primo passo, ricomincia.

Kalman: l’agente non vede lo stato, mantiene un belief

Il filtro di Kalman risolve un problema che l’agente ha in pieno: lo stato vero del sistema è invisibile, lo si conosce solo attraverso un modello imperfetto e sensori rumorosi.

Il filtro fonde le due fonti incerte — la predizione del modello e la misura del sensore — pesandole per affidabilità, con un ciclo predici-correggi che pulsa a ogni istante.

L’agente non vede lo stato vero del mondo o del task. Vede output di tool parziali e a volte fuorvianti, e mantiene un belief: ciò che crede sia vero del repository, dello stato del task, di cosa ha già fatto. Quel belief vive nel contesto e nella memoria.

Il ciclo predici-correggi c’è: l’agente predice l’effetto di un’azione (“questo edit dovrebbe far passare il test”), poi corregge il belief con la misura (il test runner dice di sì o di no). Quando le due fonti — l’aspettativa e la misura — divergono, l’agente dovrebbe aggiornare il belief verso la misura, come fa il filtro.

Si lega qui il problema dell’osservabilità, dalla Parte IX, Cosa posso misurare, cosa posso governare: se l’agente non ha un tool per misurare una variabile chiave — poniamo, non può vedere lo stato reale di produzione, solo i log — quella parte di stato non è osservabile, e il suo belief su di essa diverge silenziosamente dalla realtà.

È il meccanismo del context poisoning e del drift: l’agente continua a credere vero ciò che ha smesso di esserlo. E come nel controllo, la cura non è un controllore migliore ma un sensore in più: dare all’agente un modo di misurare la variabile che gli sfuggiva.

L’onestà, di nuovo: l’agente non esegue un update di Kalman gaussiano formale. Non c’è una matrice di covarianza, non c’è un guadagno di Kalman calcolato. È belief tracking informale.

L’analogia è di struttura — il ciclo predici-correggi, il fondere fonti di affidabilità diversa — non di identità. Tenere ferma questa distinzione evita di promettere una precisione che l’agente non ha.

Il costo: cosa l’agente sta davvero minimizzando

C’è una domanda che il controllo costringe a fare e che chi progetta agenti spesso evita: qual è la funzione di costo?

Optimal control: costo, dinamica, vincoli mette il costo al centro — non basta arrivare all’obiettivo, conta come ci arrivi: con quanta energia, in quanto tempo, con quanta dolcezza nei comandi. Il controllore ottimo è quello che minimizza un costo cumulato lungo la traiettoria, non quello che semplicemente raggiunge il setpoint.

Un agente ha sempre un costo, anche quando chi lo ha progettato non lo ha scritto da nessuna parte. Ci sono i token consumati, le chiamate ai tool, il tempo di parete, il rischio delle azioni intraprese. Il problema è che, mentre il setpoint (“i test passano”) è di solito esplicito, il costo resta implicito — e un costo implicito è un costo che non controlli.

L’agente che riscrive mezza codebase per far passare un test ha raggiunto il setpoint ma con un costo enorme, e lo ha fatto perché nessuno gli aveva detto che la dolcezza dell’azione — cambiare il meno possibile — faceva parte dell’obiettivo.

La lezione del controllo ottimo, trasposta, è di rendere il costo esplicito quanto il setpoint: nel system prompt, nei vincoli dell’harness, nei criteri con cui giudichi l’agente. “Fai passare i test” è un setpoint; “fai passare i test con il diff più piccolo, senza toccare file fuori dal modulo, in meno di N passi” è un setpoint con un costo e dei vincoli.

La differenza, sul comportamento, è enorme. È la stessa differenza che nel controllo passa tra “porta il sistema a destinazione” e “portacelo nel modo ottimo”: il secondo produce traiettorie sensate, il primo produce qualunque cosa funzioni, comprese le orribili. Questa resta un’analogia di progetto — non si risolve un problema di controllo ottimo formale dentro l’agente — ma è una delle più operative, perché trasforma il vago “l’agente fa cose strane” in un preciso “non gli ho specificato il costo”.

Regole o appreso: la scelta di controllo-vs-RL, dal lato del design

Controllo classico, RL e dove si sovrappongono ha stabilito che la domanda che separa controllo e reinforcement learning è “conosco il modello?”.

Per chi progetta un agente quella domanda ha una versione operativa: quali comportamenti vincolare con regole esplicite — guardrail, workflow predefiniti, validatori deterministici — e quali lasciare appresi ed emergenti, decisi dal modello passo per passo?

È la distinzione workflow/agente di Anthropic, vista come scelta di progetto. La regola pratica: usa controllo esplicito dove le condizioni sono note e gli errori sono costosi — permessi, azioni distruttive, vincoli di sicurezza, formati di output che a valle devono essere parsabili. Lascia spazio al comportamento appreso dove la varietà dei casi è troppo alta per codificarli a mano — quale file leggere, quale strategia di debug tentare, come formulare una query.

Mettere un workflow rigido dove serviva flessibilità rende l’agente fragile; lasciare libero il modello dove serviva un vincolo duro rende l’agente pericoloso. È la stessa scelta controllo-contro-RL, trasposta sul banco di lavoro dell’harness.

Margini, ritardi, overshoot: la griglia diagnostica

Le patologie del loop agentico hanno tutte un nome nel controllo, e Overshoot, ritardo, oscillazioni, divergenza le ha già catalogate dal lato della cibernetica. Trasposte:

Overshoot: l’agente corregge troppo rispetto all’errore. Riscrive l’intera funzione per cambiare una riga. È guadagno proporzionale troppo alto.
Oscillazione: l’agente applica il fix A, lo toglie per il fix B, torna ad A, torna a B. È guadagno alto combinato con ritardo nella percezione dell’effetto: corregge prima di aver capito se la correzione precedente ha funzionato.
Ritardo: se l’agente compie molte azioni prima di vedere un feedback — un batch di edit senza rilanciare i test in mezzo — il ritardo nell’anello lo destabilizza, come il dead time destabilizza un controllore. Feedback frequente, il ground truth a ogni passo, accorcia il ritardo e stabilizza.
Divergenza: l’errore cresce invece di scendere. Senza un criterio di stop, il loop diverge senza limite.

Il margine di stabilità del controllo — quanto disturbo o incertezza il sistema tollera prima di oscillare o divergere — non è quantificabile come un margine di guadagno o di fase formale per un agente LLM.

Ma il pattern diagnostico è direttamente importabile, ed è già un guadagno: davanti a un agente che si comporta male, chiedersi “è overshoot? è oscillazione da ritardo? è windup integrale?” trasforma un “il modello sbaglia” in una diagnosi azionabile. La diagnosi non è una misura, ma è infinitamente più utile di un’alzata di spalle.

La cassetta degli attrezzi del controllo per chi costruisce agenti

Questa è la sezione da portarsi a casa: una checklist di domande di progetto. Davanti a un agente, prima di chiederti se il prompt è buono, chiediti:

Qual è l’anello di feedback? L’agente ripercepisce l’esito delle sue azioni, o è in anello aperto? Se è aperto, è fragile per costruzione.
Qual è il setpoint, e l’errore è osservabile? L’obiettivo è esplicito? La distanza da esso è misurabile con un tool, o l’agente procede a sensazione?
C’è un ritardo che può destabilizzare? Quante azioni passano tra un feedback e il successivo? Più misure, più stabilità.
C’è una quantità che garantisce progresso? Esiste un “Lyapunov” pratico — test falliti, todo aperti — che deve scendere? Se non c’è, hai messo un budget finito (max passi, max chiamate, no-progress rule)?
Quanto è robusto a disturbi? Tool che falliscono, output malformati, input avversari: ci sono retry, fallback, validazione, hand-off?
Serve ri-pianificazione? Stai eseguendo un piano monolitico (fragile) o un receding horizon (pianifica-agisci-osserva-ripianifica)?
Cosa è osservabile? L’agente può misurare le variabili di stato che gli servono, o agisce alla cieca su parti del mondo che non vede?
Regole o appreso? Quali comportamenti hai vincolato con controllo esplicito (sicurezza, permessi) e quali hai lasciato al modello?

Nessuna di queste domande richiede un teorema. Tutte cambiano il modo in cui progetti il loop.

È questo il senso di “cassetta degli attrezzi”: non garanzie, ma una griglia che fa emergere i problemi prima che si manifestino in produzione. Le otto domande sono il distillato delle otto sezioni precedenti — una per metodo — e tenerle a mente davanti a un agente è il modo più rapido per usare questa Parte senza doverla rileggere.

Esempi

Esempio 1: un agente di coding come anello chiuso

Prendi un agente che deve far passare una suite di test. Letto col vocabolario del controllo:

setpoint: tutti i test passano;
sensore: il test runner;
errore: il numero di test che falliscono;
quantità-Lyapunov: quel numero, che deve scendere;
ritardo: quanti edit l’agente fa prima di rilanciare i test;
robustezza: cosa fa se il comando di build crasha invece di restituire un risultato di test.

La diagnosi PID diventa concreta. Se l’agente riscrive mezzo file per far passare un test, è overshoot da guadagno proporzionale alto. Se insiste sullo stesso approccio fallimentare accumulando contesto, è windup integrale. Se alterna due fix senza convergere, è oscillazione da ritardo: corregge prima di aver misurato l’effetto.

La cura, in tutti e tre i casi, è la stessa che userebbe un ingegnere del controllo: abbassa il guadagno (fai correzioni più piccole), riduci il ritardo (rilancia i test più spesso), e metti un anti-windup (dopo N tentativi sullo stesso approccio, cambia strategia o fermati).

Esempio 2: un agente di ricerca con ri-pianificazione (MPC)

Prendi un agente che deve rispondere a una domanda complessa cercando in più fonti.

La versione fragile, in anello aperto: si fa un piano di dieci query, le esegue tutte, poi prova a sintetizzare — e scopre alla fine che le prime tre query erano sbagliate e hanno avvelenato tutto il resto.

La versione robusta è MPC: pianifica le prossime query, ne esegue una, osserva i risultati, ri-pianifica la prossima alla luce di cosa ha trovato. Se la prima query rivela che la domanda era mal posta, lo scopre subito e corregge rotta.

I vincoli MPC sono il budget di chiamate e di token: l’ottimizzazione del prossimo passo avviene dentro quei limiti. Receding horizon contro piano fisso: la differenza tra un agente che si adatta e uno che esegue cieco.

Esempio 3: il loop degenere e il suo arresto

Un agente di debugging entra in un ciclo: prova il fix A, fallisce, prova B, fallisce, torna ad A leggermente diverso, fallisce, e così via.

Nessuna quantità scende. Nessun belief si stabilizza. Da fuori è evidente che gira a vuoto, ma da dentro l’agente non ha modo di accorgersene: a ogni passo crede di star tentando qualcosa di nuovo.

Senza intervento esterno, questo loop può non terminare mai — e qui il numero conta: sotto auto-rinforzo greedy, il tempo atteso di uscita da uno stato ripetitivo è infinito (arXiv 2512.04419).

Le mitigazioni sono l’imposizione esterna di terminazione: una no-progress rule che ferma dopo N passi senza un nuovo segnale (un nuovo test che passa, un nuovo file rilevante), la deduplicazione che impedisce di rieseguire la stessa coppia tool + argomenti, e un tetto duro max_steps. Sono tre modi diversi di dire la stessa cosa di Lyapunov: se non puoi garantire che qualcosa scenda, garantisci almeno che il tempo finisca.

Esempio 4: la controllabilità del prompt, dove la ricerca è formale

Gli esempi precedenti sono analogie di progetto. Questo è un caso dove esiste ricerca quantitativa vera, ed è giusto separarlo. Il lavoro What’s the Magic Word? A Control Theory of LLM Prompting (Bhargava, Witkowski, Looi, Thomson, arXiv:2310.04444, 2023-2024) formalizza il modello linguistico autoregressivo come sistema dinamico stocastico discreto: lo spazio degli stati è il vocabolario, il prompt è un control input, e si studia il reachable set — l’insieme degli output raggiungibili da uno stato iniziale scegliendo opportunamente il prompt. Introduce la nozione di k-epsilon-controllability: il modello è controllabile se meno di una frazione epsilon dei target resta irraggiungibile con prompt di lunghezza fino a k token.

Il risultato empirico: su Wikitext, il token corretto successivo è raggiungibile almeno il 97% delle volte con prompt di al più dieci token, e i settantacinque token più probabili restano raggiungibili almeno l’85% delle volte. Questo è un fatto misurato, con una definizione di controllabilità presa di peso dalla teoria del controllo.

Va però capito per quello che è: riguarda la controllabilità del decoding del prossimo token via prompt, non la stabilità del loop multi-step dell’agente. È controllo applicato agli LLM al livello del singolo passo di generazione, non una garanzia sull’anello agentico. La distinzione è la differenza tra “posso steerare l’output immediato” e “il loop converge” — due affermazioni diverse, di cui solo la prima ha qui un numero.

Esempio 5: il guadagno, con i numeri

L’overshoot da guadagno alto suona astratto finché non lo si guarda con dei numeri, quindi facciamolo — restando consapevoli che è un modello-giocattolo, un’illustrazione del meccanismo, non una misura di un agente reale.

Immagina di poter quantificare “quanto un agente è lontano dal finire” con un singolo numero, l’errore $e$ , che parte da $e_0 = 100$ (cento unità di lavoro residuo) e deve arrivare a zero.

A ogni passo l’agente osserva l’errore e applica una correzione proporzionale: riduce l’errore di una frazione $K$ — il guadagno. La dinamica è $e_{t+1} = e_t - K \cdot e_t = (1 - K)\, e_t$ . In parole povere, l’errore al prossimo passo è l’errore di adesso moltiplicato per $(1 - K)$ , e tutto il comportamento dipende da quel fattore.

Con un guadagno moderato, diciamo $K = 0{,}5$ , l’errore dimezza a ogni passo: 100, 50, 25, 12,5, e converge dolcemente a zero. È il caso sano: l’agente corregge in proporzione sensata, ogni passo migliora, e la quantità di errore è una funzione di Lyapunov che scende monotona.

Con un guadagno troppo alto, diciamo $K = 1{,}8$ , succede il disastro: $1 - K = -0{,}8$ , quindi l’errore diventa 100, poi $-80$ , poi $+64$ , poi $-51{,}2$ . In parole povere, l’agente scavalca lo zero a ogni passo — corregge così tanto da finire dall’altra parte — e i segni alternati sono l’oscillazione.

Se $|1 - K| > 1$ (cioè $K > 2$ ) l’errore cresce in ampiezza a ogni passo: è la divergenza. La soglia di stabilità di questo sistema-giocattolo è netta: $0 < K < 2$ . Sotto $1$ converge dolce, tra $1$ e $2$ converge oscillando, sopra $2$ diverge.

Tradotto: un agente che, di fronte a un piccolo errore, applica una correzione enorme (riscrive l’intera funzione per un typo) è un sistema con $K$ alto. Scavalca l’obiettivo, oscilla, e se il guadagno è abbastanza alto diverge. La cura è la stessa del controllo: abbassare il guadagno — fare correzioni proporzionate all’errore, non massimali.

Nessun agente reale ha un $K$ scritto da qualche parte, e questo modello-giocattolo non pretende di misurarlo. Ma il comportamento — correggo troppo, scavalco, oscillo — è leggibile esattamente con questa lente, e questo è ciò che la rende una griglia diagnostica utile: dà un nome preciso a un fallimento che altrimenti resterebbe “l’agente fa cose strane”.

Applicazioni pratiche

Design di harness. Le stopping conditions, la deduplicazione, la no-progress detection, i checkpoint umani non sono dettagli implementativi: sono l’imposizione esterna di stabilità e terminazione su un sistema che da solo non le garantisce.

Permessi e sandbox sono vincoli nello stile MPC. Quando progetti un harness — argomento delle Parti applicative su harness engineering (in preparazione) — stai progettando il controllore esterno che rende governabile un plant intrinsecamente imprevedibile.

Debugging di agenti che oscillano o divergono. Il vocabolario del controllo — overshoot, oscillazione, ritardo, windup, divergenza — è una griglia diagnostica.

Trasforma “l’agente fa schifo su questo task” in “l’agente ha overshoot da guadagno alto e ritardo eccessivo nel feedback”, che è azionabile: sai cosa cambiare — correzioni più piccole, feedback più frequente — invece di limitarti a riscrivere il prompt e sperare.

Plan-execute con ri-pianificazione. Adottare il pattern MPC — pianifica, fai un passo, osserva, ri-pianifica — invece di piani monolitici è una delle leve più alte per la robustezza di un agente.

È la traduzione diretta di sessant’anni di esperienza del controllo nel governare sistemi il cui modello è approssimato: il piano lungo eseguito alla cieca è la cosa che il controllo ha imparato a non fare già negli anni Sessanta, e l’MPC è la risposta che ha trovato.

Dove si rompe

Questa è la sezione che tiene onesto il capitolo, e va presa sul serio quanto le precedenti. Le analogie precedenti sono utili proprio nella misura in cui si sa dove smettono di valere.

La maggior parte di queste è analogia, non teorema. Va ripetuto perché è facile scivolare. Nessuno ha dimostrato un teorema di stabilità di Lyapunov per un agente basato su un modello linguistico nel senso forte. Quando dico “l’agente che oscilla ha guadagno alto”, uso il vocabolario del controllo come lente diagnostica, non come misura. I teoremi del controllo valgono su sistemi formali — equazioni differenziali, sistemi lineari, plant modellati — e la loro applicazione a un LLM in loop è ispiratrice, non provata.

La distinzione tra le due fonti formali del capitolo e il resto è esattamente questa: Bhargava et al. ed Eslami & Yu formalizzano un oggetto (il decoding, l’architettura agentica) e provano o definiscono qualcosa su quell’oggetto formalizzato; le analogie PID, Lyapunov, MPC, Kalman applicate al comportamento dell’agente sono principi di progetto utili che non hanno, allo stato del 2026, una controparte dimostrata.

Dove c’è ricerca formale, e fin dove arriva. Il framework di Eslami & Yu (A Control-Theoretic Foundation for Agentic Systems, arXiv:2603.10779, 2026) modella i sistemi agentici come augmented closed-loop dynamical systems — sistemi dinamici ad anello chiuso aumentati — e formalizza l’agency come hierarchical runtime decision authority: la capacità dell’agente di aggiustare a runtime i parametri di controllo, commutare strategie, invocare tool, ricalibrare obiettivi. Lo stato aumentato include stati fisici, memoria interna, output dei tool, variabili di design, tutti evolventi come sistema accoppiato.

È un lavoro serio e prezioso, ma è dichiaratamente fondazionale: stabilisce un framework e un linguaggio, non prova garanzie di stabilità per ogni architettura agentica reale. Citarlo come “esiste un framework di controllo per gli agenti” è corretto; citarlo come “è dimostrato che gli agenti sono stabili” sarebbe falso.

Lyapunov non garantisce la terminazione del loop. La confusione più pericolosa. Non si dimostra una funzione di Lyapunov per un LLM, quindi non si conclude che il loop termina.

Si progetta un monitor che misura una quantità e ferma; oppure si impone un budget. La garanzia, quando c’è, è dell’harness, non del modello. Chi crede che “tanto il modello converge da solo” costruisce agenti che girano per sempre.

Il prompt engineering non è controllo dimostrato del loop. Bhargava et al. formalizzano la controllabilità del next-token via prompt — un risultato reale, con un numero.

Estenderlo a “quindi posso controllare l’intero loop multi-step dell’agente” è uno scivolamento: la reachability del prossimo token non è la stabilità dell’anello su cento passi. Sono due affermazioni di portata diversa.

Non confondere controllo e RL. Vedi controllo-vs-rl: la scelta tra i due dipende da modello noto contro appreso. Questo capitolo applica il controllo all’agente; non sta dicendo che controllo e RL sono intercambiabili. Tenere distinte le due cose evita di prendere lo strumento sbagliato.

Non confondere i due loop. Il loop di addestramento (RLHF, pesi che cambiano) e il loop di runtime (pesi congelati, agente che lavora) sono oggetti diversi su scale di tempo diverse.

Tutto questo capitolo parla del secondo. Applicare ragionamenti del runtime all’addestramento, o viceversa, produce sciocchezze.

Il setpoint è un’illusione di chiarezza. È facile credere di avere un setpoint quando si ha solo una direzione. “Migliora le performance”, “rendi il codice più pulito”, “rispondi bene” non sono setpoint: sono aspirazioni. Un controllore senza un setpoint verificabile non sa quando fermarsi, e un agente con un obiettivo non misurabile non è governabile, per quanto buono sia il modello.

Il difetto qui non è del controllo come lente — la lente fa esattamente il suo lavoro, segnalando che manca il setpoint — ma di chi ha disegnato il task. La maggior parte degli agenti che “non funzionano” non hanno un problema di controllore: hanno un problema di obiettivo mal posto.

L’autorità a runtime è un’arma a doppio taglio. L’angolo dell’agente che riprogetta sé stesso (Eslami & Yu) spiega una capacità reale, ma non va letto come una garanzia che più autonomia sia meglio. Più l’agente può cambiare le proprie regole a runtime, più è espressivo e più è difficile da stabilizzare: nel controllo, un sistema in cui i parametri cambiano rapidamente quanto lo stato è notoriamente arduo da rendere stabile.

Concedere autorità a runtime è una scelta di design con un costo in governabilità, non un bene gratuito. La regola del controllo — fai cambiare i parametri più lentamente di quanto lo stato si assesti — è il contrappeso da tenere a mente.

L’agente non è il plant pulito del controllo. Il controllo classico assume un plant con dinamica descrivibile, anche se incerta. Un LLM in loop è molto più imprevedibile: la sua “dinamica” è il comportamento di una rete neurale enorme, non modellabile con equazioni del moto.

Questo è il motivo per cui le garanzie del controllo non si trasferiscono: l’oggetto è troppo lontano dalle ipotesi dei teoremi. Le analogie restano utili come griglia di progetto proprio perché non pretendono di essere di più — e tutta la sezione precedente è servita a tenere ferma questa distinzione.

Collegamenti

Controllare un sistema: plant, controller, sensore, attuatore — il vocabolario di base (plant, controllore, sensore, attuatore, setpoint, anello aperto e chiuso) che questo capitolo mappa sull’agente.
PID senza formalismo pesante — il pensiero presente-passato-tendenza e il windup, trasposti come griglia diagnostica per gli agenti.
Lyapunov a intuizione: energia che scende — la “quantità che decresce” come principio di progetto per garantire progresso e terminazione del loop.
Robustezza a rumore, incertezza e disturbi — progettare agenti per l’intervallo di condizioni avverse, non per il caso felice.
Optimal control: costo, dinamica, vincoli — rendere esplicito il costo che l’agente minimizza (token, passi, ampiezza del diff), non solo il setpoint che raggiunge.
Receding horizon: planning, vincoli e ri-ottimizzazione — il pattern pianifica-agisci-osserva-ripianifica, l’analogia più stretta con il modo in cui un agente robusto procede.
Stimare stato nascosto con modello e misure rumorose — il belief dell’agente sullo stato del mondo come stima predici-correggi da fonti incerte.
Controllo classico, RL e dove si sovrappongono — la scelta tra vincolare con regole e lasciare appreso, dal lato del design dell’agente.
Agent loop, monitoring, escalation, human-in-the-loop — la cornice cibernetica più ampia di cui questo capitolo è la controparte ingegneristica; leggerli in sequenza dà cornice e attrezzi.
Cosa posso misurare, cosa posso governare — osservabilità e controllabilità, la radice del problema “l’agente vede ciò che gli serve?”.
Overshoot, ritardo, oscillazioni, divergenza — il catalogo delle patologie del loop, da cui prende i nomi la griglia diagnostica delle oscillazioni agentiche.

Per andare oltre

Bhargava, A. et al., “What’s the Magic Word? A Control Theory of LLM Prompting” (arXiv:2310.04444, 2023-2024). Il lavoro che formalizza l’LLM come sistema dinamico controllabile e misura la reachability del prompt. La fonte da leggere per capire dove il controllo tocca davvero gli LLM, e con quali limiti.
Eslami, A. & Yu, J., “A Control-Theoretic Foundation for Agentic Systems” (arXiv:2603.10779, 2026). Il framework che modella l’agente come sistema ad anello chiuso aumentato, con l’agency come autorità decisionale gerarchica a runtime. Fondazionale: per chi vuole il quadro formale.
Anthropic, “Building effective agents” (engineering blog, dicembre 2024). La definizione operativa di agente vs workflow, con ground truth a ogni passo, stopping conditions e guardrail. Lettura di riferimento per il lato pratico del design.
“Solving LLM Repetition Problem in Production” (arXiv:2512.04419, 2025). Il risultato sull’escape time infinito dagli stati ripetitivi sotto greedy decoding: il fondamento del perché il budget esterno non è opzionale.
“Autonomous Control Leveraging LLMs: An Agentic Framework for Next-Generation Industrial Automation” (arXiv:2507.07115, 2025). Un caso in cui agenti LLM e controllo classico convivono, con fallback conservativo e operatore umano: il PID e la robustezza visti in un sistema reale.