Un agente AI può imparare dai propri errori?

Sì: dopo un errore qualcuno, una persona o un altro programma, cambia le istruzioni che l'agente segue. Il rischio è che nelle istruzioni finiscano i dettagli del caso invece della regola. In uno studio di Google Research del settembre 2026, l'evoluzione senza freni arrivava a 92,8 punti sui compiti su cui era stata corretta e a 40,3 su quelli nuovi, partendo da 39,7.

Cos'è il sovradattamento di un agente AI?

È quando l'agente impara le risposte dei casi su cui è stato corretto e non migliora su quelli nuovi. Le cause indicate dallo studio RRSI sono tre: modifiche che contengono i dettagli del caso, miglioramenti misurati una volta sola, e istruzioni che crescono senza che niente venga tolto.

Come si misura se una modifica a un agente AI funziona?

Su casi che l'agente non ha mai visto, e ripetendo la prova. Prima si misura quanto varia il risultato dello stesso agente messo alla prova due volte senza cambiare niente; un miglioramento più piccolo di quella differenza si considera fortuna. In una carpenteria metallica, istruzioni riscritte e provate 136 volte hanno passato 433 verifiche su 467 contro le 425 della versione in uso, con il 7% di consumo in meno.

Le istruzioni di un agente AI vanno anche sfoltite?

Sì. Ogni istruzione aggiunta allunga il testo che l'agente legge a ogni richiesta, quindi costa. Una regola che per mesi non ha cambiato nessuna risposta si archivia; le regole di sicurezza restano sempre, perché il loro lavoro è stare lì il giorno che servono. Nello studio RRSI i freni hanno ridotto il costo da 3,8 a 2,4 milioni di token per compito.

Come si fa migliorare un agente AI senza che impari la lezione sbagliata?

Cambiando le sue istruzioni dopo ogni errore, e mettendo quattro freni a quel cambiamento. Senza freni l'agente impara i casi che l'hanno fatto sbagliare e resta fermo su quelli nuovi: in uno studio di Google Research pubblicato il 21 settembre 2026, l'evoluzione senza freni otteneva il punteggio più alto sui compiti di prova e appena 0,6 punti in più su quelli mai visti. Con i freni il guadagno sui compiti nuovi è salito a 3,9 punti, con il 36% di token in meno. I quattro freni: ogni modifica deve valere su un caso mai visto, deve superare la variabilità normale del sistema, deve ripagare il costo che aggiunge, e ciò che smette di servire si toglie.

Chi vende agenti AI promette spesso che «imparano dall'uso». È vero in un senso preciso: dopo un errore qualcuno, una persona o un altro programma, cambia le istruzioni che l'agente segue. La domanda che conta è cosa finisce in quelle istruzioni.

Cosa impara un agente quando nessuno lo frena?

Lo studio si chiama RRSI ed è firmato da Google Cloud AI Research con la University of North Carolina, Stanford e la Washington University. Un modello ha riscritto le istruzioni di un agente giro dopo giro, sulla base dei suoi errori su 120 compiti professionali fatti di documenti, e alla fine l'agente è stato messo alla prova su compiti che non aveva mai visto.

Senza freni l'agente arrivava a 92,8 punti sui compiti su cui era stato corretto e a 40,3 su quelli nuovi, partendo da 39,7. Aveva imparato le risposte dei casi di prova. Nel frattempo era diventato più costoso: 3,8 milioni di token per compito, contro gli 1,56 di partenza.

Gli autori indicano tre cause, e le ho riconosciute tutte nel mio lavoro: la modifica che si porta dietro i dettagli del caso, il miglioramento misurato una volta sola che era soltanto fortuna, e le istruzioni che crescono senza che nessuno tolga niente.

Succede anche quando le istruzioni le corregge una persona?

Sì. Io lavoro così da mesi, senza automatismi: ogni errore di un agente diventa una regola scritta nelle sue istruzioni. È un buon metodo, e ha lo stesso difetto. La regola nasce con la data, il nome e l'importo del caso che l'ha prodotta, e sul caso successivo, che ha un altro nome e un altro importo, resta muta.

