Perché la teoria dei sistemi serve per capire agenti e deployment

Nove capitoli hanno costruito nove lenti. Questo le punta tutte sullo stesso oggetto — un agente che scrive codice — e mostra che ciascuna cambia una decisione concreta di chi quel sistema lo progetta, lo valuta o lo debugga.

Perché questo capitolo

Una teoria si misura da una cosa sola: cosa permette di fare. Non da quanto è elegante, non da quanti nomi introduce. Da quante decisioni, prese su un caso reale, sarebbero state diverse senza di lei.

La Parte IX ha consegnato nove attrezzi. Sistema aperto e sistema chiuso. Stato e traiettoria. Equilibrio, stabilità, attrattori. Osservabilità e controllabilità. Feedback e feedforward. Modelli descrittivi, predittivi, prescrittivi. Riduzionismo e olismo. La scelta del confine. Nove capitoli, ognuno autonomo, ognuno con il suo esempio. Ma un set di cacciaviti non è ancora un lavoro: serve una mano che li impugni tutti, sullo stesso pezzo, nello stesso pomeriggio. Questo è il capitolo che li impugna.

L’oggetto su cui li punteremo è un sistema agentico: un agente che scrive codice, del tipo di Claude Code o della modalità agent di Cursor. Sotto il cofano non è una cosa sola. È un modello di linguaggio, un runtime che lo circonda, una manciata di strumenti, una memoria, un ambiente che cambia, e un utente che dà ordini e corregge. La tesi del capitolo è che questo oggetto è un sistema nel senso tecnico dei nove capitoli precedenti — e che trattarlo come tale non è un esercizio accademico, ma il modo per smettere di debuggare al livello sbagliato.

Scegliere l’agente coding come oggetto non è arbitrario. È il sistema agentico più diffuso e meglio osservabile del 2026: chi scrive software ci lavora ogni giorno, ne vede i log, ne tocca i fallimenti con mano. Ma quasi tutto ciò che il capitolo dice si trasferisce ad altri sistemi agentici — un assistente che gestisce email e calendario, un agente di ricerca, un browser agent. Cambiano i tool e l’ambiente; restano il loop, lo stato, il feedback, il confine. L’agente coding è l’esempio concreto attraverso cui guardare; la lente che si affina guardandolo serve poi altrove.

C’è un movimento che chiunque abbia lavorato con un agente ha fatto almeno una volta. L’agente fa qualcosa di assurdo. Si apre il log, si trova la chiamata di tool che è andata storta, e si conclude: “il modello ha sbagliato”. Ma il modello è un componente. Il difetto, molto spesso, non è nel componente: è nel loop che lo contiene, nel confine che è stato tracciato male, nella mancanza di sensori che renda lo stato visibile, nella dinamica che ha spinto il sistema in una regione da cui non sa uscire. Senza il livello sistema, queste cause restano invisibili — e si itera all’infinito sul pezzo sbagliato. Quello che segue è il “cosa portarsi a casa” della Parte IX: non nove nozioni, ma una griglia di lettura.

C’è anche una ragione economica per cui questo livello conta. Debuggare al livello sbagliato non è solo inelegante: costa. Cambiare modello è un esperimento lento e caro, e se la causa era nel loop quel cambiamento non risolve nulla — al massimo sposta il sintomo. Riscrivere il prompt del task, sperando che basti, è il modo più comune di girare in tondo. La griglia di lettura sistemica è, prima di tutto, un modo di non sprecare iterazioni: instrada la prima ipotesi verso il livello che ha più probabilità di contenere la causa. Non garantisce di indovinare, ma cambia l’ordine in cui si cerca — e l’ordine è quasi tutto, quando ogni tentativo costa tempo e denaro.

Contesto

Questo è un capitolo-ponte, e i ponti hanno una forma particolare. Non introducono un concetto nuovo: collegano concetti già introdotti e mostrano che convergono. Per questo la sua struttura non segue alla lettera quella di un capitolo di contenuto standard. La sezione “L’intuizione” è breve, perché l’intuizione di ogni singolo pezzo è già stata costruita altrove; il cuore del capitolo è invece una sequenza di nove lenti, una per capitolo della Parte IX, ciascuna applicata allo stesso sistema agentico.

Se non hai letto i nove capitoli precedenti, questo si può comunque seguire: ogni lente ricapitola in due righe il concetto che usa. Ma il capitolo dà il meglio dopo quei nove, perché il suo scopo non è insegnare i concetti da zero — è mostrare che si applicano tutti allo stesso oggetto, e che applicati insieme valgono più che applicati separati. Un lettore che arriva qui freddo troverà una buona panoramica; un lettore che arriva dopo la Parte IX troverà la conferma che quegli attrezzi, raccolti, formano un mestiere.

Il vocabolario che useremo non nasce con l’AI. La teoria dei sistemi si forma a metà Novecento da radici parallele: la General System Theory del biologo austriaco Ludwig von Bertalanffy (1901-1972), che in un saggio del 1950 definisce l’organismo vivente come un sistema aperto; la cibernetica del matematico statunitense Norbert Wiener (1894-1964); la system dynamics dell’ingegnere Jay Forrester (1918-2016). Nessuno di loro pensava a un agente LLM. È esattamente questo il punto interessante: un vocabolario costruito per organismi, termostati e catene di montaggio si rivela utile per descrivere un agente che scrive codice. Quando un attrezzo nato altrove funziona qui, vale la pena chiedersi perché — e fin dove.

Il motivo per cui funziona è la stessa cosa che von Bertalanffy aveva in mente fondando la General System Theory: alcune proprietà non appartengono al materiale di cui un sistema è fatto, ma alla sua organizzazione. Un anello di feedback si comporta da anello di feedback che sia fatto di neuroni, di ingranaggi, di codice o di chiamate a un LLM. Uno stato è uno stato, una traiettoria è una traiettoria, un confine è un confine. È questa indipendenza dal materiale che rende un capitolo-ponte come questo possibile: non stiamo prendendo a prestito metafore da discipline lontane per decorazione, stiamo riconoscendo che un agente condivide la struttura di altri sistemi anche quando non ne condivide la sostanza. E il limite del prestito sta esattamente lì: quando una proprietà dipende dalla sostanza — dalla matematica precisa di un modello dinamico — e non dalla sola organizzazione, l’attrezzo smette di trasferirsi. Questa è la linea che separa, in tutto il capitolo, l’analogia legittima dall’analogia che sfora.

Una premessa di onestà, da tenere per tutto il capitolo. Quasi tutti i legami che tracceremo sono analogie, non equivalenze formali. La teoria dei sistemi e la control theory hanno teoremi veri: il criterio di osservabilità di Kalman, la stabilità secondo Lyapunov, il criterio di Routh-Hurwitz. Quei teoremi valgono su oggetti matematici precisi — equazioni differenziali, matrici di stato, spazi metrici. Un sistema agentico LLM non è uno di quegli oggetti. Quando diremo “questo agente è instabile” non staremo invocando un teorema: staremo usando il vocabolario di un teorema come metafora operativa. La metafora è produttiva — dà nomi, suggerisce diagnosi, struttura le domande — ma non è una dimostrazione. Le linee guida editoriali di questa wiki chiamano “scivolamento” il passaggio silenzioso da analogia a equivalenza a teorema. In un capitolo che collega nove concetti tecnici a un oggetto informale, quello scivolamento è il rischio principale. Lo marcheremo, lente per lente.

Una domanda legittima, a questo punto: se quasi tutto è analogia, a cosa serve? La risposta è che un’analogia non è una verità debole — è uno strumento di un tipo diverso. Una dimostrazione chiude una questione; un’analogia produttiva ne apre una, indicando dove guardare. Quando la lente della stabilità suggerisce di cercare uno smorzatore mancante, non sta dimostrando che lo smorzatore risolverà il problema: sta dicendo dove vale la pena guardare per primo. È il valore di un’euristica, e le euristiche, in un campo dove le dimostrazioni non sono disponibili, sono ciò che separa una ricerca ordinata da un brancolare. Il capitolo va letto in questa chiave: non come un teorema generale sugli agenti, ma come una collezione di buoni punti da cui iniziare a guardare.

L’intuizione: l’agente come sistema, non come modello

Due framing per fissare l’idea, prima di entrare nel dettaglio.

Primo framing — la lista delle parti. Prendi un agente coding e smontalo. Trovi sei pezzi distinti, e nessuno dei sei, da solo, è “l’agente”:

Il modello (l’LLM, large language model — il modello di linguaggio addestrato su grandi quantità di testo che, dato un contesto, produce token). È il componente che genera. È stateless: di per sé non ricorda nulla fra una chiamata e la successiva.
L’harness, o orchestratore (il runtime di codice che avvolge il modello). Costruisce il prompt, gira il loop, interpreta le richieste di tool, applica i permessi, comprime il contesto quando si riempie. È codice, per lo più deterministico.
I tool: le azioni che l’agente può compiere sul mondo — leggere un file, lanciare un comando shell, chiamare un’API, cercare sul web.
La memoria: il contesto della sessione corrente (volatile), più eventualmente una memoria persistente (file di istruzioni come CLAUDE.md, skill, un vector store, i log delle sessioni passate).
L’ambiente: il filesystem, il repository, il sistema operativo, le API esterne, il web. Cambia mentre l’agente agisce — e cambia anche per conto suo, indipendentemente da lui.
L’utente: chi assegna il task, approva le azioni rischiose, corregge, interrompe. Non è fuori dal sistema. È dentro.

L’agente è la cosa che emerge quando questi sei pezzi vengono chiusi in un loop e lasciati interagire. Non è uno dei sei. È la loro interazione.

