Sistema, ambiente, confine, stato: il vocabolario di base

Un sistema AI moderno non è un modello: è un modello dentro un sistema. Questo capitolo dà i nomi alle parti di quel sistema e spiega perché serve saperli.

Perché questo capitolo

Un agente entra in un loop. Ripete tre volte la stessa chiamata a un tool, ottiene tre volte lo stesso errore, e al quarto tentativo prova qualcosa di assurdo. Apri il log e ti fai la domanda sbagliata: “perché il modello ha sbagliato?”.

Il modello, preso da solo, non ha sbagliato niente: a ogni passo ha prodotto la continuazione più plausibile dato il contesto che aveva davanti. Il guasto non sta nel modello. Sta nel modo in cui l’output di un passo rientrava come input del passo successivo, accumulando un errore invece di correggerlo. Il guasto sta nel sistema, e finché guardi solo il modello non lo vedrai.

Questo capitolo apre la Parte IX della wiki, dedicata alla teoria dei sistemi: la disciplina che studia cosa hanno in comune oggetti apparentemente lontanissimi — un corpo umano, un’azienda, un ecosistema, un termostato, un agente in esecuzione — quando li si guarda come insiemi di parti che interagiscono.

Non è una disciplina nuova: ha radici nella biologia e nell’ingegneria di metà Novecento. Ma è esattamente il vocabolario di cui ha bisogno chi costruisce sistemi AI oggi, perché un sistema AI moderno è, nel senso tecnico della parola, un sistema: un modello più un orchestratore, più dei tool, più una memoria, più un ambiente, più un utente nel loop.

La posta in gioco è pratica. Senza un vocabolario per ragionare a livello di sistema, ogni problema agentico viene attribuito al componente più visibile — quasi sempre il modello — e ogni soluzione diventa “cambiamo il prompt” o “cambiamo il modello”.

A volte funziona. Spesso no, perché il problema era altrove: in un feedback loop disegnato male, in un confine tracciato nel punto sbagliato, in uno stato che si corrompe nel tempo, in un’interazione fra due tool che nessuno aveva previsto.

La teoria dei sistemi dà un nome a ciascuna di queste cose. Dare un nome a un guasto è il primo passo per cercarlo nel punto giusto: una diagnosi senza vocabolario resta una sensazione.

C’è anche una ragione che va oltre il debugging. Chi progetta un sistema AI prende, spesso senza accorgersene, una sequenza di decisioni di teoria dei sistemi: dove finisce un componente e dove inizia l’ambiente, quali informazioni rientrano nel contesto e quali no, quanti livelli di agenti annidare, dove inserire un controllo e dove lasciare che il sistema corra.

Prese a caso, queste decisioni producono sistemi che a volte funzionano e a volte no, senza che si capisca perché. Prese con un vocabolario, diventano scelte di progetto discutibili e correggibili. La teoria dei sistemi non è un’aggiunta colta: è il livello a cui si decide la maggior parte di ciò che rende un sistema AI affidabile o fragile.

Il capitolo non chiede prerequisiti. Costruisce, dall’intuizione, sei concetti — sistema, confine, ambiente, stato, processo, feedback — e ne anticipa altri due — emergenza, gerarchia — che i capitoli successivi della Parte svolgeranno in dettaglio.

Se questi nomi diventano familiari, il resto della Parte IX e tutta la Parte X sulla cibernetica diventano lo svolgimento di un’intuizione che già possiedi.

Contesto

La teoria dei sistemi, come campo esplicito con un nome proprio, nasce a metà Novecento. Prima di allora ogni disciplina studiava i propri sistemi senza accorgersi di studiare la stessa cosa.

Un fisiologo descriveva come il corpo mantiene costante la temperatura; un ingegnere progettava un regolatore che teneva costante la velocità di una macchina a vapore; un economista osservava come un mercato torna verso un prezzo dopo uno shock.

Tre descrizioni in tre linguaggi incompatibili, di una sola struttura. Il salto concettuale fu accorgersi che la struttura era una, e che meritava una scienza a sé.

Il primo a formularlo con forza fu Ludwig von Bertalanffy (1901-1972), biologo austriaco. A partire da lezioni del 1937 e da pubblicazioni dal 1946, sviluppò quella che chiamò General System Theory, teoria generale dei sistemi: la tesi che discipline diverse studiano sistemi che condividono principi formali comuni, e che questi principi meritano una trattazione unificata.

Il testo di sintesi, General System Theory: Foundations, Development, Applications (George Braziller, New York, 1968), raccoglie circa quarant’anni di lavoro.

Da biologo, von Bertalanffy era ossessionato da un fatto: un organismo vivente resta organizzato e stabile pur essendo attraversato da un flusso continuo di materia ed energia.

La fisica classica studiava soprattutto sistemi che, lasciati a sé, decadono verso l’equilibrio; un essere vivente fa l’opposto, e lo fa proprio perché aperto al flusso. Da qui la sua distinzione centrale fra sistemi aperti e chiusi, che riprenderemo.

In parallelo, e a tratti intrecciato, nasceva un campo gemello: la cibernetica. Il matematico statunitense Norbert Wiener (1894-1964) le diede un nome nel 1948 con il libro Cybernetics: or Control and Communication in the Animal and the Machine — la cibernetica, ovvero il controllo e la comunicazione nell’animale e nella macchina.

Mentre la teoria dei sistemi metteva al centro il concetto generale di sistema, la cibernetica metteva al centro un meccanismo specifico: il feedback, la retroazione.