Il mio assistente personale ha una funzione di revisione automatica: a fine conversazione rilegge il lavoro fatto e salva come istruzione quello che ritiene utile per le volte successive. In un mese ha salvato 21 note, e 13 erano il resoconto di una sola giornata, con le date e le cifre di quel giorno: un giorno di lavoro archiviato come regola. A fine settembre ho bloccato le scritture automatiche su quella parte delle istruzioni, e ogni lunedì un controllo elenca cosa la revisione ha scritto nel resto.

Quali sono i quattro freni?

La modifica deve valere su un caso mai visto. Prima di provarla si rilegge con una domanda: avrebbe senso su una richiesta dello stesso tipo, arrivata da un'altra persona su un'altra pratica? Date, nomi e importi del caso si tolgono.
Il miglioramento deve superare la variabilità normale. Lo stesso agente, messo alla prova due volte senza cambiare niente, dà risultati diversi. Quella differenza si misura prima, e un miglioramento più piccolo si considera fortuna.
Il costo in più va ripagato. Ogni istruzione aggiunta allunga il testo che l'agente legge a ogni richiesta. Una modifica che costa di più deve rendere di più, in proporzione.
Ciò che smette di lavorare si toglie. Una regola che per mesi non ha cambiato nessuna risposta si archivia. Le regole di sicurezza restano sempre: il loro lavoro è stare lì il giorno che servono.

Con questi freni, nello studio, il guadagno sui compiti nuovi è salito a 3,9 punti e il costo è sceso a 2,4 milioni di token per compito. Dei cinque metodi confrontati, è l'unico che sui compiti nuovi ha superato il punto di partenza di più di un punto.

Una carpenteria metallica che lavora per commessa. Le istruzioni del suo agente erano cresciute incidente dopo incidente. A settembre le ho riscritte più corte e, prima di metterle in uso, le ho provate 136 volte su scenari presi dal lavoro reale, con i programmi veri e dati inventati. La versione nuova ha passato 433 verifiche su 467, quella in uso 425, con il 7% di consumo in meno.

Le prove hanno trovato anche un errore che la versione nuova aveva introdotto: in 6 prove su 8 proponeva un totale di contratto ricavato per proporzione, quando doveva chiederlo a chi il contratto ce l'ha. Corretto prima del rilascio, e zero casi su 16 nelle prove successive.

Nella stessa azienda, a fine settembre, sono state scartate due regole per l'agente che tiene il giornale di cantiere. La prima attribuiva una nota a una commessa solo se il messaggio la nominava con le stesse parole. Superava i test scritti a mano; messa alla prova sullo storico, cioè facendo ripassare all'agente 227 messaggi veri già registrati, per evitare un'attribuzione sbagliata ne perdeva 20 giuste. La seconda univa le note brevi a quella precedente. Nelle prove l'agente ne ha ricavato una scorciatoia, «due note scritte di seguito riguardano la stessa commessa», e aumentavano le note attribuite a una commessa che il messaggio non nominava.

Un agente che migliora deve poter dimostrare di aver imparato la regola, su casi che non conosceva.

Cosa chiedere a chi promette un agente che migliora da solo?

Su quali casi misurate il miglioramento? Se sono gli stessi da cui l'agente ha imparato, la misura dice solo che li ricorda.
Quante volte avete ripetuto la prova? Una prova sola confonde un miglioramento con una giornata fortunata.
Cosa avete tolto nell'ultimo mese? Un sistema che aggiunge e basta diventa più lento e più caro, e prima o poi si contraddice.

Per ogni agente tengo un registro delle modifiche alle sue istruzioni: cosa è cambiato, perché, con quale misura, e cosa è stato respinto. A me serve per non riprovare ciò che ha già fallito. All'azienda serve per sapere chi ha deciso ogni regola che il sistema applica.

Se un agente lo avete già, una domanda da farsi oggi: l'ultima correzione alle sue istruzioni ha migliorato qualcosa oltre il caso che l'ha fatta nascere?

How do you improve an AI agent without it learning the wrong lesson?