Vale la pena fermarsi un istante su questa lista, perché il modo in cui la si legge cambia tutto ciò che segue. Letta come un elenco di parti, sembra un diagramma di architettura software qualunque. Letta con l’occhio della teoria dei sistemi, dice qualcosa di più: questi sei pezzi non sono tutti dentro il sistema allo stesso modo. Modello, harness, tool e memoria sono componenti — li si progetta, li si controlla, li si può sostituire. L’ambiente è parte del sistema nel senso che il comportamento dipende da lui, ma non lo si controlla. L’utente è dentro il loop ma è anche, in un certo senso, fuori: è la fonte degli obiettivi. La teoria dei sistemi insegna a non appiattire queste differenze. Capire quale pezzo controlli, quale subisci e quale ti dà gli scopi è il primo atto di analisi — ed è già una decisione di confine, la Lente 8 in anticipo.

Secondo framing — il test di sostituzione. Immagina di sostituire un pezzo per volta tenendo fissi gli altri cinque. Cambia il modello, tieni harness, tool e ambiente: il comportamento cambia, ma resta riconoscibilmente “lo stesso agente con un cervello diverso”. Cambia l’harness, tieni il modello: a volte cambia di più che cambiando il modello. Un modello forte dentro un harness scadente dà un sistema scadente; un modello mediocre dentro un harness ben disegnato può dare un sistema sorprendentemente solido. Questo test mostra che il comportamento osservabile non è una proprietà del modello: è una proprietà del sistema. È esattamente la definizione di sistema data nel primo capitolo della Parte IX, Sistema, ambiente, confine, stato: un insieme di parti in relazione il cui comportamento non si legge nelle parti prese da sole.

Un terzo framing — il livello di descrizione. C’è un modo rapido per sentire se si sta ragionando al livello giusto: contare i sostantivi. “Il modello ha allucinato un nome di funzione” è una frase a un sostantivo — parla di un componente. “L’agente è entrato in un loop dopo che il tool ha restituito un errore e la compaction ha tagliato il contesto rilevante” è una frase a quattro sostantivi, e tre di quei sostantivi non sono il modello. La seconda frase è al livello di sistema. Quasi sempre, il difetto che importa si descrive con la seconda, e si cura con la seconda. La teoria dei sistemi è, in fondo, l’abitudine a non fermarsi alla frase a un sostantivo.

Tenuti questi tre framing, le nove lenti che seguono diventano nove modi di guardare lo stesso oggetto. Le presento nello stesso ordine dei nove capitoli della Parte IX, perché ogni capitolo aveva costruito il concetto che la lente corrispondente adesso usa.

Ecco la mappa di cosa segue. Ognuna delle nove lenti prende un capitolo della Parte IX e lo punta sul sistema agentico:

Sistema aperto — l’agente scambia di continuo con l’ambiente: non è riproducibile per default e ha una superficie d’attacco.
Stato e traiettoria — lo stato di un agente è più del context window; una sessione è un cammino in uno spazio.
Stabilità e attrattori — un loop agentico può convergere, divergere, oscillare, restare intrappolato.
Osservabilità e controllabilità — le radici dell’interpretabilità e dello steering, lette come due domande gemelle.
Feedback e feedforward — ReAct e RLHF come anelli di feedback; il prompt come anticipazione.
Modello del mondo — l’LLM è esso stesso un modello, wrong but useful; white box fisico, black box epistemico.
Riduzionismo e olismo — l’interpretabilità meccanicistica come programma riduzionista, e i suoi limiti; l’emergenza.
Il confine del sistema — dove lo si traccia cambia eval, sicurezza e attribuzione di responsabilità.
Sistemi multi-agente — più agenti producono proprietà che nessuno di loro ha da solo.

Dopo le nove lenti, una sezione le fonde in una checklist operativa — la cassetta degli attrezzi.

Una nota su come leggere le nove sezioni che seguono. Ogni lente ha la stessa forma: ricapitola in due righe il concetto del capitolo Parte IX da cui viene, poi lo applica al sistema agentico, poi — ed è la parte che conta di più — dichiara con precisione di che classe è il legame. La classe è quasi sempre la stessa, analogia, e questo va detto ogni volta perché la ripetizione è ciò che impedisce lo scivolamento. Un capitolo che dicesse “ricordate, sono analogie” una volta sola, in apertura, e poi parlasse per dodicimila parole come se fossero teoremi, avrebbe fallito il suo compito più importante.

Lente 1 — Il sistema AI come sistema aperto

Il capitolo Sistemi aperti, chiusi, dissipativi distingue un sistema isolato da uno che scambia di continuo con l’esterno. Un sistema agentico è aperto, e in modo non marginale.

Scambia informazione in entrata a ogni passo: legge file, riceve l’output dei tool, riceve i messaggi dell’utente, fa retrieval. Scambia in uscita: scrive file, lancia processi, modifica un repository, chiama API che cambiano stato altrove. Non è mai isolato, nemmeno per un’iterazione. Bertalanffy descriveva l’organismo vivente come un sistema che non raggiunge mai un equilibrio statico ma si mantiene in uno steady state — uno stato apparentemente costante tenuto in piedi da un flusso continuo di materia ed energia. Un agente in esecuzione, vista la cosa da abbastanza lontano, gli somiglia: non ha uno “stato finale di riposo” durante il task, ha una traiettoria che attraversa l’ambiente e si nutre di ciò che ne riceve. È un’analogia, e va presa come tale: l’agente non ha metabolismo, non c’è negentropia termodinamica, non c’è membrana cellulare. Ciò che si trasferisce non è la biologia, è la forma logica: un sistema il cui comportamento ha senso solo includendo i flussi che lo attraversano.

Tre conseguenze pratiche dell’apertura, tutte cose che mordono in produzione.

La prima: un sistema aperto non è riproducibile per default. Lancia lo stesso task due volte e ottieni due traiettorie diverse. L’ambiente nel frattempo è cambiato — il file che dovevi modificare è già stato modificato la prima volta. Le API rispondono in modo diverso. Il sampling del modello è stocastico. La riproducibilità, in un sistema aperto, non è un punto di partenza: è qualcosa che si costruisce a fatica, con seed fissi, sandbox e snapshot dell’ambiente. Chi assume di averla gratis sta debuggando un sistema diverso da quello che crede.

La seconda: l’ambiente è co-protagonista, non sfondo. Una traiettoria fallita non è necessariamente colpa di una decisione dell’agente. L’ambiente può essere cambiato sotto i suoi piedi — un test diventato flaky, un’API andata in timeout, un file spostato da un altro processo. Trattare l’ambiente come una costante è il modo più rapido per attribuire all’agente errori che non sono suoi. È anche, in negativo, un argomento per la sandbox: dare all’agente un ambiente il più possibile isolato e stabile non è solo una misura di sicurezza, è un modo di ridurre il numero di variabili fuori controllo — e quindi di rendere il sistema più analizzabile. Un ambiente meno aperto è un sistema più vicino a quello chiuso, e i sistemi chiusi si ragionano meglio.

La terza: il confine input/output è poroso, e questo è una superficie d’attacco. L’output di un tool che rientra nel contesto è input che l’agente non ha generato e non controlla. Se quel tool ha letto una pagina web o un file che contiene istruzioni ostili, quelle istruzioni entrano nel sistema attraverso un canale legittimo. È il meccanismo della indirect prompt injection: l’iniezione indiretta di istruzioni tramite contenuti che l’agente legge nel corso del lavoro. L’apertura, che è ciò che rende l’agente utile, è anche ciò che lo rende attaccabile. Non si può avere l’una senza l’altra.

C’è un corollario che vale la pena rendere esplicito, perché collega questa lente alla distinzione fondante della Parte IX. Un sistema chiuso si può analizzare una volta sola: ne fai il modello, lo verifichi, hai finito. Un sistema aperto no — il suo comportamento dipende da un ambiente che continua a cambiare, quindi l’analisi non si conclude mai del tutto. Per un agente in produzione questo significa che non esiste un “test di accettazione” definitivo. Esiste un monitoraggio continuo, perché il sistema con cui hai a che fare oggi non è esattamente quello di ieri: l’ambiente è scivolato sotto di lui. Chi tratta un agente come un artefatto da collaudare e archiviare sta applicando il modo di pensare giusto per i sistemi chiusi a un sistema che chiuso non è.

Lente 2 — Lo stato di un agente, la traiettoria di una sessione

Il capitolo Stato, transizione, traiettoria parte da un’idea: per predire dove va un sistema non serve raccontarne la storia, basta un riassunto sufficiente del presente — lo stato. Per una pallina in una valle bastano posizione e velocità adesso; da quale cima sia partita due ore fa è irrilevante.

Domanda secca: qual è lo stato di un agente a metà sessione?

La risposta ingenua è “il contesto” — la finestra di token che il modello vede. Ma è incompleta, e l’incompletezza è proprio la fonte di una classe di bug. Lo stato effettivo del sistema agentico ha almeno quattro componenti:

Il contenuto del context window: ciò che il modello, in quell’istante, ha davanti.
Lo stato dell’ambiente: quali file sono stati modificati, quali processi avviati, su quale branch git si è.
Lo stato della memoria persistente: cosa è stato scritto su CLAUDE.md, cosa è finito nel vector store.
Lo stato dell’harness: il contatore di iterazione, il budget residuo, i permessi già concessi in questa sessione.

Una sessione è una traiettoria in questo spazio degli stati: una sequenza di transizioni stato → azione → nuovo stato. È la mossa centrale del capitolo: guardare la sessione come un cammino in uno spazio, non come una lista di cose fatte. Il cambiamento per il debugging è concreto. Invece di chiedere “quale singola azione era sbagliata?”, si chiede “in che regione dello spazio degli stati è finito il sistema, e attraverso quale cammino ci è arrivato?”. La seconda domanda porta alla causa; la prima spesso porta solo al sintomo.

Questo riformula anche cosa significa “fare un checkpoint” di un agente. Un checkpoint, nella lente dello spazio degli stati, è il salvataggio di un punto della traiettoria a cui si può tornare. Perché funzioni davvero deve catturare tutto lo stato — non solo il context window, ma anche lo stato dell’ambiente: i file com’erano, il branch git, i processi. Un checkpoint che salva solo il contesto e ignora l’ambiente riporta il modello indietro nel tempo ma lascia il mondo avanti, e l’agente riparte da uno stato incoerente, peggiore di quello che si voleva ripristinare. È un errore comune negli harness immaturi, e la lente lo rende ovvio: lo stato è quattro cose, il checkpoint deve salvarle tutte e quattro.

