Come funzionano gli agenti AI: dal LLM al feedback loop

Digitare una domanda in ChatGPT e ricevere una risposta è una cosa. Chiedere a un sistema "cerca i concorrenti della mia azienda, crea un foglio di calcolo comparativo e inviamelo via email" e vederlo fare da solo, in più fasi, è un'altra cosa completamente diversa. La seconda è ciò che oggi si chiama agente AI, e capire come funziona internamente richiede di separare sei componenti che, insieme, trasformano un modello che prevede solo testo in qualcosa che decide, agisce e corregge la propria rotta.

Cos'è un agente AI

Un agente AI è un sistema costruito attorno a un LLM (modello linguistico) in grado di eseguire attività a più fasi in modo autonomo, decidendo da solo quale azione intraprendere ad ogni passo, basandosi sullo stato corrente dell'attività. La differenza principale rispetto a un chatbot comune non è il modello sottostante, di solito è lo stesso, ma l'architettura che lo circonda: memoria tra i passaggi, un ciclo di pianificazione, accesso a strumenti e un meccanismo di ripetizione fino al completamento dell'attività.

Questo cambia completamente il tipo di lavoro che il sistema può svolgere. Un chatbot risponde a una domanda e si ferma. Un agente può cercare, leggere il risultato, rendersi conto che mancano informazioni, cercare di nuovo con un termine diverso, organizzare tutto e solo allora fornire la risposta finale, senza che l'utente debba mediare ogni fase.

Il termine è diventato un ombrello usato per prodotti molto diversi tra loro: agenti di codice che modificano interi repository, agenti browser che compilano moduli e cliccano pulsanti, agenti di assistenza che consultano sistemi interni prima di rispondere a un cliente. Ciò che tutti hanno in comune, nonostante l'aspetto così diverso, è proprio questa struttura di sei componenti che questo articolo dettaglia. Comprendere ogni componente separatamente è ciò che permette di confrontare prodotti diversi in modo equo, invece di giudicare tutto dal risultato finale che appare sullo schermo.

Vale anche la pena di delimitare ciò che un agente non è. Non è un sistema con "libero arbitrio" né prende decisioni al di fuori dell'ambito definito dallo sviluppatore: l'insieme degli strumenti disponibili, i limiti di iterazione e i criteri di successo sono tutti configurati in anticipo. L'autonomia di un agente è reale all'interno di questi limiti, ma i limiti stessi continuano ad essere definiti dagli umani.

LLM: il motore di ragionamento

Il LLM è il componente che decide cosa fare dopo, ma vale la pena chiarire un malinteso comune: il modello non "ricorda" nulla tra una chiamata e l'altra. Ogni volta che l'agente ha bisogno di una decisione, costruisce un nuovo prompt completo (con cronologia, risultati degli strumenti, istruzioni) e lo invia al modello, che risponde in modo stateless, senza memoria incorporata.

Ciò che fa sembrare che il LLM "ragioni" attraverso più fasi è una tecnica chiamata chain-of-thought: invece di saltare direttamente a una risposta, il modello è indotto a esporre passaggi intermedi di ragionamento prima di decidere l'azione finale. Ciò migliora notevolmente la qualità delle decisioni complesse, perché il processo stesso di "scrivere pensando" aiuta il modello a non saltare fasi logiche importanti.

In pratica, il LLM all'interno di un agente svolge un ruolo molto specifico: guardare lo stato corrente (cosa è già stato fatto, cosa ha restituito lo strumento, qual è l'obiettivo originale) e decidere la prossima azione, che sia chiamare uno strumento, chiedere più informazioni all'utente o concludere che l'attività è terminata.

Un punto che spesso sorprende chi inizia: lo stesso modello, con lo stesso prompt, può generare decisioni leggermente diverse in esecuzioni differenti. Questo accade perché la generazione di testo in un LLM è probabilistica, non deterministica, controllata da un parametro chiamato temperatura. Negli agenti che prendono decisioni sensibili (come spostare denaro o cancellare dati), è comune impostare una temperatura bassa per ridurre questa variazione e rendere il comportamento più prevedibile, anche se mai perfettamente deterministico.