I due campi crebbero insieme, soprattutto nelle Macy Conferences, dieci conferenze interdisciplinari tenute a New York fra il 1946 e il 1953 e finanziate dalla Josiah Macy Jr. Foundation. Il titolo originario di quelle conferenze — Circular Causal and Feedback Mechanisms in Biological and Social Systems, meccanismi causali circolari e di feedback nei sistemi biologici e sociali — dice già tutto.

Intorno a quel tavolo sedevano matematici, ingegneri, biologi, antropologi e psicologi, e fu lì che feedback, informazione e controllo diventarono un vocabolario condiviso fra discipline. La cibernetica ha la sua Parte dedicata in questa wiki, la Parte X; qui ci limitiamo ad annunciarla.

Da quel ceppo comune si staccò poi un ramo più operativo. Jay Forrester (1918-2016), ingegnere del MIT formatosi nei servomeccanismi — i sistemi di controllo automatico, come i puntatori dei cannoni antiaerei della Seconda guerra mondiale — dalla metà degli anni Cinquanta sviluppò la system dynamics.

È un metodo per modellare organizzazioni e sistemi complessi in termini di accumuli, flussi, ritardi e feedback loop, e per simularli al computer.

Il testo fondativo è Industrial Dynamics (MIT Press, 1961), nato dallo studio di una fabbrica di elettrodomestici della General Electric, dove Forrester mostrò che certi cicli di espansione e crisi nascevano dalle pratiche di gestione interne, non dal mercato. La system dynamics ha anch’essa il suo capitolo nella Parte X.

L’ultima figura del contesto è anche la più recente e la più vicina al lettore. Donella Meadows (1941-2001), scienziata ambientale statunitense formatasi nella tradizione di Forrester, scrisse il testo che ha reso il pensiero sistemico accessibile a chi non è uno specialista: Thinking in Systems: A Primer (Chelsea Green, 2008), pubblicato postumo.

È a Meadows che si deve la definizione operativa di sistema che useremo come spina dorsale di questo capitolo, e la distinzione netta fra i due tipi di feedback. Quando, più avanti, diremo che un sistema è “parti più interconnessioni più una funzione”, stiamo citando lei.

Tutto questo per inquadrare un punto: i nomi che useremo non sono invenzioni recenti per parlare di AI. Sono un vocabolario costruito in settant’anni su corpi viventi, macchine a vapore, fabbriche ed ecosistemi. Si applica ai sistemi AI perché un sistema AI ha la stessa forma astratta — ed è questo il motivo per cui vale la pena impararlo.

L’intuizione

Prima di qualsiasi definizione formale, due modi diversi di vedere cosa è un sistema. Sono due angoli distinti — uno guarda la realtà e ci trova una forma ricorrente, l’altro parte dal codice — e conviene tenerli entrambi.

Primo angolo: la stessa forma sotto nomi diversi

Considera quattro oggetti, presi da quattro mondi che non si parlano.

Un termostato in una stanza. Misura la temperatura, la confronta con quella che hai impostato, e se la stanza è troppo fredda accende il riscaldamento, se è troppo calda lo spegne. Risultato: la temperatura resta vicina al valore impostato.

Un corpo umano sotto sforzo. La temperatura interna tende a salire; il corpo se ne accorge, e reagisce — suda, dilata i vasi della pelle — per disperdere calore. Risultato: la temperatura interna resta vicina ai 37 gradi.

Una banca centrale che governa l’inflazione. Misura l’andamento dei prezzi, lo confronta con un obiettivo dichiarato, e se l’inflazione sale alza i tassi di interesse, se scende troppo li abbassa. Risultato: l’inflazione resta, nelle intenzioni, vicina all’obiettivo.

Un agente AI che si autocorregge. Produce una risposta, una seconda istanza la critica confrontandola con un criterio di qualità, e se la critica trova un difetto l’agente rigenera la risposta. Risultato: la qualità della risposta finale resta sopra una soglia.

Quattro oggetti, quattro discipline, quattro vocabolari. Eppure, se cancelli i nomi specifici, resta una sola struttura: c’è qualcosa che viene misurato, c’è un valore di riferimento con cui lo si confronta, c’è un meccanismo che agisce per ridurre la differenza, e c’è il fatto che l’azione cambia la cosa misurata — chiudendo un anello.

Quell’anello è la struttura. La teoria dei sistemi è la disciplina che vede la struttura sotto i nomi, e che, una volta vista, ti permette di studiarla una volta sola invece di quattro. È un guadagno enorme: invece di imparare da capo come funziona ogni nuovo oggetto, riconosci una forma che hai già visto e ne sai già il comportamento tipico.

Questo è il primo angolo: un sistema non è un tipo di oggetto, è un modo di guardare un oggetto. Guardi qualcosa come “parti che interagiscono e producono insieme un comportamento”, e quel qualcosa diventa un sistema. Lo stesso oggetto fisico — la stanza col termostato — è un sistema se lo guardi così, ed è solo “un radiatore e un muro” se lo guardi come un elenco di componenti.

Secondo angolo: la scatola con stato e confine

Per chi pensa in codice c’è una via più diretta. Immagina una scatola. Dentro la scatola c’è dello stato: delle variabili, dei dati che la scatola si porta dietro. Nella scatola entrano degli input, dalla scatola escono degli output.

E dentro c’è una regola, una funzione di transizione: dato lo stato attuale e l’input appena ricevuto, la regola calcola il nuovo stato e l’output da emettere.

In pseudocodice:

nuovo_stato, output = transizione(stato_corrente, input)

Esegui questa riga una volta e hai un passo. Esegui la stessa riga in un loop, ogni volta passando come stato_corrente il nuovo_stato calcolato al giro prima, e hai un sistema che evolve nel tempo.