C’è poi un fallimento specifico che questa lente rende leggibile: la violazione della proprietà di Markov. Quella proprietà, descritta in Stato, transizione, traiettoria, dice che lo stato presente è un riassunto sufficiente: il futuro dipende dal presente, non dalla storia. La compaction del contesto — la compressione che l’harness applica quando la finestra si riempie — può romperla. Se la compaction butta via un’informazione che serviva, lo stato visibile al modello non è più un riassunto sufficiente della storia. Il sistema diventa non-markoviano, e questo si manifesta in un modo molto riconoscibile: “l’agente ha dimenticato cosa stava facendo”. Non è un capriccio del modello. È una proprietà strutturale del sistema, prevista dal vocabolario.

C’è anche un’asimmetria utile da notare fra stato visibile e stato effettivo. Il modello vede solo il context window — è il suo unico accesso allo stato. Ma lo stato effettivo del sistema include l’ambiente e la memoria persistente, che il modello non vede direttamente: li conosce solo per quello che ne è finito nel contesto. Questa è una situazione che la Lente 4 chiamerà col suo nome — stato parzialmente osservabile dal punto di vista del modello — e spiega un’intera classe di errori in cui l’agente agisce su una rappresentazione del mondo che è ferma a qualche passo fa. Un file modificato da un processo esterno, un branch git cambiato, un test diventato flaky: tutte cose vere dello stato effettivo che il modello non ha modo di sapere finché un tool non gliele riporta nel contesto. Progettare bene un agente significa, in buona parte, mantenere lo stato visibile allineato con quello effettivo.

Lente 3 — Stabilità, attrattori, divergenza di un loop agentico

Il capitolo Equilibrio, stabilità, attrattori fornisce tre nomi precisi. Un equilibrio è uno stato che il sistema, lasciato a sé, non abbandona. La stabilità è la risposta alla domanda: se lo disturbi, ci ritorna o se ne allontana? Un attrattore è una regione verso cui le traiettorie vicine convergono.

Un loop agentico ha quattro comportamenti che questi tre nomi descrivono con precisione sorprendente:

Divergenza. L’agente si allontana sempre più dal task. Ogni iterazione aggiunge complessità, apre file nuovi, cambia approccio. Non converge a niente.
Oscillazione, o ciclo limite. L’agente alterna due stati. Fa la modifica A, un test fallisce, torna a B, un altro test fallisce, torna ad A. È il fallimento agentico più raccontato.
Attrattore indesiderato. L’agente resta intrappolato in una regione. Ripete la stessa chiamata di tool con lo stesso identico errore tre, quattro, cinque volte. La regione “riprova la stessa cosa” si comporta come un attrattore: le piccole variazioni di contesto fra un tentativo e l’altro non bastano a farlo uscire.
Equilibrio desiderato. Il task è completo e l’agente si ferma. È l’attrattore che vogliamo — e progettare bene un agente significa, in larga parte, rendere questo l’unico attrattore facilmente raggiungibile.

Qui la dichiarazione di classe è obbligatoria, perché è il punto dove lo scivolamento è più facile. Quando diciamo che un loop agentico “è instabile”, è un’analogia, non un teorema. Non esiste una matrice di stato di cui calcolare gli autovalori. Non esiste una funzione di Lyapunov da esibire. La control theory fornisce quei criteri su sistemi dinamici formali; un loop di chiamate LLM non è uno di quei sistemi. Chi dicesse “ho dimostrato che l’agente è stabile” starebbe usando una parola che non gli appartiene.

Detto questo, l’analogia è produttiva — ed è per questo che la usiamo. Suggerisce due categorie di meccanismi che altrimenti non si vedrebbero come una coppia. Da un lato gli smorzatori: tutto ciò che riporta il sistema verso l’equilibrio desiderato. Un tetto massimo di iterazioni. Un checkpoint a cui tornare. Un’istruzione esplicita “cambia una cosa per volta”. Un reset del contesto. Dall’altro gli amplificatori: tutto ciò che spinge il sistema lontano. Un contesto che cresce e si confonde a ogni passo. Un errore che, restando nel contesto, viene riletto e ri-citato dal modello, rinforzandosi. Progettare un agente stabile, in questa lente, ha una formulazione compatta: mettere più smorzatori che amplificatori. Non è un teorema. È una direzione di progetto, ed è già abbastanza.

Una nota sull’amplificatore più insidioso, perché è quello che si dimentica più spesso. Il context window stesso è un amplificatore quando contiene gli errori dei passi precedenti. Un agente che ha fallito tre volte ha tre fallimenti scritti nel suo contesto, e il modello — che predice il token successivo a partire da ciò che vede — trova nel contesto un pattern di fallimento e lo continua. Il sistema, in pratica, si auto-convince di essere un sistema che fallisce. È un loop di feedback positivo nel senso tecnico di Feedback vs feedforward: l’uscita rinforza l’ingresso nella stessa direzione, e la deviazione cresce. Lo smorzatore corrispondente è brutale ma efficace: ripulire il contesto, ripartire da uno stato sano con il solo riassunto di cosa è stato già provato. Non è il modello che “si arrende”: è il sistema che si è messo in un attrattore, e da quell’attrattore si esce solo cambiando lo stato, non insistendo.

Lente 4 — Osservabilità e controllabilità: le radici di interpretabilità e steering

Il capitolo Osservabilità e controllabilità presenta le due domande gemelle poste da Rudolf Kalman (ingegnere e matematico ungherese-statunitense, 1930-2016) nel 1960. Guardando solo le uscite di un sistema, posso ricostruire il suo stato interno? Questa è l’osservabilità. Con le leve di cui dispongo, posso portare il sistema in qualunque stato voglia? Questa è la controllabilità.

Queste due domande sono le radici, spesso non riconosciute, di due grandi problemi pratici dell’AI.

Osservabilità → interpretabilità e monitoring. Il problema “non so cosa sta succedendo dentro il modello” è, alla lettera, un problema di osservabilità. Le attivazioni interne e il residual stream — il flusso di informazione che attraversa i layer del transformer — sono lo stato. I token in output sono l’uscita che si può misurare. La domanda “posso dedurre cosa il modello ha rappresentato internamente guardando solo ciò che produce?” è la domanda di osservabilità di Kalman, trasposta su un nuovo oggetto. La risposta, per gli LLM, è “parzialmente”. Il chain-of-thought — il ragionamento esplicitato in testo prima della risposta — rende osservabile una fetta dello stato. L’interpretabilità meccanicistica prova a strumentare il resto. Ma una fetta dello stato resta non osservabile, e questo non è un dettaglio: un sistema le cui variabili critiche non sono osservabili non è pienamente debuggabile, per costruzione.

Controllabilità → steering e alignment. Il problema “posso far comportare il modello come voglio?” è controllabilità. Le leve sono note: il prompt, il fine-tuning, l’RLHF, gli steering vector (vettori di attivazione che spostano il comportamento del modello), il system prompt. La domanda “queste leve bastano a raggiungere qualunque comportamento desiderato, ed evitare qualunque comportamento indesiderato?” è la domanda di controllabilità. La risposta onesta, allo stato del 2026, è “non lo sappiamo con certezza, e quasi sicuramente no in pieno”.

Una distinzione che la lente rende netta: controllabilità non è la stessa cosa di affidabilità. Una leva può funzionare — il system prompt cambia davvero il comportamento — e funzionare in modo poco prevedibile, con effetti collaterali che non si volevano. La control theory, sui suoi sistemi formali, distingue il fatto che una leva raggiunga uno stato dal fatto che lo raggiunga bene, senza overshoot, senza far oscillare il resto. Per un sistema agentico la traduzione è quotidiana: aggiungere un’istruzione al prompt per correggere un comportamento spesso ne perturba un altro che funzionava. Le leve di un sistema AI sono accoppiate — tirarne una muove le altre — e una buona analisi di controllabilità non chiede solo “ho una leva per questo?” ma “questa leva, tirata, cosa muove di non voluto?”.

Anche qui, la classe va dichiarata: analogia. I teoremi di osservabilità e controllabilità di Kalman valgono su sistemi lineari tempo-invarianti, dotati di una matrice di stato esplicita. Un LLM non è quello. Ciò che si trasferisce non è il teorema, è la coppia di domande — e la coppia, da sola, è già illuminante, perché separa nettamente due problemi che il dibattito pubblico confonde di continuo. “Non vedo lo stato” è un problema di sensori. “Vedo lo stato ma non riesco a cambiarlo” è un problema di attuatori. Sono difetti diversi, con cure diverse. Tenere distinte osservabilità e controllabilità impedisce di proporre una cura di sensori per un problema di attuatori.

C’è infine un livello che va oltre il modello. L’osservabilità di un agente, e non del modello che lo abita, è soprattutto un problema di harness. I trace strutturati, il log di ogni chiamata di tool con i suoi argomenti, gli eventi di decisione: questi sono i sensori del sistema agentico. Un agente che gira senza trace è un sistema non osservabile per costruzione — e non lo si può debuggare, qualunque cosa faccia. La prima cosa che un harness serio costruisce non è una capacità: è la visibilità.

Vale la pena chiudere la lente con un’osservazione sul rapporto fra le due metà. Osservabilità e controllabilità mostra che le due domande di Kalman, su un sistema lineare, hanno una simmetria formale: sono la stessa domanda letta in due direzioni. Per un sistema AI quella simmetria formale non c’è — di nuovo, manca la matrice di stato — ma resta una simmetria pratica che vale la pena tenere a mente. Non puoi controllare bene ciò che non osservi: senza sensori sullo stato non sai se la leva che hai tirato ha avuto l’effetto voluto, e il controllo diventa cieco. E non guadagni niente a osservare ciò che non puoi controllare: vedere un comportamento indesiderato senza nessuna leva per correggerlo produce solo frustrazione documentata. Un sistema agentico ben progettato investe nelle due metà insieme — sensori e leve — perché ciascuna, da sola, rende l’altra inutile.