Vale anche notare che "il LLM" di un agente raramente è una singola chiamata al modello. I sistemi più sofisticati utilizzano modelli diversi per fasi diverse: un modello più economico e veloce per decisioni semplici di instradamento, e un modello più grande e costoso solo per i passaggi che richiedono davvero un ragionamento profondo. Questa divisione del lavoro aiuta a controllare i costi senza sacrificare la qualità dove conta.

Memoria

Poiché il modello non conserva nulla da solo, tutta la "memoria" di un agente è, in realtà, ingegneria del contesto: decidere cosa rimettere nel prompt ad ogni chiamata. In pratica, esistono due tipi:

• Memoria a breve termine: la cronologia della conversazione o dell'esecuzione corrente, che rientra nella finestra di contesto del modello. Cresce ad ogni passo dell'agente e, in attività lunghe, potrebbe dover essere riassunta per non superare il limite di token.
• Memoria a lungo termine: informazioni che devono sopravvivere oltre una singola esecuzione, conservate al di fuori del modello, in un database, un file o un indice vettoriale, e recuperate su richiesta quando rilevanti. La tecnica più comune per questo è il RAG (retrieval-augmented generation): prima di rispondere, il sistema cerca i brani più rilevanti di questa memoria esterna e li inietta nel prompt.

Un esempio pratico aiuta a fissare la differenza: un agente di programmazione che legge il codice di un progetto conserva il file aperto al momento come memoria a breve termine, ma le convenzioni del team (come "usa sempre TypeScript strict" o "non usare mai la libreria X") di solito vengono salvate come memoria a lungo termine, in un file di configurazione che viene ricaricato ad ogni nuova sessione.

La finestra di contesto di un modello, per quanto grande, ha un limite fisico di token, e ogni token costa denaro e tempo di elaborazione. Questo obbliga chi costruisce l'agente a prendere decisioni costanti su cosa vale la pena mantenere nella memoria a breve termine e cosa può essere riassunto o scartato. Una tecnica comune è la compressione progressiva: ogni certo numero di passi, l'agente stesso genera un riepilogo di ciò che è accaduto fino a quel momento, sostituisce la cronologia grezza con questo riepilogo e prosegue l'esecuzione con un contesto molto più snello.

Per la memoria a lungo termine basata su RAG, il meccanismo alla base coinvolge solitamente un database vettoriale: ogni frammento di informazione viene convertito in un vettore numerico (embedding) che rappresenta il suo significato, e la ricerca non cerca parole esatte, ma i vettori più simili semanticamente alla domanda corrente. Ecco perché un agente con RAG ben configurato può trovare un documento rilevante anche se utilizza parole completamente diverse da quelle digitate dall'utente.

Pianificazione

Di fronte a un'attività complessa, un agente raramente risolve tutto in un'unica chiamata al modello. Il modello più utilizzato oggi è il ReAct (Reasoning and Acting), pubblicato nel 2022: il modello alterna tra "pensare" (ragionare su cosa fare) e "agire" (chiamare uno strumento), osservando il risultato di ogni azione prima di decidere la successiva, invece di cercare di prevedere l'intero piano in una volta sola.

Esiste anche il modello "plan-and-execute", in cui il modello prima scrive un piano completo con diverse fasi, e solo dopo inizia ad eseguirle una per una. Tende ad essere più prevedibile, ma meno flessibile: se una fase a metà strada fallisce o rivela nuove informazioni, l'agente deve ri-pianificare, cosa che non sempre viene gestita automaticamente in questo design.

In pratica, la maggior parte degli agenti di produzione combina i due: un piano iniziale approssimativo, rivisto ogni pochi passi in base a ciò che è realmente accaduto, invece di essere seguito ciecamente dall'inizio alla fine.

Un esempio concreto del modello ReAct in azione: chiedi a un agente "qual è l'orario di apertura del negozio più vicino a me che ha il prodotto X in magazzino". Un piano rigido, fatto tutto in una volta, probabilmente fallirebbe, perché l'agente non sa ancora quali negozi esistono né quali hanno il prodotto. Con ReAct, il modello prima ragiona ("devo trovare negozi vicini"), agisce (chiama uno strumento di ricerca per località), osserva il risultato, ragiona di nuovo ("ora devo controllare il magazzino di ciascuno"), agisce di nuovo, e solo allora, con informazioni sufficienti, formula la risposta finale. Ogni decisione dipende dal risultato della precedente, cosa che sarebbe impossibile prevedere in un piano unico e fisso.