By changing its instructions after each mistake, and putting four brakes on that change. Without brakes the agent learns the cases that tripped it up and stays flat on new ones: in a Google Research study published on 21 September 2026, unregularized evolution scored highest on the tasks it was tuned on and gained only 0.6 points on unseen tasks. With the brakes the gain on new tasks rose to 3.9 points, on 36% fewer tokens. The four brakes: every change must hold on a case never seen before, must beat the system's normal variability, must pay for the cost it adds, and whatever stops working is removed.

People selling AI agents often promise they "learn from use". That is true in a precise sense: after a mistake someone, a person or another program, changes the instructions the agent follows. The question that matters is what ends up in those instructions.

What does an agent learn when nothing holds it back?

The study is called RRSI, by Google Cloud AI Research with the University of North Carolina, Stanford and Washington University. A model rewrote an agent's instructions round after round, based on its mistakes on 120 document-heavy professional tasks, and the agent was then tested on tasks it had never seen.

Without brakes the agent reached 92.8 points on the tasks it had been corrected on and 40.3 on new ones, starting from 39.7. It had learned the answers to the practice cases. Along the way it became more expensive: 3.8 million tokens per task, against 1.56 at the start.

The authors name three causes, and I have met all three in my own work: the change that carries the details of the case, the improvement measured once that was only luck, and instructions that keep growing while nobody removes anything.

Does it happen when a person corrects the instructions too?

Yes. I have worked this way for months, with no automation: every mistake an agent makes becomes a written rule in its instructions. It is a good method, and it has the same flaw. The rule is born with the date, the name and the amount of the case that produced it, and on the next case, with another name and another amount, it stays silent.

My personal assistant has an automatic review feature: at the end of a conversation it rereads the work done and saves as an instruction whatever it thinks will help next time. In one month it saved 21 notes, and 13 were the account of a single day, with that day's dates and figures: one day's work filed away as a rule. At the end of September I locked that part of its instructions against automatic writes, and every Monday a check lists what the review wrote in the rest.

What are the four brakes?

The change must hold on a case never seen before. Before testing it, reread it with one question: would it make sense for a request of the same kind, from another person, on another job? Dates, names and amounts from the case come out.
The improvement must beat normal variability. The same agent, tested twice with nothing changed, gives different results. That difference is measured first, and a smaller improvement counts as luck.
Extra cost must be paid for. Every added instruction lengthens the text the agent reads on every request. A change that costs more has to deliver more, in proportion.
Whatever stops working is removed. A rule that has not changed a single answer in months is archived. Safety rules always stay: their job is to be there on the day they are needed.

With these brakes, in the study, the gain on new tasks rose to 3.9 points and the cost fell to 2.4 million tokens per task. Of the five methods compared, it is the only one that beat its starting point on new tasks by more than a point.

A metal fabrication firm that works to order. Its agent's instructions had grown incident by incident. In September I rewrote them shorter and, before putting them in use, tested them 136 times on scenarios taken from real work, with the real programs and invented data. The new version passed 433 checks out of 467, the one in use 425, with 7% less consumption. The tests also caught an error the new version had introduced: in 6 runs out of 8 it proposed a contract total worked out by proportion, when it should have asked whoever holds the contract. Fixed before release, and zero cases out of 16 in the runs that followed.

In the same company, at the end of September, two rules for the agent that keeps the site log were discarded. The first assigned a note to a job only if the message named it in the same words. It passed the hand-written tests; backtested, running 227 real messages already on record back through the agent, it lost 20 correct assignments to avoid one wrong one. The second merged short notes into the previous one. In testing the agent drew a shortcut from it, "two notes written in a row are about the same job", and more notes ended up assigned to a job the message never named.

What to ask whoever promises an agent that improves by itself

Which cases do you measure the improvement on? If they are the ones the agent learned from, the measurement only says it remembers them.
How many times did you repeat the test? A single test mistakes a lucky day for an improvement.
What did you remove last month? A system that only ever adds becomes slower and more expensive, and sooner or later contradicts itself.

For every agent I keep a log of the changes to its instructions: what changed, why, with which measurement, and what was rejected. It keeps me from retrying what has already failed, and it tells the company who decided each rule the system applies. Message me on WhatsApp or write to info [chiocciola] antoniodelia.it.