Lente 5 — Feedback e feedforward: ReAct, RLHF, e il prompt come anticipazione

Il capitolo Feedback vs feedforward separa due strategie opposte per tenere un sistema sul bersaglio. Il feedback misura lo scarto dal bersaglio e reagisce. Il feedforward prevede il disturbo prima che colpisca e agisce in anticipo. Un sistema agentico ne è pieno, e a più scale temporali insieme.

Il loop ReAct è feedback alla scala dei secondi. Il nome viene dal paper ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., presentato a ICLR 2023), che introduce il pattern thought → action → observation → thought: il modello produce un pensiero, compie un’azione tramite un tool, ne osserva il risultato, e quel risultato alimenta il pensiero successivo. Letto con la lente del feedback: l’observation è la misura, il thought che la segue è la correzione, lo scarto è la distanza dal task. Il contributo del paper, in termini sistemici, è proprio questo: intrecciare reasoning e azione riduce le allucinazioni e la propagazione di errori rispetto al chain-of-thought puro, perché chiude il loop con l’ambiente invece di lasciarlo aperto. Un modello che ragiona senza agire è un controllore ad anello aperto: non misura mai se ciò che pensa corrisponde al mondo.

L’RLHF (reinforcement learning from human feedback — l’addestramento che allinea il modello alle preferenze umane) è feedback alla scala dei mesi. Il modello produce output, degli esseri umani — o un reward model che li sostituisce — li valutano, il gradiente corregge i pesi. Lo scarto, qui, è “quanto l’output si discosta dalla preferenza umana”. È lo stesso schema del termostato, con una costante di tempo enormemente più lunga e un anello che passa per un processo di training.

Vedere ReAct e RLHF come lo stesso schema a scale temporali diverse non è un gioco di parole: ha una conseguenza pratica. Significa che un sistema agentico ha anelli di feedback annidati, e che ogni anello ha la sua costante di tempo. C’è l’anello dei secondi — il loop ReAct dentro una sessione. C’è l’anello dei giorni — un team che osserva i fallimenti e riscrive le skill e il CLAUDE.md. C’è l’anello dei mesi — il training che incorpora le preferenze nei pesi. Un difetto va corretto all’anello giusto: un comportamento sbagliato che si ripete in ogni sessione non si cura aspettando il prossimo training, si cura al livello delle skill; e un limite radicato nel modello non si cura riscrivendo il prompt all’infinito. Riconoscere a quale anello appartiene un problema è metà della sua soluzione, ed è la lente del feedback che fornisce la mappa degli anelli.

Il feedforward, nel sistema agentico, è tutto ciò che anticipa senza misurare. Il system prompt. Le skill. Le descrizioni dei tool. Gli esempi few-shot. Nessuno di questi reagisce a uno scarto osservato: tutti anticipano disturbi noti. “L’agente tende a fare X di sbagliato — scriviamo nel prompt di non farlo” è, letteralmente, progettazione di un controllore feedforward. Un file CLAUDE.md scritto bene è un regolatore feedforward: codifica in anticipo la conoscenza dei disturbi prevedibili.

Questa lettura ha un risvolto pratico sul mantenimento del sistema. Un controllore feedforward è buono quanto il suo modello dei disturbi, e i disturbi cambiano: nuove versioni di un tool, nuovi tipi di task, nuovi modi in cui l’agente sbaglia. Un CLAUDE.md non è un artefatto che si scrive una volta — è un modello del mondo che invecchia, e va aggiornato man mano che si osservano disturbi nuovi. Il meccanismo di aggiornamento è esso stesso un feedback, a scala lenta: si guardano i fallimenti, si aggiorna il feedforward. Feedback e feedforward, in un sistema agentico ben tenuto, non sono alternativi — sono concatenati: il feedback lento alimenta e corregge il feedforward.

La disambiguazione non è pedanteria, perché i due falliscono in modi diversi e richiedono diagnosi diverse. Il feedback può oscillare e diventare instabile se il guadagno è troppo alto o il ritardo troppo lungo — è il legame diretto con la Lente 3 e con Equilibrio, stabilità, attrattori. Il feedforward fallisce invece in silenzio: quando il modello del disturbo è sbagliato — il prompt anticipa un problema che non esiste, oppure ne ignora uno che esiste — non c’è nessun segnale di errore, perché il feedforward non misura niente. Un sistema robusto li combina deliberatamente: feedforward per i disturbi prevedibili, feedback per tutto il resto e per ciò che il feedforward ha mancato.

C’è un terzo punto che Feedback vs feedforward sottolinea e che qui torna prezioso: il ritardo nell’anello. Un feedback corregge bene solo se la misura arriva abbastanza in fretta; se fra l’azione e l’osservazione del suo effetto passa troppo tempo, la correzione si applica a uno stato che nel frattempo è già cambiato, e il sistema oscilla. In un loop agentico il ritardo ha una forma concreta: quanti passi di azione l’agente compie prima di ricevere un segnale che gli dice se sta andando bene. Un agente che scrive cinquanta righe di codice e poi lancia i test ha un anello a ritardo lungo — se sbaglia, lo scopre tardi e deve disfare molto. Un agente che scrive una funzione, la testa, scrive la successiva, ha un anello a ritardo corto e corregge presto. Accorciare l’anello — testare più spesso, verificare prima — è un intervento di stabilità che la Lente 3 e la Lente 5 indicano insieme, e che non ha nulla a che vedere con il modello: è puro disegno del loop.

Lente 6 — Il sistema AI come modello del mondo, white box e black box

Il capitolo Modelli descrittivi, predittivi, prescrittivi parte da una frase di mezzo secolo fa: “all models are wrong, but some are useful” — tutti i modelli sono sbagliati, ma alcuni sono utili. Un modello non è una copia del sistema: è un sostituto deliberatamente impoverito, costruito per rispondere a una domanda. Due ricadute su un sistema AI.

La prima: l’LLM è esso stesso un modello, nel senso tecnico del capitolo. È un sostituto compresso del testo — e, indirettamente, del mondo che quel testo descrive — costruito per una domanda precisa: “qual è il token successivo?”. È wrong: non è il mondo, è una compressione lossy del mondo filtrata attraverso il testo. Ed è, per moltissimi compiti, useful. L’errore che Modelli descrittivi, predittivi, prescrittivi mette in guardia — scambiare il modello per il sistema che modella — qui ha un nome operativo: trattare l’LLM come un oracolo invece che come un modello. Un oracolo non sbaglia; un modello sbaglia sempre, di un margine che dipende dalla domanda. Sapere quale dei due si ha davanti cambia quanta fiducia mettere nelle sue uscite.

La seconda: white box e black box. Il capitolo distingue i modelli di cui si vede il meccanismo da quelli di cui si vede solo la relazione input-output. Un LLM occupa una posizione curiosa rispetto a questa distinzione. È fisicamente white box: i pesi sono tutti lì, ogni numero è leggibile, niente è nascosto. Ma è epistemicamente black box: avere tutti i pesi non significa capire il calcolo che eseguono. È una distinzione che vale la pena tenere ferma, perché “open weights” — pesi pubblici — viene a volte confuso con “interpretabile”. Non lo è. La trasparenza dei pesi e la comprensione del comportamento sono due cose diverse, e la distanza fra loro è il problema di cui si occupa la lente successiva.

E c’è una terza ricaduta, che riguarda il sistema agentico nel suo insieme e non solo il modello. Anche l’harness è un modello — un modello del compito che l’agente deve svolgere. Le descrizioni dei tool, la struttura del prompt di sistema, le skill: tutto questo è una rappresentazione, costruita da chi progetta, di “cosa serve fare e come”. Ed essendo un modello, è wrong nel senso di Modelli descrittivi, predittivi, prescrittivi: è una semplificazione deliberata, e ci sono compiti reali che la sua semplificazione non cattura. Quando un agente fallisce su un caso che “avrebbe dovuto saper gestire”, la causa è spesso qui: non nel modello-LLM, ma nel modello-harness, che ha rappresentato il compito in modo troppo povero. È un’istanza precisa della Lente 8 — il confine del compito tracciato male — e mostra che la frase “all models are wrong” si applica due volte a un sistema agentico, una per il modello statistico e una per il modello del compito codificato nell’harness.

Lente 7 — Interpretabilità meccanicistica: un programma riduzionista e i suoi limiti

Il capitolo Riduzionismo e olismo sostiene una tesi precisa: scomporre un sistema nei suoi pezzi funziona — è la mossa che ha costruito quasi tutta la scienza moderna — ma da sola non ricostruisce mai il tutto; servono due lenti, non una. L’interpretabilità meccanicistica è il caso di prova perfetto di questa tesi applicata all’AI.

L’interpretabilità meccanicistica è un programma di ricerca che cerca di capire un modello come si capisce un programma: identificandone i componenti interni e il modo in cui si compongono. Il manifesto è Zoom In: An Introduction to Circuits (Olah et al., pubblicato sulla rivista Distill nel 2020), che pone la tesi fondante del campo: le reti neurali contengono circuiti leggibili dall’uomo, e capirli è un’impresa trattabile con gli strumenti giusti. Il vocabolario che ne è seguito — circuiti, attention head, feature monosemantiche, sparse autoencoder — è riduzionismo allo stato puro: capire il tutto smontandolo nei pezzi. È un programma legittimo, scientificamente serio, e ha prodotto risultati reali: circuiti veri, mappati e verificati, in modelli veri.

Ma lo stesso capitolo Riduzionismo e olismo annuncia il limite, e quel limite si presenta puntuale qui. Il riduzionismo si rompe quando il comportamento dipende dall’organizzazione delle parti e non dalle parti stesse. L’interpretabilità meccanicistica ha mappato circuiti autentici e resta, allo stesso tempo, lontana dallo spiegare il comportamento globale di un modello di frontiera. Questo non è un fallimento del metodo né una promessa non mantenuta: è il limite strutturale del riduzionismo, esattamente quello che il capitolo aveva previsto. La cura non è “fare più riduzionismo”: è affiancargli la lente olistica, che guarda il comportamento al livello del sistema intero.