La linea di gesso che hai disegnato attorno alla scatola — la decisione di cosa è “dentro” e cosa è “fuori” — è il confine. Tutto ciò che sta fuori dal confine ma fornisce gli input o consuma gli output è l’ambiente.

Questa immagine è meno poetica della prima ma ha un vantaggio: è già quasi un programma. E rende evidente una cosa che la prima immagine lasciava implicita. La parola chiave è stato.

Una scatola senza stato — che data lo stesso input produce sempre lo stesso output, indipendentemente da cosa è successo prima — è una funzione pura, non un sistema interessante. Ciò che rende un sistema un sistema è che porta con sé una memoria del passato, e che quindi il suo comportamento dipende dalla sua storia, non solo dall’ultimo input.

Terzo angolo: il livello sbagliato a cui si guarda

C’è un terzo modo di entrare nel concetto, ed è quello che spiega meglio perché la teoria dei sistemi è utile a chi debugga, e non solo a chi filosofeggia.

Immagina di voler capire perché un’autostrada si ingorga ogni mattina alle otto. Puoi studiare una singola auto con precisione assoluta — il motore, le decisioni del guidatore, la traiettoria — e non capirai mai l’ingorgo, perché l’ingorgo non è una proprietà di nessuna auto.

È una proprietà del traffico: nasce da come migliaia di auto, ciascuna delle quali frena un po’ troppo tardi, si influenzano a vicenda. Studiare l’auto è il livello sbagliato. L’oggetto che vuoi capire vive a un livello sopra.

Lo stesso vale al contrario. Se vuoi capire perché un singolo motore batte in testa, studiare il traffico non serve: scendi al livello del motore, anzi dei suoi cilindri. Il punto generale è che ogni fenomeno ha un suo livello naturale, e guardare al livello sbagliato — troppo sotto o troppo sopra — rende il fenomeno invisibile per costruzione, non per mancanza di sforzo.

Il pensiero sistemico è, in questa luce, l’abitudine di chiedersi prima di tutto: a quale livello vive la cosa che voglio capire? È un componente, è un’interazione fra componenti, è una proprietà del tutto?

Quando un sistema AI si comporta in modo strano, la prima mossa non è aprire il modello: è decidere a che livello vive il comportamento strano. Quasi sempre il tempo perso nel debugging è tempo passato a guardare il livello sbagliato con grande accuratezza.

Tieni vicine le tre immagini. La prima ti fa riconoscere un sistema quando lo incontri nel mondo. La seconda ti dice da quali pezzi è fatto. La terza ti dice a che livello cercare quando qualcosa non va. Il resto del capitolo non fa che mettere nomi precisi su quei pezzi e su quei livelli.

La meccanica

Adesso le definizioni. Le diamo nell’ordine in cui si appoggiano una sull’altra.

La definizione di sistema

Donella Meadows, nel testo citato sopra, definisce un sistema come un insieme di tre cose: elementi, interconnessioni e una funzione o scopo.

In parole povere: ci sono delle parti, le parti si influenzano a vicenda secondo certe regole, e l’insieme fa qualcosa di riconoscibile. Tutte e tre sono necessarie, e la prossima sezione le passa una per una.

Le parti sono i componenti. In un sistema AI agentico: il modello, l’orchestratore che decide il prossimo passo, i tool, la memoria, il prompt di sistema.

Le interconnessioni sono le regole secondo cui le parti si influenzano: il modello riceve il contesto e produce una tool call, il tool viene eseguito e restituisce un risultato, il risultato rientra nel contesto. Le interconnessioni sono spesso flussi di informazione.

La funzione è cosa fa l’insieme: risolvere un task, rispondere a una domanda, mantenere aggiornata una documentazione.

Meadows aggiunge un’osservazione che vale la pena isolare: cambiare le parti, mantenendo interconnessioni e funzione, di solito cambia poco; cambiare le interconnessioni cambia quasi sempre tutto.

Sostituisci un modello con un altro di pari livello e l’agente si comporta in modo simile. Cambia il modo in cui i tool si passano i risultati, o introduci un passo di critica fra generazione e risposta, e hai un sistema diverso, anche con gli stessi modelli e gli stessi tool. È un primo indizio di dove guardare quando un sistema non funziona: prima alle interconnessioni, poi alle parti.

A questa definizione aggiungiamo la clausola che la rende stringente: il comportamento del sistema non si riduce alla somma dei comportamenti delle parti prese isolatamente.

Un mucchio di sabbia è un insieme di parti, ma i granelli non si influenzano in modo da produrre un comportamento coordinato: non è un sistema in senso interessante. Un motore lo è — pistoni, valvole e albero a gomiti si vincolano a vicenda — e infatti il motore “gira”, una proprietà che nessun pistone possiede.

Confine e ambiente

Il confine è la linea che separa ciò che consideri parte del sistema da ciò che consideri esterno.

Il punto cruciale, e controintuitivo, è che il confine non è un dato della natura: è una scelta di chi modella. Non esiste “il” sistema in assoluto; esiste il sistema una volta che hai deciso dove passa la linea.

Prendi un agente di coding. Puoi tracciare il confine attorno al solo modello: tutto il resto — l’harness, i tool, il filesystem, l’utente — è ambiente. Oppure puoi tracciarlo attorno a modello, harness e tool insieme: l’ambiente diventa il filesystem e l’utente. Oppure ancora più largo, includendo l’utente nel sistema: l’ambiente è il resto dell’organizzazione.