Esiste anche la questione della profondità di pianificazione: le attività semplici possono saltare la fase di pianificazione esplicita e andare direttamente alla scelta dello strumento, mentre le attività complesse, con molte dipendenze tra sotto-attività, beneficiano di un piano scritto in modo esplicito, a volte anche mostrato all'utente prima di iniziare l'esecuzione, in modo che possa approvare o modificare la rotta prima che venga intrapresa qualsiasi azione reale.

Strumenti

Gli strumenti sono ciò che danno all'agente la capacità di agire nel mondo reale, oltre a generare solo testo: cercare sul web, eseguire codice, consultare un database, inviare un'email. Il meccanismo tecnico alla base è il function calling (o tool calling): lo sviluppatore descrive ogni strumento disponibile, con nome, descrizione e uno schema dei parametri che accetta, e il modello restituisce una risposta strutturata indicando quale strumento chiamare e con quali argomenti.

Il modello stesso non esegue mai lo strumento. Decide e formatta solo la chiamata; chi effettivamente esegue il codice, fa la richiesta HTTP o consulta il database è il software attorno al modello. Questa separazione è importante: significa che lo stesso "cervello" può essere collegato a strumenti completamente diversi senza bisogno di essere riaddestrato, solo riconfigurando quali funzioni sono disponibili nel prompt.