Tradotto in termini pratici per chi costruisce: l’interpretabilità meccanicistica è uno strumento prezioso e parziale. Aiuta a capire come il modello calcola una cosa specifica, e questa è conoscenza vera. Ma sperare che, accumulando circuiti, si arrivi un giorno a una spiegazione completa del comportamento di un modello agentico è sperare che il riduzionismo superi il proprio limite — e quel limite, dice la Parte IX, non è una difficoltà tecnica che più sforzo risolverà, è strutturale. Per il monitoring di un agente in produzione questo significa che non si può aspettare la “soluzione” dell’interpretabilità: servono comunque i sensori a livello di sistema, i trace, le eval di comportamento. Le due lenti, riduzionista e olistica, non si sostituiscono — si usano insieme, ciascuna per ciò che l’altra non vede.

Da qui le capacità emergenti — ma con la classe di affermazione giusta, perché qui il rischio di overclaim è alto. L’idea che certe capacità “compaiano” superata una soglia di scala è emergenza nel senso di Riduzionismo e olismo: una proprietà del tutto che non si legge nelle parti. Solo che molte emergenze raccontate non sono emergenze. Il paper Are Emergent Abilities of Large Language Models a Mirage? (Schaeffer, Miranda, Koyejo, NeurIPS 2023) mostra che molti salti improvvisi di capacità sono artefatti della metrica scelta. Una metrica discontinua — giusto/sbagliato, tutto-o-niente — produce sui grafici un salto netto. La stessa identica capacità, misurata con una metrica continua, produce una curva liscia e prevedibile. La lezione sistemica è netta, e si lega alla Lente 4: cosa misuri determina cosa vedi. Prima di chiamare “emergente” un comportamento, controlla che non sia un artefatto dello strumento di misura. L’emergenza vera esiste — i sistemi complessi la esibiscono davvero — ma è più rara di quanto la forma dei grafici suggerisca.

Questo non è scetticismo a buon mercato sull’emergenza: è la stessa disciplina che Riduzionismo e olismo raccomanda. La lente olistica serve a vedere proprietà reali del tutto che il riduzionismo perde; ma proprio perché è la lente che “vede di più”, è anche quella che più facilmente vede cose che non ci sono. Olismo disciplinato significa esattamente questo: usare la lente del tutto, e contemporaneamente chiedersi se ciò che la lente mostra sia una proprietà del sistema o un riflesso dello strumento. Per un sistema agentico la domanda si traduce in pratica: quando qualcuno dice “questo agente ha sviluppato una capacità nuova”, la prima reazione utile non è l’entusiasmo né lo scetticismo, è guardare la metrica.

Lente 8 — Il confine del sistema: una decisione, non una scoperta

Il capitolo Scegliere il confine cambia il problema chiude la sequenza con l’idea forse più sottile della Parte IX: il confine di un sistema non si trova nella natura, lo traccia chi modella, in funzione di uno scopo — e tracciarlo male produce analisi corrette nei numeri e sbagliate nella sostanza, un errore che non lascia tracce visibili. Per un sistema AI la scelta del confine cambia tre cose, tutte concrete.

Cambia l’eval. Se il confine del sistema è “il modello”, lo valuti su benchmark — MMLU, GPQA, gli insiemi standard di domande. Se il confine è “il sistema agentico”, lo valuti su task end-to-end — SWE-bench e simili, dove conta se il problema viene risolto, non se la singola risposta è corretta. Sono due domande diverse, e danno risposte diverse. Un modello che vince i benchmark ma vive dentro un harness scadente produce un sistema scadente — e l’eval a livello modello, per costruzione, non lo cattura. Decidere il confine prima di valutare non è un cavillo metodologico: è ciò che rende l’eval informativa.

Cambia la sicurezza. Se il confine esclude i tool, l’analisi di sicurezza guarda una cosa sola: “il modello produce contenuti dannosi?”. Se il confine include tool e ambiente, la domanda diventa “il sistema può compiere azioni dannose?” — e solo allora entrano nel quadro la prompt injection, l’exfiltration di dati, il blast radius di un permesso troppo largo. Il confine decide quali minacce sono persino visibili. Una minaccia fuori dal confine scelto non viene mitigata male: non viene vista affatto.

C’è un caso particolarmente insidioso, ed è quello in cui il confine dell’analisi di sicurezza è più stretto del confine del sistema reale. Si testa il modello in isolamento, lo si trova robusto, e si dichiara sicuro il prodotto — che però in produzione ha dei tool. Il modello non è cambiato; il sistema sì. La superficie d’attacco vera è quella del sistema con i tool, e l’analisi l’ha mancata per intero non perché abbia sbagliato i conti, ma perché ha guardato dentro un confine più piccolo di quello che conta. È il modo di sbagliare che Scegliere il confine cambia il problema chiama “non lascia tracce”: tutto, dentro il confine scelto, era corretto.

Cambia l’attribuzione di responsabilità. Un agente cancella un file di produzione. Di chi è la colpa? Del modello, che ha deciso l’azione? Dell’harness, che l’ha eseguita senza chiedere conferma? Dell’utente, che aveva concesso un permesso troppo ampio? Dell’ambiente, dove quel file non era protetto contro la scrittura? La risposta dipende interamente da dove si traccia il confine del “sistema responsabile”. Non esiste una risposta naturale che la teoria possa consegnare. Esiste una scelta — e il compito di chi progetta è renderla esplicita, non lasciarla implicita e quindi indiscutibile.

Quest’ultimo punto ha un peso che va oltre il debugging. La scelta del confine, quando si parla di responsabilità, è anche una scelta su chi risponde di un danno — un tema che le normative sull’AI affrontano in modo esplicito, e che tocca compliance e contratti. La teoria dei sistemi non decide chi è responsabile: non è il suo mestiere. Ma fa una cosa preziosa a monte di quella decisione: rende visibile che una decisione c’è. Senza la lente del confine, l’attribuzione “è colpa del modello” sembra un fatto naturale; con la lente, si vede che è una scelta di dove fermare lo sguardo, e che fermarlo un passo più in là — sull’harness, sull’utente, sul progettista del sistema — è altrettanto legittimo. Un capitolo di teoria non chiude la questione della responsabilità. La apre nel posto giusto.

Lente 9 — Sistemi multi-agente e proprietà emergenti

Quando più agenti interagiscono — un supervisore con dei worker, uno swarm, una pipeline in cui ognuno passa il risultato al successivo — il sistema acquista un livello in più, e con esso proprietà che nessun agente possiede da solo. È emergenza nel senso di Riduzionismo e olismo, stavolta in forma evidente: il comportamento del collettivo non si legge nel comportamento dei singoli.

C’è una simmetria interessante con la Lente 1. Un singolo agente è già un sistema con sei componenti; un multi-agente è un sistema i cui componenti sono a loro volta sistemi. La teoria dei sistemi chiama questo gerarchia di sistemi, ed è uno dei suoi temi fondativi: un sistema a un livello è un componente al livello sopra. Ne segue una raccomandazione pratica precisa. Quando si analizza un multi-agente, conviene scegliere un livello per volta e tenerlo fermo: o si guarda il singolo agente come sistema, o si guarda il collettivo come sistema con i singoli agenti come scatole chiuse. Mescolare i due livelli nello stesso ragionamento — “questo worker ha sbagliato perché il suo modello, e anche perché il supervisore” — confonde la diagnosi. La gerarchia va salita o scesa di un gradino alla volta.

I fallimenti specifici dei sistemi multi-agente sono stati censiti. Il lavoro Why Do Multi-Agent LLM Systems Fail? (Cemri et al., 2025) propone una tassonomia, chiamata MAST, di quattordici failure mode raccolti in tre categorie: errori di specifica e di design del sistema; disallineamento fra agenti — misinterpretazione, perdita di informazione nei passaggi, loop conversazionali che non terminano; fallimenti di verifica e di terminazione. I comportamenti emergenti tipici hanno nomi propri: le cascate di errori, in cui l’errore di un agente si propaga e si rinforza lungo la rete; il monoculture collapse, in cui agenti costruiti tutti sullo stesso modello base condividono le stesse identiche vulnerabilità, così che un input che inganna uno li inganna tutti; e poi miscoordinazione, conflitto, collusione.

Notare che queste tre categorie della tassonomia MAST sono, lette con le lenti di questo capitolo, tre delle nove lenti applicate al caso multi-agente. Gli errori di specifica e design sono problemi di confine (Lente 8): si è definito male cosa ogni agente deve fare e dove finisce. Il disallineamento fra agenti è un problema di feedback (Lente 5): le interfacce fra agenti sono anelli, e anelli mal disegnati perdono informazione o oscillano. I fallimenti di terminazione sono problemi di stabilità (Lente 3): il sistema non ha un attrattore desiderato dominante, e il loop conversazionale non converge a “fatto”. La tassonomia, costruita empiricamente osservando sistemi che falliscono, ricade in modo naturale sul vocabolario della teoria dei sistemi — il che è una conferma indiretta che quel vocabolario sta cogliendo qualcosa di reale.

Il punto sistemico è controintuitivo e va detto chiaro: i sistemi multi-agente non sono più intelligenti per default. Aggiungere un agente significa aggiungere interfacce, e ogni interfaccia è un nuovo punto di feedback che può oscillare o amplificare un errore — è la Lente 5 che torna, moltiplicata. Anthropic, nel documento ingegneristico Building Effective Agents (dicembre 2024), lo formula come principio operativo: cerca la soluzione più semplice possibile, e aumenta la complessità solo quando un beneficio concreto lo giustifica — a volte la cosa giusta è non costruire un sistema agentico affatto. La lente dell’emergenza dà la ragione teorica di quel principio pratico: ogni livello in più non aggiunge solo capacità, aggiunge modi di fallire che prima non esistevano.

