Anatomia di un agente AI: loop, strumenti, memoria

Date a un assistente di programmazione il compito «il test test_login fallisce, sistemalo». Un modello linguistico da solo vi risponderebbe con un elenco di ipotesi plausibili su cosa potrebbe essere andato storto. Un agente, invece, apre il file di test, lo legge, apre il codice che testa, lancia il test per vedere l’errore reale, formula un’ipotesi, modifica una riga, rilancia il test, e se è ancora rosso ci riprova. Alla fine — a volte — il test è verde. Il modello sotto è lo stesso in entrambi i casi. A cambiare è tutto ciò che gli hanno costruito intorno. La parola «agente» oggi è appiccicata a qualsiasi prodotto che contenga un LLM, ma dietro c’è un’architettura sorprendentemente sobria, fatta di tre pezzi: un loop, degli strumenti, una memoria. Vale la pena aprirla e guardarci dentro.

Il loop: il motore che nessuno vede

Il cuore di un agente non è il modello: è il ciclo che lo avvolge. A ogni giro l’agente percepisce lo stato delle cose — la richiesta iniziale più l’esito dell’ultima azione — il modello decide quale sia il passo successivo, l’azione viene eseguita, e il risultato rientra come nuova percezione. Il giro ricomincia finché il compito è chiuso o qualcosa lo interrompe.

È la stessa logica di chi cucina seguendo il gusto invece della ricetta: assaggi (percezione), decidi che manca sale (decisione), lo aggiungi (azione), riassaggi (nuova percezione), e continui finché il piatto ci sta. La differenza rispetto a una singola domanda a ChatGPT è tutta in quel riassaggiare: l’output di un passo diventa l’input del passo dopo. Il modello smette di essere un oracolo interrogato una volta e diventa un processo che si corregge strada facendo.

In codice, il loop è quasi sempre un banale while di poche righe: componi il prompt con lo storico, chiami il modello, controlli se la risposta chiede di usare uno strumento, lo esegui, accodi il risultato, ripeti. La parte difficile non è il ciclo — è decidere cosa metterci dentro a ogni giro.

Il ciclo percezione–azione: l’esito di ogni azione torna dentro come nuova percezione. Al centro, la memoria mantiene il contesto da un giro all’altro.

Gli strumenti: dare mani a chi sa solo parlare

Un modello linguistico, da solo, sa fare una cosa: produrre testo. Gli strumenti — i tool — sono ciò che trasforma quel testo in effetti reali: una ricerca sul web, una query a un database, l’invio di una email, l’esecuzione di uno script. Il meccanismo è questo: lo sviluppatore descrive ogni strumento (nome, cosa fa, quali parametri accetta); il modello, quando serve, produce una richiesta strutturata di usarne uno; il codice attorno la esegue e restituisce il risultato al modello.

C’è un punto che sfugge quasi sempre: il modello non esegue niente. Somiglia a un regista che grida «motore, azione»: indica cosa fare e quando, ma non impugna la telecamera. L’azione vera avviene fuori, nel codice dell’applicazione. Questo confine è anche il luogo dove si gioca la sicurezza. Ogni strumento è un permesso concesso, e dare a un agente il tool «esegui questo comando sul server» è una scelta di natura completamente diversa dal dargli «leggi il meteo di domani».

La qualità di un agente dipende, in misura che stupisce, dalla qualità delle descrizioni. Un tool spiegato male è un cassetto senza etichetta: il modello non sa quando aprirlo, e a volte lo apre nel momento sbagliato.

La memoria: perché un modello smemorato sembra ricordare

Il terzo pezzo aggira un limite di fondo: i modelli non ricordano nulla tra una chiamata e l’altra. Ogni invocazione riparte da foglio bianco; ciò che il modello «sa» della conversazione è soltanto ciò che gli viene ripassato nel prompt. La memoria di un agente è quindi una finzione costruita bene, su più livelli.

• Memoria di lavoro: lo storico del compito in corso — messaggi, azioni, risultati — reinserito nel contesto a ogni giro. È la più immediata e la più costosa: cresce a ogni passo e prima o poi urta il tetto della finestra di contesto.
• Memoria compressa: quando lo storico si allunga troppo, l’agente lo riassume e va avanti col riassunto. Si perde dettaglio, si guadagna spazio, come prendere appunti di una riunione invece di trascriverla parola per parola.
• Memoria a lungo termine: informazioni salvate fuori dal modello — su file, in un database, in un archivio vettoriale — e recuperate quando servono. È ciò che permette a un agente di ricordare le vostre preferenze la settimana dopo.

Buona parte dell’ingegneria degli agenti è, in fondo, gestione della memoria: decidere cosa tenere nel contesto, cosa comprimere, cosa archiviare, cosa ripescare. Chi ci ha lavorato lo conferma: gli agenti falliscono più per un contesto gestito male che per un modello poco brillante.

Dove il meccanismo si rompe

La stessa struttura che li rende capaci li rende fragili. Il loop può girare a vuoto: l’agente tenta un’azione, fallisce, ritenta la stessa azione, fallisce di nuovo — un criceto nella ruota convinto di avanzare. E gli errori si accumulano: se ogni passo ha il 95% di probabilità di riuscire, dopo venti passi la probabilità che sia andato tutto liscio scende sotto il 36%. È un’aritmetica implacabile che una singola chiamata al modello non affronta mai, e un agente sì.

Un agente non è un modello più intelligente: è lo stesso modello messo nelle condizioni di riprovare, verificare e correggersi — e, allo stesso tempo, di sbagliare in modi nuovi.

Per questo ogni agente costruito con criterio ha dei guardrail: un tetto massimo di iterazioni, timeout, richieste di conferma umana prima delle azioni irreversibili, un registro di ogni decisione. Non sono zavorra: sono la linea che separa uno strumento affidabile da uno che, una notte, vi «riordina» la casella email cancellando metà dei messaggi.

Perché vi riguarda

Nei prossimi anni userete sempre più software fatto così: assistenti che prenotano, sistemi che rispondono ai clienti, strumenti che scrivono ed eseguono codice al posto vostro. Sapere cosa c’è dentro — un loop, degli strumenti, una memoria — vi dà tre vantaggi concreti. Primo: sapete dove guardare quando qualcosa va storto, e quasi sempre la causa è un contesto gestito male o un tool descritto peggio, non «il modello è stupido». Secondo: sapete quali domande fare prima di dare fiducia a un agente — quali strumenti ha? chi ha deciso di darglieli? cosa succede se sbaglia? Terzo: se scrivete software, ora sapete che costruire un agente è meno esoterico di come lo si racconta, e che la parte difficile non è il ciclo while ma tutto ciò che serve perché quel ciclo non combini guai.