Sono tre confini diversi, tre sistemi diversi, e ognuno è legittimo. Quale scegliere dipende dalla domanda che ti stai facendo.

Se la domanda è “il modello sa usare questo tool”, il confine stretto basta; se la domanda è “perché l’agente e l’utente continuano a fraintendersi”, il confine deve includere l’utente, altrimenti la causa cade fuori e diventa invisibile. Il capitolo confini-del-sistema (in preparazione) di questa Parte è dedicato interamente a questa scelta.

L’ambiente è, per definizione, tutto ciò che sta fuori dal confine ma interagisce con il sistema: gli fornisce input o ne riceve output. L’ambiente di un agente AI, con il confine tracciato attorno a modello e harness, comprende il filesystem su cui scrive, le API che chiama, l’utente che gli parla, e — in un sistema multi-agente — gli altri agenti.

Input, output, stato, processo

Con il confine fissato, gli altri termini si definiscono da soli.

L’input è ciò che attraversa il confine entrando: per un agente, il prompt iniziale e le osservazioni che i tool restituiscono. L’output è ciò che attraversa il confine uscendo: le risposte all’utente, le tool call, le scritture su file.

Lo stato è l’informazione interna che il sistema porta con sé e che, insieme all’input, determina cosa farà. Per un agente lo stato è concreto e identificabile: la conversation history, lo scratchpad del ragionamento, la memoria a lungo termine, le variabili che l’harness tiene fra un passo e l’altro.

Lo stato è ciò che rende il comportamento dipendente dalla storia. Due agenti identici, stesso modello e stessi tool, che ricevono lo stesso prompt, possono comportarsi in modo diverso se partono da uno stato diverso — per esempio una memoria popolata da sessioni precedenti differenti.