C’è un secondo motivo, più sottile, per cui la lente dell’emergenza è quella giusta qui. In un sistema multi-agente il confine — la Lente 8 — si moltiplica: ogni agente ha il suo confine interno, e poi c’è il confine del collettivo. Una proprietà come “il sistema termina” o “il sistema non entra in collusione” non è una proprietà di nessun singolo agente: vive solo al livello del collettivo, è emergente in senso stretto. Questo ha una conseguenza pratica precisa sull’eval. Valutare i singoli agenti uno per uno, e trovarli tutti corretti, non dimostra che il sistema lo sia — proprio perché i failure mode di terminazione e di coordinamento, nella tassonomia MAST, sono per costruzione proprietà di interazione. Un multi-agente va valutato come sistema intero, sul suo confine esterno, oppure non è stato valutato sulle cose che lo fanno fallire davvero. È la Lente 8 e la Lente 7 che lavorano insieme.

La meccanica: la cassetta degli attrezzi

Le nove lenti, messe in fila, diventano una procedura. Quando progetti un sistema agentico, o quando ne debugghi uno che ha fallito, ci sono sei domande sistemiche da porsi, in quest’ordine. Ognuna eredita da una lente della Parte IX. Non sono un rituale: sono un instradamento, un modo per portare la diagnosi al livello giusto invece che sempre, per riflesso, al modello.

Le nove lenti non diventano sei domande per caso: alcune lenti si fondono. La Lente 6 — l’LLM come modello — e la Lente 7 — riduzionismo e olismo — non sono domande operative separate, sono il modo di pensare che sta sotto a tutte le altre: ricordare che ogni descrizione del sistema, inclusa quella che la cassetta degli attrezzi produce, è essa stessa un modello impoverito. Le sei domande sono le lenti che si traducono in un’azione di verifica concreta; le altre tre sono l’atteggiamento con cui si pongono le sei. Ecco la procedura.

Qual è il confine? Cosa è dentro il sistema che sto valutando e cosa fuori? Il modello da solo? Il modello più i tool? Tutto, utente incluso? (Lente 8, da Scegliere il confine cambia il problema.) Questa domanda viene per prima perché sbagliarla invalida tutte le risposte successive: stai valutando, debuggando o mettendo in sicurezza un sistema diverso da quello che credi.
Qual è lo stato? Cosa devo conoscere, in un dato istante, per predire cosa farà il sistema? Context window, ambiente, memoria persistente, contatori dell’harness. (Lente 2, da Stato, transizione, traiettoria.) Se non sai dire qual è lo stato, non puoi ragionare sulla dinamica — puoi solo raccontare la cronaca di ciò che è successo.
Quali sono i loop di feedback? Dove c’è una misura che torna indietro a correggere? Il loop ReAct, l’RLHF, il retry su errore. E quali meccanismi sono invece feedforward — il system prompt, le skill, le descrizioni dei tool? (Lente 5, da Feedback vs feedforward.) Identificare i loop è il prerequisito per la domanda dopo.
È stabile? Le traiettorie convergono verso l’equilibrio desiderato — il task completo — o ci sono attrattori indesiderati: loop, divergenza, oscillazione? Ci sono più smorzatori o più amplificatori? (Lente 3, da Equilibrio, stabilità, attrattori.) Ricorda che “stabile” qui è un’analogia, non un teorema: la domanda guida la diagnosi, non la dimostra.
È osservabile? Guardando i trace e i log che il sistema produce, posso ricostruire perché ha fatto ciò che ha fatto? Se la risposta è no, il sistema non è debuggabile — e il primo intervento non è sul comportamento, è sui sensori. (Lente 4, da Osservabilità e controllabilità.)
È controllabile? Con le leve di cui dispongo — prompt, permessi, scelta dei tool, checkpoint, system prompt — posso portare il sistema dove voglio? Quali comportamenti restano fuori dalla mia portata, qualunque leva io tiri? (Lente 4, da Osservabilità e controllabilità.)

C’è una settima domanda, trasversale, che fa da chiusura: è aperto, e verso cosa? Quali flussi entrano dall’ambiente che non controllo — output dei tool, contenuti web, file letti? Ognuno è insieme una fonte di non-riproducibilità e una superficie d’attacco. (Lente 1, da Sistemi aperti, chiusi, dissipativi.)

L’ordine delle domande non è arbitrario, e vale la pena spiegarlo. Il confine viene per primo perché definisce di che sistema stiamo parlando: ogni risposta successiva dipende da quel perimetro. Lo stato e i loop vengono subito dopo perché descrivono com’è fatto il sistema: senza di loro non si può ragionare sulla dinamica. La stabilità viene quarta perché è la prima domanda sul comportamento, e ha senso solo dopo aver identificato stato e loop. Osservabilità e controllabilità chiudono perché sono domande su cosa posso farci: hanno senso solo quando il sistema è già stato definito e descritto. La settima domanda — l’apertura — è trasversale e va tenuta presente sempre, perché tocca riproducibilità e sicurezza, due cose che non aspettano il loro turno nella lista. Seguire l’ordine non è pedanteria: saltare al “è stabile?” prima di aver fissato il confine significa quasi sempre rispondere sul sistema sbagliato.

Espressa come procedura di triage, la cassetta degli attrezzi diventa codice:

def diagnostica_fallimento(sessione):
    # Instrada la diagnosi al livello giusto invece che
    # sempre, per riflesso, al modello.

    if not sessione.ha_trace_completi():
        # Lente 4: osservabilità. Senza sensori, ogni
        # altra diagnosi resta una congettura indimostrabile.
        return "Sistema non osservabile: aggiungi trace prima di tutto"

    confine = sessione.confine_valutato()
    if confine != sessione.confine_d_uso_reale():
        # Lente 8: confine. Stai guardando il sistema sbagliato.
        return "Confine errato: rivaluta sul sistema end-to-end"

    forma = sessione.traiettoria.classifica()  # Lente 2 + Lente 3
    if forma == "oscillazione" or forma == "attrattore_trappola":
        # Loop instabile: il difetto sta nel feedback, non nel modello.
        if sessione.loop_feedback().guadagno_alto():
            return "Feedback ad alto guadagno: smorza (fix mirati, 1 cosa per volta)"
        return "Manca uno smorzatore: aggiungi limite iterazioni o checkpoint"
    if forma == "divergenza":
        return "Nessun attrattore desiderato dominante: rivedi il criterio di stop"

    if sessione.stato_compresso_ha_perso_informazione():
        # Lente 2: la proprietà di Markov rotta dalla compaction.
        return "Stato non-markoviano: la compaction ha scartato ciò che serviva"

    # Solo qui, esauriti i livelli di sistema, si guarda il componente.
    return "Nessun difetto sistemico evidente: esamina il modello"

Il valore del blocco non è il codice in sé — è l’ordine. Il modello viene esaminato per ultimo, non per primo. Ogni return precedente è un bug che vive a livello di sistema e che, cercato nel modello, non si sarebbe mai trovato.

Una precisazione sul “per ultimo”: non significa “mai”. A volte il difetto è davvero nel modello — un’allucinazione, un limite reale di capacità su un compito specifico. La cassetta degli attrezzi non nega questa possibilità: la mette in coda. La ragione è statistica più che teorica. I bug a livello di sistema sono numerosi, spesso silenziosi, e quasi sempre invisibili a chi guarda solo l’output del modello; i bug a livello di modello, quando ci sono, tendono a essere più riconoscibili una volta esclusi gli altri. Esaminare prima i livelli numerosi e silenziosi, e per ultimo quello che si vede meglio, è semplicemente l’ordine che minimizza il numero atteso di iterazioni sprecate. Quando la procedura arriva all’ultimo return, l’esame del modello è finalmente informato: si sa che non era il confine, non era il loop, non era l’osservabilità.

Esempi

Quattro esempi deliberatamente eterogenei: uno scenario di debugging, uno numerico, uno di confronto fra numeri, uno organizzativo. Lo scopo non è ripetere quattro volte la stessa cosa, ma mostrare che la cassetta degli attrezzi instrada bene a partire da situazioni molto diverse.

Esempio 1 — l’agente nel loop

Un agente coding ha il compito di far passare una suite di test. Modifica un file, lancia i test, due falliscono. Modifica di nuovo, ne falliscono altri due, diversi dai primi. Itera otto volte senza mai convergere.

Diagnosi ingenua, a livello componente: “il modello non capisce il codice”. Conduce a cambiare modello, riscrivere il prompt del task, o arrendersi. Nessuna delle tre tocca la causa.

Diagnosi sistemica, lente per lente. È un’oscillazione (Lente 3): la traiettoria alterna regioni senza convergere. Lo stato include il filesystem, che cambia a ogni iterazione (Lente 2): l’agente non sta ripartendo da fermo, sta ripartendo da un ambiente che lui stesso ha modificato in modo incoerente. Il loop di feedback ReAct ha guadagno troppo alto (Lente 5): ogni test fallito provoca una riscrittura ampia invece di un fix mirato, e una correzione troppo grande supera il bersaglio dall’altra parte — classico overshoot di un controllore ad alto guadagno. Manca uno smorzatore (Lente 3): nessun limite di iterazioni, nessuna istruzione “cambia una cosa per volta”, nessun checkpoint a cui tornare. La cura segue dalla diagnosi: ridurre il guadagno (istruire fix minimi e isolati), aggiungere uno smorzatore (tetto di iterazioni, checkpoint), eventualmente resettare lo stato dell’ambiente a ogni tentativo. La diagnosi a livello componente non avrebbe indicato nessuna di queste.

Notare la struttura della diagnosi: quattro lenti diverse — stabilità, stato, feedback, stabilità di nuovo — concorrono allo stesso caso, e ognuna aggiunge un pezzo. Nessuna delle quattro, da sola, basterebbe a indicare la cura. È questo il senso di “impugnare i nove cacciaviti insieme”: il valore non sta in una lente brillante, sta nel fatto che applicate in sequenza convergono su un punto di intervento preciso. Un fallimento reale raramente è leggibile da una sola lente.