Il Model Context Protocol (dettagliato nell'articolo precedente su MCP) risolve proprio la parte di standardizzare come questi strumenti vengono descritti e scoperti, in modo che un agente non abbia bisogno di un'integrazione specifica per ogni servizio esterno che utilizza.

In pratica, gli strumenti di un agente tendono a raggrupparsi in alcune categorie ricorrenti: ricerca e lettura di informazioni (web, documenti, database), azione su sistemi esterni (inviare email, creare un ticket, aggiornare un foglio di calcolo), esecuzione di codice (eseguire uno script, una query SQL, un comando di terminale) e comunicazione con l'utente stesso (chiedere conferma, fare una domanda di chiarimento). Un agente ben progettato di solito non riceve accesso a tutti gli strumenti disponibili nel sistema in una volta, ma solo al sottoinsieme necessario per l'attività in questione, seguendo lo stesso principio del minimo privilegio utilizzato nella sicurezza dei sistemi tradizionali.

La qualità della descrizione di ogni strumento conta più di quanto sembri. Un nome vago come process_data con una descrizione di una riga tende a generare chiamate errate o mal formattate, perché il modello non ha abbastanza contesto per decidere quando usarlo. Descrizioni specifiche, con esempi di utilizzo e limiti chiari (cosa lo strumento non fa), riducono notevolmente il tasso di errore in questa fase.

Esecuzione

L'esecuzione è il livello software, solitamente chiamato runtime o orchestratore dell'agente, che riceve la decisione del LLM e la mette effettivamente in pratica: chiama l'API giusta, esegue il comando, attende la risposta, gestisce gli errori se la chiamata fallisce. È qui che entrano in gioco anche i livelli di sicurezza: sandboxing per il codice generato dal modello, limiti di tempo (timeout) per ogni chiamata e validazione dei parametri prima di eseguire qualsiasi cosa irreversibile.

Un dettaglio che genera confusione: non tutta l'esecuzione è sequenziale. Gli agenti più sofisticati possono attivare più strumenti in parallelo quando sono indipendenti tra loro, come cercare in tre fonti diverse contemporaneamente, riducendo notevolmente il tempo totale dell'attività rispetto a chiamare uno strumento alla volta e attendere ogni risposta prima di procedere.

La gestione degli errori a questo livello è ciò che separa un agente fragile da uno affidabile. Una chiamata a uno strumento può fallire per decine di motivi: l'API esterna è fuori servizio, i parametri sono mal formattati, l'autorizzazione è stata negata, il timeout è scaduto. Un orchestratore ben costruito cattura ogni tipo di errore separatamente e decide cosa farne: riprovare automaticamente (con un limite di tentativi, per non ripetere un errore permanente all'infinito), restituire l'errore al LLM come parte dell'osservazione in modo che provi un approccio diverso, o escalare il problema all'intervento umano quando nessuna delle opzioni automatiche risolve.

Il sandboxing merita una menzione a parte quando lo strumento coinvolge l'esecuzione di codice generato dal modello stesso. Eseguire questo codice direttamente nello stesso ambiente in cui vive l'agente è un rischio reale, quindi le implementazioni serie isolano questa esecuzione in un contenitore o macchina virtuale usa e getta, senza accesso alla rete o a file sensibili per impostazione predefinita, liberando solo ciò di cui l'attività specifica ha realmente bisogno.

Feedback loop

Dopo che uno strumento viene eseguito, il suo risultato non scompare: torna nel contesto, come una nuova informazione che il LLM deve tenere in considerazione nella decisione successiva. Questo ciclo (percepire lo stato, pianificare, agire, osservare il risultato, aggiornare il contesto) si ripete tutte le volte necessarie fino a quando accade una di due cose: il modello decide che l'attività è completa, oppure l'agente raggiunge un limite di sicurezza, come un numero massimo di iterazioni o un tempo totale di esecuzione.

Questo limite di iterazioni non è un dettaglio minore. Senza di esso, un agente mal configurato può entrare in un ciclo in cui ripete la stessa azione senza mai considerare l'attività completata, spendendo token (e denaro) all'infinito. Per questo motivo, praticamente ogni framework serio per agenti incorpora una qualche forma di blocco: un contatore massimo di passi, un controllo esplicito del criterio di successo, o la richiesta di conferma umana dopo un certo numero di tentativi senza progresso.

Vale la pena distinguere due tipi di arresto. L'arresto "felice" si verifica quando il LLM valuta lo stato corrente rispetto all'obiettivo originale e conclude, in modo esplicito, che tutti i criteri sono stati soddisfatti. L'arresto per limite si verifica quando l'agente esaurisce il numero di iterazioni o il budget di tempo/costo consentito senza arrivarci, e in questo caso il comportamento previsto non è semplicemente bloccarsi, ma segnalare all'utente cosa è stato fatto fino a quel punto e perché l'attività non ha potuto essere completata da sola.

Un modello sempre più comune nei sistemi di produzione è l'human-in-the-loop: per azioni ad alto rischio (spostare denaro, cancellare dati, inviare una comunicazione pubblica), il ciclo di feedback include una pausa obbligatoria in attesa dell'approvazione umana prima di procedere all'iterazione successiva, anche se l'agente ha già deciso, da solo, che quella è l'azione corretta.

Il ciclo completo, in diagramma

Unendo i sei componenti, il ciclo di un agente AI si presenta così:

Il punto centrale di questo schema è che la freccia di ritorno non è un dettaglio estetico: è ciò che separa un agente da un semplice flusso automatizzato di fasi fisse. L'agente decide, ad ogni giro del ciclo, se deve continuare o se ha già raggiunto l'obiettivo.

Chatbot vs agente

Vale la pena metterli a confronto, perché il confine tra i due non è sempre ovvio per chi utilizza il prodotto finale:

Aspetto	Chatbot tradizionale	Agente AI
Struttura della risposta	Una domanda, una risposta	Più fasi concatenate fino al completamento di un obiettivo
Accesso agli strumenti	Raro o inesistente	Centrale, tramite function calling o MCP
Memoria tra i passaggi	Solo la cronologia della conversazione attuale	Breve e lungo termine, spesso con ricerca esterna (RAG)
Autonomia decisionale	Bassa, l'utente guida ogni scambio	Alta, il sistema stesso decide i passi successivi
Criterio di arresto	Fine del messaggio generato	Criterio di successo dell'attività o limite di iterazioni

In pratica, il confine è uno spettro, non una linea netta: molti prodotti oggi sono chatbot con alcuni semplici strumenti collegati, senza arrivare ad avere un ciclo di pianificazione completo. Il termine "agente" tende ad essere riservato a sistemi che decidono realmente i propri passi successivi, non solo eseguono una funzione quando l'utente lo chiede esplicitamente.

Un test pratico per distinguere i due quando si valuta un prodotto: chiedi un'attività che richiede almeno tre fasi dipendenti tra loro, senza dettagliare il procedimento, solo il risultato desiderato. Un chatbot tende a chiedere più istruzioni o a cercare di risolvere tutto in una risposta unica e superficiale. Un vero agente scompone la richiesta in sotto-attività, utilizza strumenti per risolverle ciascuna e fornisce il risultato finale solo dopo aver completato l'intero ciclo da solo.

Esempio completo

Per rendere tutto concreto, vale la pena seguire un agente ipotetico di ricerca di mercato che riceve la richiesta: "cerca i 3 principali concorrenti della mia azienda in Brasile e inviami un riepilogo via email".

Passo 1, pianificazione: il LLM scompone la richiesta in sotto-attività: cercare concorrenti, raccogliere dati su ciascuno, sintetizzare in un riepilogo, inviare via email. Questo piano iniziale viene conservato nella memoria a breve termine dell'esecuzione.

Passo 2, primo strumento: l'agente chiama uno strumento di ricerca sul web con la query "principali concorrenti [azienda] Brasile". Il risultato (un elenco di nomi e link) torna come osservazione.

Passo 3, feedback e ri-pianificazione: il LLM osserva che la ricerca ha restituito 5 nomi, ma ne servono solo 3. Filtra i più rilevanti e decide, per ciascuno, di chiamare un nuovo strumento che estrae dati pubblici di base (dimensioni, prodotti principali, presenza sul mercato).

Passo 4, esecuzione parallela: poiché i tre concorrenti sono indipendenti tra loro, l'orchestratore attiva le tre chiamate di estrazione contemporaneamente, invece di una dopo l'altra, risparmiando tempo totale.

Passo 5, sintesi: con i tre set di dati nella memoria a breve termine, il LLM genera il testo del riepilogo comparativo, già formattato.

Passo 6, ultimo strumento: l'agente chiama lo strumento di invio email, passando il riepilogo generato come corpo del messaggio.

Passo 7, conclusione: il LLM osserva la conferma di invio, verifica che tutti gli elementi del piano iniziale siano stati soddisfatti e termina il ciclo, rispondendo all'utente che l'attività è stata completata.

Nota che, in nessun momento, l'utente ha dovuto intervenire tra un passo e l'altro. Ciò è possibile solo perché ciascuno dei sei componenti (LLM, memoria, pianificazione, strumenti, esecuzione, feedback loop) ha svolto esattamente il ruolo descritto nelle sezioni precedenti.

FAQ

Un agente AI ha sempre bisogno di memoria a lungo termine?

No. Le attività semplici, risolte in un'unica sessione, possono funzionare solo con memoria a breve termine (la cronologia dell'esecuzione corrente). La memoria a lungo termine è importante quando l'agente deve ricordare qualcosa tra esecuzioni diverse.

Quante iterazioni fa di solito un agente prima di fermarsi?

Varia molto con la complessità dell'attività e la configurazione del framework utilizzato, ma la maggior parte dei sistemi di produzione imposta un limite esplicito, generalmente tra 5 e 25 iterazioni, per evitare loop infiniti.

Un chatbot con plugin è già un agente?

Dipende da quanta autonomia ha. Se l'utente deve chiedere esplicitamente ogni azione, è più un chatbot con strumenti. Se il sistema decide da solo la sequenza di azioni necessarie per raggiungere un obiettivo, questo è già comportamento da agente.

Cosa succede se uno strumento fallisce a metà dell'esecuzione?

Dipende dall'orchestratore. Le implementazioni robuste restituiscono l'errore come parte dell'osservazione, e il LLM decide se riprovare, provare un approccio diverso o segnalare il fallimento all'utente, invece di bloccare l'intero ciclo.

È possibile che un agente utilizzi più di un LLM contemporaneamente?

Sì, ed è sempre più comune. Un modello più piccolo ed economico può gestire decisioni semplici di instradamento, mentre un modello più grande entra solo nelle fasi che richiedono un ragionamento più profondo, aiutando a controllare il costo totale dell'esecuzione senza perdere qualità nelle parti che contano di più.

Togliendo il gergo, un agente AI non è una tecnologia nuova isolata, ma un modo specifico di organizzare componenti già noti (un modello linguistico, un qualche tipo di memoria, accesso a strumenti) in un ciclo che si ripete fino al raggiungimento di un obiettivo. Comprendere questi sei componenti separatamente è ciò che rende possibile diagnosticare perché un agente specifico fallisce, si blocca in un loop o fornisce un risultato incompleto, invece di trattare l'intero sistema come una scatola nera.