Il processo è la sequenza di trasformazioni che porta lo stato da un istante al successivo: la regola di transizione applicata ripetutamente nel tempo. Quando dici che “l’agente sta lavorando”, stai descrivendo un processo: la transizione (stato, input) -> (stato', output) iterata, passo dopo passo.

Sistemi aperti e sistemi chiusi

Una distinzione che von Bertalanffy mise al centro del suo lavoro. Un sistema chiuso non scambia materia con l’ambiente — e nei modelli più stretti, della termodinamica, nemmeno energia. Lasciato a sé, un sistema chiuso evolve verso uno stato di equilibrio e lì si ferma.

Un sistema aperto, all’opposto, scambia continuamente materia, energia o informazione con l’ambiente, ed è proprio questo flusso a tenerlo in vita.

L’esempio di von Bertalanffy era l’organismo vivente. Un essere vivente non è in equilibrio: l’equilibrio, per un organismo, è la morte.

È invece in quello che lui chiamava uno steady state, uno stato stazionario stabile ma lontano dall’equilibrio, mantenuto attivamente dal flusso continuo di nutrienti, ossigeno e calore che lo attraversa. Smetti il flusso e il sistema collassa verso l’equilibrio vero.

Per un sistema AI la distinzione è netta. Un modello a riposo — i pesi salvati su disco, nessuna inferenza in corso — è vicino a un sistema chiuso: nessun flusso, nessun comportamento, niente che evolve.

Un agente in esecuzione è un sistema aperto in pieno: riceve token, chiama tool, osserva risultati, emette azioni, in un flusso continuo attraverso il confine. Spegnerlo lo chiude e lo congela. Il capitolo sistemi-aperti-chiusi (in preparazione) di questa Parte sviluppa la distinzione, inclusi i sistemi dissipativi.

Feedback: l’anello che si richiude

Arriviamo al concetto che lega la teoria dei sistemi alla cibernetica. Il feedback, o retroazione, è ciò che accade quando l’output di un sistema rientra, direttamente o indirettamente, come input, e quindi influenza il comportamento futuro. L’anello si chiude: l’effetto torna a essere causa.

Ci sono due tipi di feedback, e i loro nomi sono tecnici, non valutativi.

Il feedback negativo, detto anche bilanciante, è quello in cui il segnale di ritorno contrasta la deviazione. Se una variabile sale troppo, il feedback negativo spinge per farla scendere; se scende troppo, spinge per farla salire.

Il risultato è la stabilizzazione: il sistema tende verso un valore di riferimento, un setpoint, e ci resta. Il termostato è feedback negativo allo stato puro: temperatura sotto il setpoint, accende; sopra, spegne. Tutti e quattro gli esempi del primo angolo intuitivo erano feedback negativo.

Il feedback positivo, detto anche rinforzante, è quello in cui il segnale di ritorno amplifica la deviazione. Se una variabile sale, il feedback positivo la fa salire ancora di più; e quel di più la fa salire ancora.

Il risultato è la crescita esplosiva o il collasso. L’interesse composto è feedback positivo: più capitale hai, più interessi maturi, più capitale hai. Il microfono avvicinato all’altoparlante che inizia a fischiare è feedback positivo: il suono captato viene amplificato, riemesso, ricaptato più forte, riamplificato.

Insisto sul punto che è fonte di confusione: “positivo” e “negativo” non significano “buono” e “cattivo”. Un feedback positivo può essere un disastro — è il loop infinito dell’agente con cui abbiamo aperto il capitolo. Un feedback negativo è di solito ciò che tiene un sistema sano. I segni descrivono la direzione dell’effetto — amplifica o contrasta — non la sua desiderabilità.

Qui ci fermiamo all’introduzione: il feedback ha un capitolo dedicato in questa Parte, feedback-feedforward (in preparazione), e l’intera Parte X della wiki, sulla cibernetica, lo svolge fino in fondo.

Accumuli e flussi: la grammatica della system dynamics

C’è un’ultima coppia di termini che vale la pena introdurre, perché è la grammatica con cui Forrester e Meadows descrivono i sistemi che cambiano nel tempo, e perché chiarisce un equivoco molto comune.

Un accumulo — in inglese stock — è una quantità che si trova nel sistema in un dato istante: l’acqua in una vasca, i soldi su un conto, i token già consumati da un agente in una sessione, i messaggi in una coda di richieste. Un accumulo è una fotografia: ha senso chiedere “quanto ce n’è adesso”.

Un flusso — in inglese flow — è la velocità con cui un accumulo cresce o cala: l’acqua che entra dal rubinetto e quella che esce dallo scarico, i token consumati al secondo, le richieste che arrivano e quelle smaltite al minuto. Un flusso non è una fotografia, è un ritmo: ha senso chiedere “quanto sta entrando, e quanto sta uscendo, per unità di tempo”.

La distinzione sembra pedante e invece spiega un comportamento controintuitivo. Un accumulo cambia solo gradualmente, perché può cambiare unicamente attraverso i suoi flussi. Se chiudi di colpo il rubinetto, la vasca non si svuota di colpo: continua a contenere tutta l’acqua che c’era, e cala solo al ritmo dello scarico.

È il motivo per cui i sistemi reali hanno inerzia: un cambiamento improvviso in un flusso non produce un cambiamento improvviso nell’accumulo.

L’errore tipico è confondere i due — credere che, siccome hai ridotto un flusso, l’accumulo sia già al livello desiderato. Una pipeline che smette di accettare nuove richieste non ha una coda vuota: ha una coda che si svuota al ritmo con cui le richieste vecchie vengono smaltite.

I feedback loop, in questa grammatica, sono esattamente i meccanismi per cui il livello di un accumulo influenza i flussi che lo riempiono o lo svuotano. Il termostato è un loop in cui l’accumulo “temperatura” controlla il flusso “calore immesso”.

Tutto il vocabolario di questo capitolo — confine, stato, feedback — si riformula in termini di accumuli e flussi, ed è in quei termini che la system dynamics lo rende simulabile. Il capitolo system-dynamics-forrester (in preparazione) della Parte X svolge questa grammatica fino a costruirci modelli completi.

Due concetti che anticipiamo: emergenza e gerarchia

Due termini che ricorreranno in tutta la Parte IX e che conviene introdurre adesso, anche se i loro capitoli dedicati li svilupperanno.

Una proprietà è emergente quando appartiene al sistema nel suo insieme e a nessuna delle parti, e non si lascia prevedere — in pratica, spesso nemmeno in linea di principio — guardando le parti isolate. L’aforisma informale è antico, lo si fa risalire ad Aristotele: “il tutto è più della somma delle parti”.

La temperatura di un gas è emergente: una singola molecola non ha temperatura, ce l’ha solo l’insieme. Il traffico è emergente rispetto alle singole auto.

Un avvertimento sulla classe di affermazione: dire “X è emergente” descrive un fatto — la proprietà non si legge nelle parti — ma non lo spiega. L’emergenza è un’osservazione, non un meccanismo. Trattarla come una spiegazione (“perché si comporta così? perché è emergente”) è un errore che vedremo più avanti.

La gerarchia è il fatto che i sistemi si annidano. Un sistema è fatto di sottosistemi ed è a sua volta un componente di un sistema più grande. Una cellula sta dentro un tessuto, che sta dentro un organo, che sta dentro un organismo, che sta dentro una popolazione. A ogni livello compaiono proprietà emergenti nuove e serve un vocabolario nuovo.

Per un sistema AI la gerarchia è esplicita: un token sta dentro un messaggio, che sta dentro un turno, che sta dentro una sessione, che sta dentro un agente, che sta dentro un sistema multi-agente, che sta dentro un deployment. Ogni livello è un sistema a pieno titolo, con i suoi feedback loop e le sue proprietà emergenti.

Esempi

Quattro esempi eterogenei: uno numerico, uno fisiologico, uno in codice, uno scenario reale di agent coding. Sono volutamente lontani fra loro — l’idea è che tu veda la stessa struttura affiorare ogni volta.

Esempio 0: un accumulo che si riempie, con i numeri

Partiamo dal caso più nudo possibile, solo numeri, per fissare la differenza fra accumulo e flusso.

Una coda di richieste in un sistema di serving. All’istante zero la coda contiene 100 richieste in attesa: questo è l’accumulo, lo stato del sistema. Arrivano 30 richieste al minuto — flusso in ingresso — e il sistema ne smaltisce 25 al minuto — flusso in uscita. Il flusso netto è quindi 30 - 25 = 5 richieste al minuto che si accumulano.

Dopo un minuto la coda contiene 100 + 5 = 105 richieste. Dopo dieci minuti, 100 + 50 = 150. La coda cresce, lentamente ma senza fermarsi, perché il flusso netto è positivo.

Nota il punto controintuitivo: anche se a un certo istante il flusso in ingresso scende bruscamente da 30 a 26, il flusso netto resta positivo (26 - 25 = 1) e la coda continua a crescere — più piano, ma cresce. Per far scendere l’accumulo non basta ridurre il flusso in ingresso: bisogna portarlo sotto il flusso in uscita.

E anche quando ci riesci, l’accumulo non torna a 100 di colpo: cala al ritmo del flusso netto, che ora è negativo. Lo stato di un sistema porta la storia dei flussi passati, non solo l’ultimo valore. Questo, in tre numeri, è il motivo per cui i sistemi hanno inerzia.

Esempio 1: la termoregolazione del corpo umano

Il corpo umano che mantiene la temperatura interna intorno ai 37 gradi è il sistema-modello della teoria dei sistemi, quello su cui Walter Cannon — fisiologo statunitense — coniò nel 1926 il termine omeostasi, la capacità di un sistema di tenere costanti certe variabili interne nonostante le perturbazioni esterne.

Mappiamolo con il vocabolario del capitolo. Le parti: i recettori termici nella pelle e nell’ipotalamo, l’ipotalamo stesso come centro di confronto, gli effettori — ghiandole sudoripare, vasi sanguigni, muscoli che producono il brivido. Le interconnessioni: i recettori inviano segnali all’ipotalamo, l’ipotalamo confronta con il valore di riferimento e attiva gli effettori.

Il confine: la pelle, ragionevolmente — anche se, da bravi modellatori, sappiamo che è una scelta, e che per certe domande conviene includere nel sistema anche i vestiti o la stanza. L’ambiente: l’aria esterna, la sua temperatura e umidità. Lo stato: la temperatura interna corrente, più lo stato di attivazione degli effettori.

Il feedback: negativo. Temperatura che sale sopra il setpoint, il corpo suda e dilata i vasi per disperdere calore; temperatura che scende, il corpo trema e contrae i vasi per trattenerlo.

È un sistema aperto: scambia calore con l’ambiente di continuo, e la sua stabilità non è equilibrio ma steady state mantenuto attivamente. Smetti il metabolismo e la temperatura collassa verso quella della stanza — l’equilibrio vero.

Esempio 2: un sistema in codice, riga per riga

Il modo più diretto per vedere “scatola con stato, confine, feedback” è scriverla. Niente sostituisce il riconoscere i concetti del capitolo dentro righe di codice che potresti aver scritto tu. Ecco un sistema di controllo minimale — un termostato simulato — in pseudocodice.

def sistema_termostato(temp_iniziale, setpoint, passi):
    stato = temp_iniziale          # lo stato: la temperatura corrente
    storia = []
    for _ in range(passi):
        # input dall'ambiente: la stanza perde calore a ogni passo
        dispersione = 0.5
        # la regola di transizione, con il feedback
        errore = setpoint - stato
        if errore > 0:             # troppo freddo: il riscaldatore agisce
            riscaldamento = 1.0
        else:
            riscaldamento = 0.0
        # output del passo che diventa stato del passo dopo
        stato = stato - dispersione + riscaldamento
        storia.append(stato)
    return storia

Leggiamolo con il vocabolario. La variabile stato è lo stato del sistema, la sua memoria fra un passo e l’altro. La variabile dispersione è un input che arriva dall’ambiente: la stanza perde calore comunque. Il confine del sistema è il corpo della funzione: dentro c’è il termostato, fuori c’è la dispersione che lo perturba.

La riga errore = setpoint - stato è la misura della deviazione; il blocco if è la decisione.

E la riga stato = stato - dispersione + riscaldamento è la regola di transizione, dove il riscaldamento calcolato in base allo stato torna a modificare lo stato stesso: l’anello si chiude, ed è feedback negativo, perché riscaldamento si attiva solo quando l’errore è positivo, cioè per contrastare il raffreddamento.

Esegui questa funzione e la storia mostra la temperatura che parte lontana dal setpoint e vi converge, poi oscilla leggermente intorno: il comportamento tipico di un sistema stabilizzato da feedback negativo.

Cambia un solo segno — fai agire il riscaldatore quando l’errore è negativo invece che positivo — e hai trasformato il feedback in positivo: la temperatura diverge invece di convergere. Una riga di differenza nel codice, due comportamenti opposti del sistema. È la prova più nuda del fatto che il comportamento non sta nelle parti ma in come sono collegate.

Esempio 3: il loop di un agente di coding

Lo scenario reale. Un agente di coding riceve il task: “fai passare i test di questo repository”. Il suo loop, nello stile del pattern ReAct — di cui parla il capitolo react (in preparazione) della Parte sugli agenti — è: ragiona sul prossimo passo, esegui un’azione con un tool, osserva il risultato, ripeti.

Questo loop è un sistema con feedback, e conviene leggerlo come tale. Le parti: il modello, l’orchestratore che mantiene il loop, i tool — eseguire i test, leggere file, applicare una patch. Lo stato: la conversation history, che a ogni giro si allunga con il ragionamento, l’azione e l’osservazione del passo precedente.

L’ambiente: il filesystem del repository, il runner dei test. Il feedback: l’output di un’esecuzione dei test — passati, falliti, con quale messaggio di errore — rientra nel contesto e diventa l’input su cui il modello ragiona al passo dopo.

Quando il sistema è sano, questo feedback è negativo: ogni iterazione usa il messaggio di errore per ridurre la distanza dal “tutti i test verdi”. È omeostasi orientata a un obiettivo.

Quando il sistema si guasta, lo stesso loop può diventare feedback positivo: l’agente applica una patch che peggiora le cose, l’osservazione peggiorata lo confonde di più, la patch successiva è peggiore ancora — e la conversation history, lo stato, accumula errore invece di correggerlo.

Lo stesso identico loop, due regimi opposti. Notare che la diagnosi “il modello ha sbagliato” qui non aiuta: a ogni singolo passo il modello ha prodotto una continuazione plausibile del contesto che aveva. Il guasto è nella dinamica del sistema — un feedback che ha cambiato segno — non in una parte. È esattamente il punto da cui il capitolo è partito.

Applicazioni pratiche

Il vocabolario di questo capitolo non resta teorico: cambia il modo concreto in cui si progettano e si riparano i sistemi AI.

Debugging di pipeline agentiche. Davanti a un agente che fallisce, il riflesso utile è mappare il sistema prima di cercare il colpevole. Dove passa il confine? Quali sono le parti e le interconnessioni? Cosa c’è nello stato e come evolve? Ci sono feedback loop, e di che segno?

Molto spesso il guasto non è in una parte ma in un’interconnessione — un tool che restituisce un output che, rientrando nel contesto, lo avvelena — oppure in un feedback che ha cambiato segno. Cercare nel modello un guasto che sta nella dinamica del sistema è il modo più comune di perdere tempo.

Progettazione di sistemi RAG e multi-agente. Progettare un sistema AI è in buona parte decidere confini e feedback loop. Decidere dove finisce un componente e dove inizia l’ambiente determina cosa puoi testare in isolamento e cosa no.

Decidere quali feedback loop introdurre — un reranker è un loop di filtraggio, un critico è un loop di correzione, entrambi feedback negativi voluti — è progettazione di sistema.

E altrettanto importante è decidere quali loop evitare: due agenti che si rinforzano a vicenda su un’assunzione sbagliata sono un feedback positivo non voluto, e il modo di prevenirlo è strutturale, non si risolve con un prompt migliore.

Capacity planning e SLO. Un sistema di serving con autoscaling è un sistema omeostatico in senso pieno: l’autoscaler è un feedback negativo che misura la latenza o la coda di richieste, la confronta con un obiettivo — lo Service Level Objective — e aggiunge o toglie capacità per contrastare gli scostamenti.

Progettarlo bene significa progettare l’omeostasi: scegliere il setpoint giusto, sensori che misurano la cosa giusta, attuatori abbastanza rapidi, e fare i conti con i ritardi — perché un feedback negativo con troppo ritardo non stabilizza, oscilla, e quel fenomeno è materia del capitolo equilibrio-stabilita (in preparazione) di questa Parte.

Eval end-to-end invece di soli unit test. Sapere che le proprietà importanti di un sistema sono emergenti — nascono dalle interazioni e non si leggono nelle parti — ha una conseguenza operativa diretta: non puoi certificare un sistema agentico testando i suoi componenti uno per uno.

Un modello che supera ogni benchmark in isolamento e tool che funzionano ciascuno per conto proprio non garantiscono un agente che funziona. Il comportamento utile è del sistema, e va misurato sul sistema intero, con eval end-to-end. La fiducia nelle parti non si somma in fiducia nel tutto.

Una checklist diagnostica. Le quattro applicazioni precedenti si possono comprimere in una sequenza di domande da farsi quando un sistema AI si comporta in modo inatteso, prima di toccare qualunque componente.

Dove passa il confine che sto assumendo, e ne esiste uno diverso da cui il problema si vedrebbe meglio? Quali sono le parti, e quali le interconnessioni — e il guasto è in una parte o in un’interazione? Cosa c’è nello stato in questo momento, e come ci è arrivato: lo stato è corrotto da qualcosa accaduto molti passi fa?

Ci sono feedback loop attivi, e di che segno: un loop che doveva contrastare l’errore lo sta amplificando? Il fenomeno che osservo vive al livello a cui sto guardando, o a un livello sopra o sotto?

Nessuna di queste domande riguarda i pesi del modello. Tutte riguardano il sistema. Farsele nell’ordine, prima di intervenire, è la differenza pratica fra un debugging guidato e un debugging a tentoni.

Dove si rompe

La teoria dei sistemi è un modo di guardare, e come ogni lente ha i suoi modi di ingannare. I più frequenti sono fraintendimenti del vocabolario stesso.

“Sistema” inteso come “computer” o “software”. Nel gergo informatico la parola “sistema” significa spesso “la macchina” o “il software in esecuzione” — system administrator, operating system. Nella teoria dei sistemi il termine è molto più astratto: un’azienda, un mercato, un ecosistema, una conversazione sono sistemi.

Un sistema AI lo è in questo senso astratto, e non coincide con il solo software che lo implementa: comprende anche l’utente, l’ambiente, le interazioni. Chi importa l’accezione informatica ristretta finisce per tracciare il confine troppo stretto, di default, senza accorgersi di averlo fatto.

Confondere “stabile” con “in equilibrio”. È l’errore che von Bertalanffy combatteva. Un organismo, un agente che si autocorregge, un sistema di serving con autoscaling sono stabili — restano vicini a un valore desiderato — ma non sono in equilibrio nel senso fisico. Sono steady state mantenuti attivamente da un flusso e da feedback.

L’equilibrio vero, per questi sistemi, è lo stato morto: il termostato spento, l’agente terminato, il corpo senza metabolismo.

Chiamare “equilibrio” la stabilità attiva fa perdere di vista che quella stabilità ha un costo continuo — il flusso, l’energia, il compute — e che se il costo si interrompe la stabilità sparisce. Il capitolo equilibrio-stabilita (in preparazione) di questa Parte tiene separati i due concetti con cura.

Trattare l’emergenza come una spiegazione. Dire “il sistema si comporta così perché è una proprietà emergente” sembra una risposta e non lo è. “Emergente” descrive un fatto — la proprietà appartiene al tutto e non si legge nelle parti — ma non indica alcun meccanismo.

È un’etichetta sul fenomeno, non la sua causa. Usata come spiegazione, l’emergenza diventa una scorciatoia che ferma l’indagine proprio dove dovrebbe cominciare. La domanda giusta dopo “è emergente” non è “ah, ecco perché”, è “da quali interazioni emerge, e come”.

Pensare che il confine sia oggettivo. Chi cerca “il” sistema, il confine vero scritto nella natura delle cose, cerca qualcosa che non esiste. Il confine è una scelta del modellatore, e scelte diverse danno problemi diversi — tutti legittimi.

L’errore non è scegliere un confine: è scegliere un confine e poi dimenticare di averlo scelto, trattandolo come un dato. Quando un’indagine si blocca, una delle mosse più produttive è proprio spostare il confine — salire al sistema multi-agente, o scendere al singolo tool — e guardare lo stesso problema da un confine diverso.

Confondere il pensiero sistemico con un misticismo dell’interconnessione. C’è una versione degradata del pensiero sistemico che si riduce allo slogan “tutto è connesso, niente si può davvero capire”. È l’opposto di ciò che la disciplina propone.

Il pensiero sistemico ha strumenti precisi — confini, stato, feedback, accumuli, flussi, livelli, leverage point — e serve proprio a rendere analizzabile ciò che a prima vista sembra un groviglio inestricabile. Non è il nemico del rigore: è rigore applicato a un livello diverso.

Il pensiero sistemico contro il riduzionismo, come se uno dei due dovesse vincere. Il pensiero analitico — scomporre un oggetto nelle parti, capire ogni parte, ricomporre — non è “sbagliato”.

È lo strumento giusto quando il comportamento del tutto è effettivamente la somma di quello delle parti, cioè quando le interazioni sono deboli o lineari. Un orologio meccanico si capisce così, perfettamente.

Il pensiero sistemico è l’altro strumento, per quando il riduzionismo fallisce — per quando il comportamento emerge dalle interazioni e scomporre fa perdere proprio l’oggetto di interesse. Sceglierne uno come ideologia, contro l’altro, è un errore di metodo. Il capitolo riduzionismo-olismo (in preparazione) di questa Parte è dedicato a quando conviene l’uno e quando l’altro.

Il rischio opposto: vedere sistemi dappertutto. Se ogni cosa è un sistema, la parola non seleziona più niente e smette di essere utile. Un mucchio di sabbia ha delle parti, ma non interazioni che producono comportamento coordinato: chiamarlo sistema non aggiunge nulla.

La lente sistemica è produttiva quando le tre clausole — parti, interconnessioni, comportamento irriducibile — reggono davvero. Quando non reggono, il vocabolario più semplice — un elenco, un aggregato, una funzione pura — è quello giusto, e insistere con “sistema” è solo decorazione.

Collegamenti

sistemi-aperti-chiusi (in preparazione) — sviluppa la distinzione fra sistemi aperti, chiusi e dissipativi qui solo introdotta; il prossimo capitolo naturale della Parte.
stato-spazio-dinamica (in preparazione) — formalizza i concetti di stato, transizione e traiettoria che qui abbiamo dato in forma intuitiva.
equilibrio-stabilita (in preparazione) — distingue con rigore equilibrio, stabilità e attrattori, e chiarisce la confusione “stabile contro in equilibrio”.
feedback-feedforward (in preparazione) — svolge il feedback, qui solo accennato, e lo confronta con il controllo in anticipo.
riduzionismo-olismo (in preparazione) — il trade-off fra pensiero analitico e pensiero sistemico, e quando conviene ciascuno.
confini-del-sistema (in preparazione) — la scelta del confine come scelta di modellazione, e come cambia il problema.
ponte-sistemi-ai (in preparazione) — il capitolo che chiude la Parte IX collegando esplicitamente la teoria dei sistemi ad agenti e deployment.
cibernetica-definizione (in preparazione) — il campo gemello, nato negli stessi anni, che mette al centro feedback e controllo, primo capitolo della Parte X.
Equazione di Bellman e MDP — gli MDP sono sistemi con stato e regola di transizione: lo stesso schema “scatola con memoria” di questo capitolo, applicato al decision making.
Equazioni differenziali a intuizione — il linguaggio matematico per descrivere come lo stato di un sistema evolve nel tempo continuo.
Monte Carlo Tree Search — un esempio di algoritmo che esplora lo spazio degli stati di un sistema decisionale.

Per andare oltre

Donella H. Meadows, Thinking in Systems: A Primer (Chelsea Green, 2008). Il testo divulgativo di riferimento per il pensiero sistemico. Pubblicato postumo, scritto per lettori non specialisti: la definizione di sistema, i due tipi di feedback loop e i leverage point sono spiegati con esempi e senza formalismo. Il punto di partenza naturale.
Ludwig von Bertalanffy, General System Theory: Foundations, Development, Applications (George Braziller, 1968). Il testo fondativo del campo. Più denso e datato del precedente, ma è la fonte diretta per la distinzione sistemi aperti/chiusi e per la tesi dell’unità formale fra discipline.
Norbert Wiener, Cybernetics: or Control and Communication in the Animal and the Machine (MIT Press, 1948). Il libro che fonda la cibernetica e mette il feedback al centro. Lettura per chi vuole risalire alla radice del legame fra controllo nelle macchine e regolazione negli organismi.
Jay W. Forrester, Industrial Dynamics (MIT Press, 1961). Il testo fondativo della system dynamics: come modellare un sistema complesso in termini di accumuli, flussi, ritardi e feedback loop, e simularlo. Tecnico, ma il capostipite di tutta una tradizione di modellazione.
System Dynamics Society, “Origin of System Dynamics” (systemdynamics.org). Una ricostruzione breve e accessibile della genesi della system dynamics al MIT negli anni Cinquanta, utile per inquadrare storicamente Forrester e il legame con l’ingegneria dei servomeccanismi.