Esempio 2 — il guadagno del loop, con i numeri

Vale la pena rendere l’oscillazione dell’Esempio 1 quantitativa, perché mostra cosa significa, concretamente, “guadagno troppo alto” — un termine che la control theory misura e che qui resta un’analogia.

Immagina di poter contare i test che falliscono a ogni iterazione: è la misura dello scarto dal bersaglio, e il bersaglio è zero. Un loop ben smorzato si avvicina così: 9 test rossi, poi 5, poi 2, poi 1, poi 0. Lo scarto si dimezza circa a ogni passo; la sequenza converge. È il comportamento di un controllore che corregge in proporzione all’errore, con un guadagno sotto la soglia critica.

Un loop ad alto guadagno fa un’altra cosa: 9 test rossi, poi 12, poi 4, poi 15, poi 3, poi 18. Lo scarto non si restringe — rimbalza, e l’ampiezza dei rimbalzi tende perfino a crescere. Ogni correzione è così aggressiva da scavalcare il bersaglio e atterrare dall’altra parte, peggio di prima. In control theory questo si chiama instabilità da guadagno eccessivo, e per un sistema lineare si calcola con precisione dove sta la soglia. Per un loop agentico la soglia non si calcola — non c’è una matrice di stato — ma il pattern numerico è riconoscibile a occhio, ed è esattamente quello che la Lente 3 insegna a cercare. La cura ha una forma precisa: abbassare il guadagno significa istruire l’agente a fare la più piccola modifica plausibile e rimisurare, invece di riscrivere mezzo file a ogni fallimento. La sequenza che rimbalza è la firma diagnostica; “fai un cambiamento per volta” è lo smorzatore.

C’è un dettaglio onesto da aggiungere, perché il confine fra le classi va rispettato anche qui. La sequenza che converge e la sequenza che rimbalza sono illustrazioni, non dati di un esperimento: servono a rendere visibile cosa intende la Lente 3 con “guadagno”. Un loop agentico reale è rumoroso, e una singola sequenza non basta a diagnosticare nulla — il pattern va visto su molte sessioni prima di chiamarlo “oscillazione” e non “sfortuna”. L’esempio numerico insegna la forma da cercare; non sostituisce la misura ripetuta che sola può confermarla.

Esempio 3 — il confine e l’eval

Esempio 2 — il confine e l’eval

Due modelli da scegliere. Modello A: 88% su un benchmark di coding. Modello B: 84%. Si sceglie A — il numero è più alto. In produzione, dentro l’harness reale, A risolve il 41% dei task end-to-end e B il 53%. Una contraddizione apparente: il modello “peggiore” è il migliore.

La spiegazione è interamente di confine (Lente 8). Il benchmark misurava il sistema “modello da solo, un colpo solo, niente strumenti”. La produzione misura il sistema “modello più tool più retry più memoria”. B sbaglia di più al primo colpo — ed è ciò che il benchmark ha visto — ma recupera molto meglio dagli errori dei tool: legge un messaggio di errore, capisce cosa è andato storto, riprova in modo diverso. Quella capacità di recupero è una proprietà del sistema nel loop, completamente invisibile al confine del benchmark, che il loop non lo contiene. La scelta corretta non dipende dal numero più alto: dipende da quale confine corrisponde all’uso reale. Se l’uso reale è agentico, il benchmark a colpo singolo stava rispondendo alla domanda sbagliata.

La morale non è “i benchmark a colpo singolo sono inutili”: misurano una cosa vera, la qualità del modello al primo tentativo, e per alcuni usi è esattamente la cosa che conta. La morale è che il numero ha un confine implicito, e che il confine va reso esplicito prima di confrontare due numeri. Due percentuali confrontabili devono venire da eval con lo stesso confine. Confrontare l’88% di un benchmark a colpo singolo con il 53% di un’eval end-to-end è confrontare risposte a due domande diverse — un errore che non si vede, perché entrambi i numeri sembrano “la performance del modello”.

Esempio 4 — multi-agente che peggiora le cose

Un team migra da un singolo agente a un sistema con un supervisore e tre worker, con l’obiettivo dichiarato di “andare più veloci”. Dopo la migrazione il throughput cala e il tasso di errore sale.

Diagnosi sistemica. Il sistema è passato da un componente a quattro, e con i quattro componenti sono arrivate tre nuove interfacce, ognuna un punto di feedback che può oscillare o amplificare (Lente 5). Si manifestano cascate di errori: lo sbaglio di un worker, passato al supervisore e ridistribuito, contamina gli altri (Lente 9, emergenza della Lente 7). I tre worker girano sullo stesso modello base, quindi condividono le stesse vulnerabilità — monoculture collapse: l’input che confonde uno confonde tutti e tre allo stesso modo, e la ridondanza apparente non protegge da niente. Conclusione: aggiungere agenti ha aggiunto modi di fallire, non capacità. Era esattamente il caso in cui il principio di Building Effective Agents — cerca la soluzione più semplice — andava applicato prima di costruire, non scoperto dopo.

Vale la pena notare che la diagnosi corretta, qui, non dice “i multi-agente sono sempre sbagliati”. Dice che il beneficio va dimostrato contro un costo che è strutturale e prevedibile — più interfacce, più punti di feedback, più modi di fallire. Ci sono compiti per cui quel costo si ripaga: lavori genuinamente parallelizzabili, in cui i sotto-task sono indipendenti e il coordinamento è minimo. La lente non vieta il multi-agente; impone di chiedersi se il compito ha la forma giusta per pagarne il prezzo. È una decisione di progetto informata, non un divieto.

Applicazioni pratiche

I quattro esempi mostrano la cassetta degli attrezzi che diagnostica. Ma il suo uso più redditizio non è la diagnosi a posteriori — è la progettazione a priori. Letta in positivo, la stessa griglia che spiega un fallimento è una lista di cose da mettere in piedi prima che il fallimento accada. Ecco i quattro usi più concreti.

Debugging stratificato. Davanti a un agente che fallisce, la cassetta degli attrezzi impedisce il riflesso di iterare sul modello quando il difetto è nel loop, nel confine o nell’osservabilità. È, alla lettera, la differenza fra “il modello ha sbagliato” e “il feedback è disegnato male” — e solo la seconda formulazione indica una cura.

Progettazione dell’harness. Le sei domande non servono solo a debuggare: lette in positivo, sono requisiti di progetto. Trace strutturati perché il sistema sia osservabile. Limiti di iterazione e checkpoint perché sia stabile. Permessi espliciti e confini netti perché sia analizzabile sul piano della sicurezza. Feedforward — skill, CLAUDE.md, descrizioni dei tool — per i disturbi prevedibili. Un harness progettato a partire dalla cassetta degli attrezzi nasce debuggabile.

Scelta del modello e disegno dell’eval. La Lente 8 impone una mossa che si tende a saltare: decidere il confine prima di valutare. Benchmark del modello o eval end-to-end del sistema, a seconda di quale confine corrisponde all’uso reale. Saltare questa decisione significa fidarsi di numeri che rispondono a una domanda diversa dalla propria.

Decisione single-agente contro multi-agente. Le lenti dell’emergenza e del feedback dicono, con una ragione teorica e non solo per prudenza, che aggiungere agenti aggiunge modi di fallire. La scelta multi-agente va giustificata con un beneficio concreto, non assunta come progresso di default.

Comunicazione fra chi costruisce e chi opera. C’è un’applicazione meno ovvia e altrettanto concreta: la cassetta degli attrezzi è anche un vocabolario condiviso. Una segnalazione di bug che dice “l’agente è scemo” non è azionabile. Una che dice “l’agente entra in oscillazione: il loop di feedback corregge troppo aggressivamente, manca uno smorzatore” indirizza chi deve sistemare il sistema verso un punto preciso. Quando un team adotta le sei domande come linguaggio comune, le conversazioni di debugging smettono di girare intorno al modello e iniziano a localizzare il difetto. Il valore di una teoria condivisa non è solo che fa pensare meglio il singolo: è che fa parlare meglio il gruppo.

Lettura delle analisi di sicurezza e delle eval altrui. La griglia serve anche a leggere, non solo a costruire. Quando si valuta il report di sicurezza di un sistema AI, o il claim di performance di un fornitore, la prima domanda da porsi è di confine: di quale sistema sta parlando questo numero? Un report che dichiara un modello “sicuro” senza dire se l’analisi includeva i tool sta rispondendo a una domanda ristretta — e va letto come tale. La cassetta degli attrezzi è anche uno strumento di lettura critica: rende visibili i confini impliciti nei numeri e nelle affermazioni degli altri.

Dove si rompe

Questo capitolo è un capitolo-ponte, e i ponti hanno un modo di fallire tutto loro: promettere più di quanto possano reggere. Vale la pena essere espliciti su dove l’inquadramento sistemico smette di portare peso. Le sezioni “Dove si rompe” di questa wiki contano quanto le sezioni sui meccanismi; per un capitolo che propone una griglia di lettura generale, contano forse di più, perché una griglia mal calibrata danneggia più di quanto la sua assenza farebbe.

Il limite più grande è la classe di affermazione. Va ripetuto perché è il punto su cui tutto il capitolo può scivolare. Nessuno dei legami tracciati qui è un teorema. “L’agente è instabile”, “il sistema non è osservabile”, “il loop ha guadagno alto” sono analogie — vocabolario di teoremi usato come metafora operativa. La control theory dimostra la stabilità calcolando gli autovalori di una matrice di stato; per un loop di chiamate LLM quella matrice non esiste. Chiunque presenti una di queste affermazioni come un risultato dimostrato sta commettendo l’errore esatto che le linee guida di questa wiki chiamano scivolamento di classe. Il valore della cassetta degli attrezzi è euristico: organizza l’intuizione e instrada la diagnosi. Non è una garanzia, e non va venduta come tale.

