La maggior parte dei team di IA che cerca di migliorare le prestazioni degli agenti ricorre alle stesse leve: finestre di contesto più ampie, più documenti e prompt più efficaci. Questo articolo sostiene che sia proprio l'approccio sbagliato. L'ingrediente mancante non sono più informazioni. È il controllo. Un livello di controllo ben progettato distingue un agente che funziona in una demo da uno che funziona in produzione.
Dare a un agente di IA più memoria, più documenti o una finestra di contesto più lunga non lo rende più intelligente, ma solo più lento e costoso. I veri miglioramenti derivano dall'insegnare all'agente a scegliere ciò che gli serve, quando gli serve, anziché elaborare tutto in una volta.
L'affidabilità dipende dal ciclo, non dal modello. La differenza tra un agente che stupisce in una demo e uno che regge in produzione non sta nella qualità dell'IA, ma nella capacità del sistema di controllare il proprio lavoro. Gli agenti che pianificano, agiscono, osservano e verificano ogni passaggio individuano i propri errori, invece di sbagliare con sicurezza.
Oggi la maggior parte degli agenti di IA è essenzialmente un chatbot con qualche passaggio in più: non dispone di alcun meccanismo per sapere se è sulla strada giusta, quando fermarsi o quando provare un approccio diverso. Aggiungere un livello di controllo adeguato, con criteri di successo chiari, stato strutturato e controlli di convalida, trasforma un oggetto a forma di agente in qualcosa di cui ci si possa davvero fidare.
Che cosa hai mangiato ieri a pranzo?
Probabilmente non hai ripercorso ogni ricordo della tua vita finché non hai trovato «ieri + pranzo». Sei andato direttamente alla parte della tua esperienza in cui si trovano quei concetti. È un modello mentale utile per creare agenti:
Una gigantesca finestra di contesto non è memoria.
Una pila di documenti recuperati non equivale alla comprensione.
Un lungo chain of thought non è sinonimo di affidabilità.
Questi sono solo ingredienti. Ma ciò che fa sembrare un agente davvero tale è la stessa cosa che impedisce al cervello di analizzare con la forza bruta tutta la storia della nostra vita: il controllo.
Una recente indagine, Agentic Reasoning for Large Language Models, ha riassunto e definito molto bene il cambiamento che molti di noi hanno percepito durante lo sviluppo: dal ragionamento all'interno del modello al ragionamento attraverso l'interazione. Questo articolo non è un riassunto di quello studio. È un tentativo di tradurre questo cambiamento in una progettazione pratica dei sistemi:
Se si progettano gli agenti come chatbot con strumenti, si continueranno a ottenere gli stessi errori dei chatbot, ma con conseguenze più costose.
Per un certo periodo, il nostro approccio predefinito per «rendere il modello più intelligente» consisteva essenzialmente in prompt migliori, chain of thought, autoconsistenza o miglioramenti basati sul campionamento e, magari, un po' di ricerca.
ReAct ha rappresentato una svolta, perché ha reso naturale la sequenza «pensiero → azione → osservazione». Ma va notato il vincolo implicito: in molti casi tutto si riduce ancora a «inferenza one-shot, ma con più token». L'impostazione dell'indagine è più netta: il ragionamento agentico punta a scalare l'interazione al momento del test, trasformando l'inferenza in un processo iterativo in cui modello, memoria e ambiente restano tutti nel ciclo.
Se hai creato o usato agenti sorprendenti nelle demo ma fragili nei flussi di lavoro reali, questo articolo è per te.
Ecco uno schema che ho visto spesso e di cui ho sicuramente creato anch'io alcune versioni:
Prendi un buon modello di chat
Aggiungi alcuni strumenti (ricerca, query sul DB, magari esecuzione di codice)
Aggiungi il RAG
Aggiungi un prompt di sistema «sei un agente autonomo»
Inserisci tutto in un ciclo while finché non si arresta o scade il tempo
Congratulazioni: hai un oggetto a forma di agente. Ma tende a fallire in modi prevedibili:
Contesto eccessivo: ogni osservazione viene aggiunta e i prompt diventano strati archeologici.
Uso casuale degli strumenti: «lo strumento sbagliato, ma usato con sicurezza» diventa la modalità di errore predefinita.
Nessuna condizione di arresto: continua perché può farlo, non perché dovrebbe.
Nessuna disciplina di ancoraggio: non si accorge di sbagliare, a meno che non lo si costringa.
Memoria = cronologia della chat: in pratica, scrivere log e chiamarli apprendimento.
Ecco perché gli «agenti» spesso sembrano magici nelle demo e caotici in produzione. Anche la nostra esperienza nel portare in produzione sistemi agentici lo conferma: quando non si valuta più un modello ma un sistema, le modalità di errore includono navigazione, uso corretto degli strumenti, selezione del contesto e progettazione delle valutazioni, non soltanto «il modello ha risposto correttamente?».
La domanda diventa quindi: qual è l'agente intenzionale?
Per rendere il concetto meno astratto, ecco un semplice flusso di lavoro che quasi tutti possono immaginare: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Una comune implementazione «a forma di agente» funziona così:
Recupera subito molti documenti sulle compagnie aeree e sulle politiche di viaggio, anche se per il momento non servono.
Richiama uno strumento di ricerca, incolla nel prompt un lungo elenco di risultati e «ne sceglie uno».
Prenota prematuramente senza verificare i vincoli relativi a orario di arrivo, bagaglio, posto e politiche.
Se non riesce, riprova in modo leggermente diverso, ma senza sapere con chiarezza cosa sia cambiato o cosa abbia imparato.
Il problema non è che il modello non sappia ragionare, ma che il sistema non controlla il flusso di lavoro.
Una versione più agentica tratta l'attività come un processo interattivo, con stato e controlli espliciti:
PIANIFICA: ribadisci i vincoli ed elenca le informazioni mancanti, ad esempio «quale aeroporto preferisci?» o «va bene uno scalo?».
AGISCI: richiama la ricerca dei voli con una query strutturata (intervallo di date, limite per l'arrivo, budget).
OSSERVA: salva i risultati in un oggetto di stato compatto (i 5 candidati migliori con prezzo, arrivo e scali), anziché incollare un'enorme massa di dati.
AGGIORNA: affina la query se i vincoli non sono soddisfatti, ad esempio: «Arrivare prima delle 18:00 è un vincolo troppo rigido: ampliare la fascia oraria o aumentare il budget?».
VERIFICA: esegui i validatori («arrivo < 18:00», «prezzo ≤ £900», «conforme alle politiche», «selezione del posto disponibile»).
FERMATI: solo quando l'API di prenotazione restituisce una conferma e tutti i validatori danno esito positivo.
Il cambiamento è sottile, ma decisivo. Il recupero è condizionale, non automatico; il contesto viene gestito, con uno stato strutturato anziché accumulato; e la verifica fa parte del ciclo, invece di essere lasciata all'utente. Si può sostituire «prenotare un volo» con «creare un ordine di acquisto», «emettere un rimborso», «modificare una configurazione di produzione» o «pubblicare una PR»: il principio non cambia. Quando l'agente può agire, il ciclo conta più del prompt.
L'indagine citata sopra organizza il ragionamento agentico in tre livelli: fondamentale (pianificazione, uso degli strumenti, ricerca), autoevolutivo (feedback e memoria) e collettivo (coordinamento multiagente).
Ma l'idea più profonda è che il ragionamento diventa il principio organizzativo di pianificazione, decisione e verifica, anziché limitarsi a generare un chain of thought plausibile. Sembra un concetto astratto, finché non lo si associa ai cambiamenti dell'architettura. I punti fondamentali da ricordare sono tre:
Un buon agente non dovrebbe considerare il recupero come qualcosa «da fare sempre». Recuperare è una decisione, non un riflesso.
Ecco un'euristica pratica:
Se il sistema recupera dati a ogni turno, non è stato creato un sistema di recupero, ma una tassa sul contesto.
Nel lavoro reale accade continuamente. Durante il debug di un incidente in produzione, non si riversano tutti i log nel contesto: si decide quali metriche o log recuperare in base all'ipotesi corrente. Questo è il «recupero agentico». Ecco uno schema più concreto:
Decidi se il recupero è necessario
Se sì: prepara una query, recupera, esamina ed estrai
Se le evidenze sono in conflitto, esegui un nuovo recupero
Solo a quel punto sintetizza
È anche qui che il «RAG agentico» inizia a differenziarsi dal RAG tradizionale: il recupero diventa una fase intenzionale del ragionamento, non uno stadio predefinito della pipeline.
Nel momento in cui si smette di valutare «un modello» e si inizia a valutare «un sistema», il monitoraggio e il tracciamento dello stato diventano importanti.
Un aspetto su cui il settore ha ormai fatto maggiore chiarezza è l'osservabilità dei flussi di lavoro degli agenti. Ad esempio, l'Agents SDK di OpenAI include funzionalità di tracciamento e una dashboard Traces che registra le esecuzioni degli agenti (generazioni, chiamate agli strumenti, passaggi di consegne, misure di protezione, eventi personalizzati), proprio per consentire il debug e la verifica puntuale di quanto accaduto.
Non è un semplice «optional». È la differenza tra un sistema di cui si può eseguire il debug e uno che si può valutare solo a sensazione.
A mio parere, la parte più concreta dell'indagine è la schiettezza con cui affronta il feedback. Suddivide il feedback in tre regimi: feedback riflessivo (genera → valuta → rivedi), adattamento parametrico (apprendimento tramite fine-tuning/RL) e feedback basato su validatori (ripeti finché un validatore non dà esito positivo).
La maggior parte dei team dovrebbe iniziare dal feedback basato su validatori, perché è poco entusiasmante ma efficace. Se si riesce a scrivere un qualsiasi validatore che esegua unit test, controlli lo schema, imponga regole o vincoli aziendali («nessun rimborso superiore a X senza escalation») oppure verifichi l'attendibilità dei fatti («citazioni obbligatorie»), si può trasformare l'output non deterministico del modello in qualcosa di cui ci si possa davvero fidare.
Uno dei cambiamenti più semplici tra quelli che «non sappiamo di non sapere» è questo: nel mondo degli agenti, l'affidabilità spesso dipende più dal ciclo che dal modello.
Ecco la più semplice disciplina ciclica che, nella mia esperienza, migliora stabilmente il comportamento senza addestramento:
Procedi per fasi: Pianifica → Agisci → Osserva → Aggiorna,
Dopo ogni azione, riassumi l'osservazione in 1-3 punti,
Fermati quando i criteri di successo sono soddisfatti o il budget è esaurito; restituisci il miglior risultato noto e le incertezze rimanenti.
L'obiettivo non è rendere prolisso il modello. L'obiettivo è rendere il sistema comprensibile e costringerlo a «confrontarsi con la realtà» a ogni passaggio. Un esempio molto familiare per chi sviluppa software è l'ancoraggio a ciclo chiuso in stile CI:
Pianifica: proponi un elenco di modifiche
Agisci: esegui test/lint
Osserva: analizza gli errori
Aggiorna: applica una correzione e riprova
Ecco alcune domande che tendono a smascherare i progetti diventati agenti per caso:
«È il mio agente a scegliere cosa recuperare o recupero sempre tutto?»
Se il recupero è incondizionato, se ne paga il prezzo in termini di latenza, costi, diluizione del contesto e maggior rischio che dati scadenti producano risultati scadenti.
«Il mio agente sa accorgersi quando sbaglia?»
Se l'unico segnale di feedback dell'agente è «l'utente si irrita», si sta facendo RL a spese dell'utente. Un ciclo di nuovi tentativi basato su validatori è il modo più lineare per imporgli un confronto con la realtà.
«La memoria è scrivibile e migliora nel tempo?»
Se la «memoria» si limita ad aggiungere la cronologia della chat, in pratica si stanno scrivendo log. Il modo in cui l'indagine inquadra la memoria è importante: diventa un contesto in crescita dinamica che gli agenti affinano nel tempo, non una semplice trascrizione.
I log indicano cosa è successo, mentre la memoria indica cosa fare la volta successiva. La cronologia della chat è una trascrizione. La memoria è una strategia in evoluzione su ciò che vale la pena conservare per il futuro.
Un pratico punto di partenza è una piccola tabella di «lezioni apprese», organizzata per tipo di attività, strumento e modalità di errore, con l'indicazione di cosa ha funzionato e cosa evitare. L'obiettivo non è creare un grafo della conoscenza perfetto. L'obiettivo è ottenere miglioramenti cumulativi: memoria e feedback trasformano gli agenti da «assistenti senza stato» in sistemi che migliorano nel tempo.
La tentazione è assegnare più agenti al problema, ma spesso ciò moltiplica il lavoro di coordinamento. Un valido schema di «team minimo funzionante»:
Coordinatore: scompone e assegna
Esecutore: richiama gli strumenti e apporta le modifiche
Critico/valutatore: controlla correttezza e rischi
Responsabile della memoria: scrive e seleziona le lezioni apprese
Se non si riesce a spiegare di cosa sia responsabile ogni agente, probabilmente non servono ancora più agenti.
Se accettiamo davvero questo cambio di paradigma, probabilmente smetteremo di inserire tutto nei prompt, trattare gli errori come output definitivi e valutare gli agenti come chatbot. E inizieremo a considerare gli agenti per ciò che sono: sistemi software in cui il linguaggio costituisce il piano di controllo e l'affidabilità dipende dal ciclo.
Prima di aggiungere un altro modello, aggiungi un altro ciclo di valutazione. Prima di recuperare tutto, rendi il recupero condizionale. Distribuisci un validatore prima di distribuirne dieci. Tratta la memoria come un insieme di decisioni strategiche, non come un database. E quando passi a un sistema multiagente, inizia con due agenti, non venti. Non sono regole, ma gli schemi che hanno superato la prova della produzione.