Le metafore prese alla lettera ingannano. “L’agente è un organismo” è un’analogia produttiva finché illumina l’apertura del sistema; diventa fuorviante se la si spinge a suggerire che l’agente abbia un metabolismo, un’omeostasi vera, un istinto di sopravvivenza. “Il loop ha un attrattore” aiuta a vedere la trappola del retry; non implica che esista un bacino di attrazione calcolabile con i metodi dei sistemi dinamici. Ogni metafora di questo capitolo ha un raggio d’azione, e oltre quel raggio mente.

Il confine del sistema resta una scelta, e una scelta può essere cattiva. La Lente 8 dà uno strumento, non una risposta. Decidere dove tracciare il confine richiede giudizio, e un giudizio sbagliato produce un’analisi internamente coerente e sostanzialmente inutile. La teoria dei sistemi rende la scelta visibile; non la fa al posto di chi progetta.

Il vocabolario non sostituisce la misura. Sapere che un sistema “dovrebbe essere osservabile” non produce i trace. Sapere che “dovrebbe essere stabile” non aggiunge gli smorzatori. Il rischio del pensiero sistemico è la sua eleganza: dà l’impressione di aver capito un sistema per il solo fatto di averlo descritto bene. La descrizione è il primo passo del lavoro, non il lavoro.

La griglia può diventare una gabbia. C’è un fallimento opposto e più sottile: applicare le nove lenti in modo rigido, come una checklist burocratica, e smettere di guardare il caso concreto. Le lenti sono utili finché aiutano a vedere; diventano un ostacolo se inducono a forzare ogni fenomeno in una delle nove caselle. Alcuni difetti di un sistema agentico sono banalmente bug di codice nell’harness, o un tool che restituisce dati nel formato sbagliato — non c’è niente di “sistemico” da diagnosticare, c’è una riga da correggere. Lo strumento giusto per un difetto va scelto guardando il difetto, non l’inventario degli strumenti. La cassetta degli attrezzi serve a porre buone domande per prime, non a sostituire il giudizio su quale domanda quel caso specifico stia chiedendo.

Alcuni fenomeni dei sistemi AI non hanno ancora una buona lente sistemica. L’in-context learning — la capacità di un modello di apprendere uno schema dagli esempi nel prompt, senza modificare i pesi — non si lascia inquadrare pulitamente come feedback, né come stato, né come controllo. Il rapporto fra le capacità del modello pre-addestrato e il comportamento del sistema agentico che lo contiene non è ancora ben formalizzato da nessuna delle nove lenti. Il capitolo offre una griglia di lettura potente, non completa: ci sono caselle ancora vuote, e fingere il contrario sarebbe il difetto peggiore di un capitolo-ponte.

Cosa portarsi a casa, e dove porta

Se di tutta la Parte IX dovesse restare una cosa sola, è questa: un sistema AI moderno non è un modello, è un sistema, e i due livelli si debuggano in modi diversi. Il livello del modello risponde alla domanda “perché questo componente ha prodotto questo output”. Il livello del sistema risponde a una domanda diversa e quasi sempre più utile: “perché l’interazione fra questi componenti, chiusa in questo loop, dentro questo confine, ha prodotto questa traiettoria”. Il primo riflesso, davanti a un agente che sbaglia, punta al modello. La Parte IX serve a costruire il secondo riflesso — quello che, prima di toccare il modello, chiede dove sia il confine, quale sia lo stato, quali siano i loop, se il sistema sia stabile, osservabile, controllabile.

Le nove lenti non sono nove nozioni da ricordare. Sono una sequenza di domande che, poste su un caso reale, cambiano una decisione: quale modello scegliere, come disegnare l’eval, dove mettere uno smorzatore, se costruire un multi-agente o no, cosa loggare. Una teoria che cambia una decisione ha fatto il suo lavoro. Una che resta elegante e inerte no.

C’è un beneficio della Parte IX che si vede solo a distanza. I capitoli che seguono — cibernetica, controllo, agenti, harness — useranno di continuo parole come stato, feedback, stabilità, osservabilità, confine, emergenza, senza ridefinirle ogni volta. Chi è arrivato fin qui possiede già quel lessico, e lo possiede non come una lista di definizioni ma come un modo di guardare. Questa è la funzione vera di una Parte di fondamenti: non insegnare fatti che si useranno direttamente, ma installare un vocabolario che renderà leggibili i fatti veri quando arriveranno. Un capitolo-ponte come questo è il momento in cui quel vocabolario viene messo alla prova una prima volta, su un oggetto concreto, per verificare che regga il peso prima di caricarlo davvero.

E questo capitolo è un ponte anche in senso letterale: la Parte IX finisce qui, e tre direzioni si aprono. La Parte X, sulla cibernetica, prende la Lente 5 — il feedback — e ne fa una disciplina autonoma: Wiener, l’omeostasi, la legge della varietà necessaria di Ashby, i sistemi che si regolano da soli. La Parte XI, sulla control theory operativa, prende le Lenti 3 e 4 — stabilità e controllabilità — e le rende quantitative dove il sistema lo permette: il controllo PID, la stabilità di Lyapunov, il model predictive control. E le Parti agentiche — i fondamenti degli agenti, l’harness engineering — prendono la cassetta degli attrezzi e la trasformano in pratica di costruzione: dove mettere i sensori, come disegnare i permessi, quali pattern di loop reggono e quali no. La teoria dei sistemi è stata il vocabolario; la cibernetica e la control theory saranno la grammatica; le Parti agentiche sono i testi scritti in quella lingua. Chi ha letto la Parte IX arriva a quei capitoli con la lingua già in bocca.

C’è una continuità precisa che vale la pena anticipare. La Parte IX ha trattato il feedback come uno dei tanti concetti; la cibernetica lo metterà al centro, perché è la disciplina che nasce proprio attorno alla domanda “come fa un sistema a regolarsi guardando il proprio errore”. E la control theory porterà la domanda di stabilità da analogia a calcolo, almeno sui sistemi che si lasciano modellare con equazioni. Un sistema agentico, in larga parte, non si lascia modellare così — e questo è esattamente il motivo per cui le Parti agentiche esistono come Parti separate: trattano il caso in cui il vocabolario sistemico vale, ma il calcolo formale no. Tenere a mente questa gradazione — dal vocabolario qualitativo della Parte IX, al calcolo della control theory, al ritorno dell’euristica nelle Parti agentiche — aiuta a leggere ogni Parte con le aspettative giuste su quanto rigore può offrire.

Collegamenti

Questo capitolo riusa per intero la Parte IX. I rimandi che seguono non sono accessori: sono le nove lenti, ciascuna alla sua fonte.

Sistema, ambiente, confine, stato — il vocabolario di base. Questo capitolo lo mette alla prova: definisce un sistema agentico nei termini esatti del primo capitolo.
Sistemi aperti, chiusi, dissipativi — Lente 1. Il sistema AI come sistema aperto: non riproducibile per default, con l’ambiente come co-protagonista e una superficie d’attacco che coincide con la sua utilità.
Stato, transizione, traiettoria — Lente 2. Lo stato di un agente e la sessione come traiettoria; la compaction che viola la proprietà di Markov.
Equilibrio, stabilità, attrattori — Lente 3. Divergenza, oscillazione e attrattori-trappola di un loop agentico; smorzatori contro amplificatori.
Osservabilità e controllabilità — Lente 4. Le due domande di Kalman come radici dell’interpretabilità e dello steering.
Feedback vs feedforward — Lente 5. ReAct e RLHF come feedback a scale temporali diverse; il prompt e le skill come feedforward.
Modelli descrittivi, predittivi, prescrittivi — Lente 6. L’LLM come modello del mondo; white box fisico contro black box epistemico.
Riduzionismo e olismo — Lente 7. L’interpretabilità meccanicistica come programma riduzionista e il suo limite olistico; l’emergenza, vera e apparente.
Scegliere il confine cambia il problema — Lente 8. Il confine come decisione che cambia eval, sicurezza e attribuzione di responsabilità.

Verso le Parti successive, applicative, a cui questo capitolo fa da ponte:

cibernetica-definizione e feedback-loop (in preparazione), Parte X — la cibernetica prende la Lente 5 e ne fa una disciplina: Wiener, omeostasi, requisite variety.
control-theory-intro e ponte-control-agenti (in preparazione), Parte XI — la control theory prende le Lenti 3 e 4 e le rende quantitative dove è possibile: PID, Lyapunov, model predictive control.
react (in preparazione), Parte XXXVIII — il pattern ReAct in dettaglio, il loop di feedback agentico visto da vicino.
agente-definizione, multi-agent, agent-observability (in preparazione), Parte XXXVIII — la cassetta degli attrezzi trasformata in pratica di design degli agenti.
harness-definizione (in preparazione), Parte XLI — il runtime attorno al modello: dove vivono concretamente i sensori e gli smorzatori di questo capitolo.
mech-interp-intro (in preparazione), Parte XXI — il programma riduzionista sui circuiti, di cui la Lente 7 dà solo l’inquadramento.

Per andare oltre

Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023 (arXiv:2210.03629). Il paper che introduce il loop thought-action-observation; da leggere con la lente del feedback in mano.
Schaeffer, Miranda, Koyejo, Are Emergent Abilities of Large Language Models a Mirage?, NeurIPS 2023 (arXiv:2304.15004). Il caso più netto di “cosa misuri determina cosa vedi”: molte emergenze sono artefatti della metrica.
Anthropic, Building Effective Agents, dicembre 2024. Documento ingegneristico sulla composizione di un sistema agentico e sul principio della soluzione più semplice; la base pratica della Lente 9.
Ludwig von Bertalanffy, General System Theory: Foundations, Development, Applications, 1968. Il testo fondativo: l’organismo come sistema aperto, l’argomento per cui un vocabolario di sistema attraversa le discipline.
Cemri et al., Why Do Multi-Agent LLM Systems Fail?, 2025 (arXiv:2503.13657). La tassonomia MAST dei quattordici failure mode dei sistemi multi-agente; l’evidenza empirica dietro la cautela della Lente 9.