Da due anni il discorso sugli agenti AI ha un ritornello fisso: dagli più memoria e diventerà più bravo. Più contesto, più storico, più documenti recuperati, più esperienza accumulata. Una ricerca di IBM Research pubblicata ad agosto 2026 dice che quel ritornello è sbagliato, e lo dice con i numeri. Il team ha testato otto modelli, dai 117 miliardi di parametri open weight fino ai frontier proprietari, misurando cosa succede quando si inietta memoria agentica in dosi diverse. Il risultato è controintuitivo: quanta memoria serve a un agente AI non ha una risposta unica, su un modello la dose piena non produce alcun guadagno misurabile, su un altro ne produce nove punti ma costa il 78% di token in più. La memoria, scrivono, è una dose da calibrare, non una funzione da accendere.
In questo articolo scoprirai:
- Cosa ha misurato davvero IBM: otto modelli, 585 task, tre dosi di memoria
- Come funziona ALTK-Evolve: l'agente impara dalle sue tracce senza riaddestramento
- La curva dose-risposta: tre comportamenti diversi a seconda del modello
- Perché più contesto peggiora il ragionamento: il conto dell'attenzione
- Quanta memoria serve a un agente AI: cosa cambia in azienda
Cosa ha misurato davvero IBM: otto modelli, 585 task, tre dosi di memoria
L’esperimento gira su AppWorld, un benchmark presentato ad ACL 2024 che simula nove applicazioni quotidiane, Gmail, Venmo, Spotify, Amazon, Todoist, Splitwise e altre, operabili tramite 457 API, con circa cento utenti fittizi e le loro attività digitali. Non è un quiz: l’agente deve scrivere codice interattivo, chiamare API in sequenza, gestire casi limite. Per dare la misura della difficoltà, GPT-4o nel 2024 risolveva circa il 49% dei task “normal” e il 30% di quelli “challenge”.
IBM ha usato 585 task del benchmark (168 test_normal più 417 test_challenge) e ha valutato ogni modello su due metriche: la TGC, cioè la percentuale di singoli task completati, e la SGC, molto più severa, che considera superato uno scenario solo se l’agente riesce su tutte le varianti, dati diversi, frasi diverse, condizioni al contorno diverse. È la differenza tra “funziona” e “funziona sempre”, che in azienda è tutta la differenza che conta.
Su questo impianto sono state confrontate tre configurazioni: nessuna memoria (l’agente così com’è), set completo di linee guida iniettato a ogni passo di ragionamento, e recupero curato, un nucleo fisso di regole ad alta confidenza più le linee guida pertinenti al singolo task, recuperate su misura. Tre dosi, stesso agente, stesso benchmark. Il confronto è pulito proprio perché l’unica variabile che cambia è quanta memoria entra nel contesto.
Come funziona ALTK-Evolve: l’agente impara dalle sue tracce senza riaddestramento
Il metodo si chiama ALTK-Evolve ed è un ciclo in quattro tempi. L’agente esegue i task di un insieme di addestramento e produce tracce, sia dei successi sia dei fallimenti. Da quelle tracce vengono estratte linee guida comportamentali: strategie che hanno funzionato, errori da non ripetere, casi limite incontrati. Le linee guida vengono consolidate in un insieme riutilizzabile. Infine, al momento dell’inferenza, quell’insieme viene consegnato all’agente attraverso il contesto.
Il punto architetturale è dichiarato esplicitamente da IBM: l’apprendimento avviene attorno al modello, non dentro di esso. Nessun aggiornamento dei pesi, nessuna annotazione umana, nessun fine-tuning. È per questo che lo stesso impianto ha potuto girare su otto architetture diverse senza modifiche, ed è anche il motivo per cui è replicabile da chi non addestra modelli propri ma li orchestra, che è la condizione della quasi totalità delle aziende. Se il meccanismo dei pesi e del contesto non vi è familiare, la nostra guida su come funziona davvero un modello di AI spiega la differenza tra ciò che il modello “sa” e ciò che gli passi ogni volta.
Nella variante a recupero curato la selezione avviene per similarità semantica tra il task in corso e le linee guida disponibili, lo stesso meccanismo che regge i sistemi RAG e che abbiamo raccontato parlando di similarità coseno. IBM indica proprio qui il lavoro futuro: sostituire la similarità con un selettore addestrato sul segnale di esito, perché “vicino” non significa “utile”.
La curva dose-risposta: tre comportamenti diversi a seconda del modello
Il risultato più utile della ricerca è che i modelli non stanno su una scala unica. Si dividono in tre famiglie, e ogni famiglia vuole una dose diversa.
Modelli deboli: il recupero curato vince su accuratezza e su costo insieme
Su gpt-oss-120b il completamento dei task passa dal 39,9% al 56,0% con il recupero curato: +16,1 punti percentuali con appena il 5% di token in più. Lo stesso modello con il set completo di linee guida guadagna meno e spende il 51% di token in più. Il set pieno lo affoga: riceve tutto, comprese le regole irrilevanti per il task che sta facendo, e usa il suo budget di attenzione per gestire rumore. Qui la versione più accurata è anche la più economica, il che è raro abbastanza da meritare attenzione.
Modelli forti e modelli saturi: dose piena oppure niente
DeepSeek-V3.2 sale dal 79,8% all’89,3% (+9,5pp) con il set completo, Claude Opus 4.6 dal 90,5% al 94,6%, GPT-5.5 dal 92,3% al 95,2%. Hanno capienza per assorbire tutto, casi rari inclusi, ma pagano: DeepSeek passa da 148K a 263K token per task, +78%. Poi c’è GLM-5, ed è il dato che nessuno si aspetta: 87,5% con memoria, 87,5% senza, zero guadagno misurabile in entrambe le configurazioni. Sul caso più interessante del confronto costi, un modello che paga senza guadagnare, manca però il numero: IBM non riporta il costo in token per GLM-5, quindi l’entità dello spreco resta non quantificata. IBM non lo spaccia per successo, raccomanda di non aggiungere memoria finché non si capisce quali siano i modi di fallimento residui. In tutti i casi i guadagni sulla metrica severa SGC superano quelli sulla TGC: le linee guida servono soprattutto a rendere l’agente affidabile su ogni variante, non a farlo brillare in media.
Perché più contesto peggiora il ragionamento: il conto dell’attenzione
Il meccanismo dietro questi numeri non è misterioso ed è documentato altrove. Anthropic, nella sua guida al context engineering, lo formula così: “man mano che il numero di token nella finestra di contesto cresce, la capacità del modello di richiamare accuratamente le informazioni presenti in quel contesto diminuisce”. La causa è architetturale, nei large language model le relazioni a coppie fra token crescono col quadrato, e produce quello che Anthropic chiama un budget di attenzione finito, analogo alla memoria di lavoro umana. L’obiettivo diventa allora trovare il più piccolo insieme possibile di token ad alto segnale.
La misura indipendente esiste. La ricerca di Chroma sul context rot ha testato 18 modelli, Claude, GPT, Gemini, Qwen, su cinque esperimenti controllati e conclude che “le prestazioni del modello degradano costantemente al crescere della lunghezza dell’input”, anche su compiti banali come replicare un testo. Il degrado è più rapido quando l’informazione utile è semanticamente lontana dalla domanda, cioè esattamente la condizione di un archivio di memoria cresciuto senza potatura.
Ne segue una regola di igiene che i manuali operativi già raccomandano: memorie con timestamp, provenienza e condizioni di scadenza, strategie di decadimento, “progettare il percorso di cancellazione prima di averne bisogno”. Chi accumula senza cancellare non sta costruendo memoria: sta costruendo rumore con l’etichetta giusta.
Quanta memoria serve a un agente AI: cosa cambia in azienda
La conseguenza pratica è che la domanda “quanta memoria diamo all’agente?” non ha una risposta comprabile a scaffale. Dipende dal modello che usate, dai task che gli assegnate e dai fallimenti che osservate, e le tre cose si scoprono solo misurando sul vostro caso, non leggendo una scheda prodotto. È lo stesso motivo per cui, come abbiamo scritto altrove, nell’AI agent enterprise il servizio conta più del modello: la parte difficile non è scegliere il motore, è calibrarlo su un processo reale.
La memoria è anche una voce di costo
C’è anche una lettura economica diretta. Se il set completo costa +78% di token per un guadagno di pochi punti, e il recupero curato ne costa +5% per un guadagno maggiore, allora la calibrazione della memoria è una voce del costo di un agente AI in azienda, non un dettaglio tecnico. E aiuta a spiegare una delle cause per cui i POC si bloccano: il pilota funziona con poca storia accumulata, poi in produzione l’archivio cresce, il recupero peggiora e l’affidabilità scende senza che nessuno abbia cambiato una riga.
Tarare la memoria dell’agente AI sui processi, non da manuale
È qui che, in Mimír AI Agent, abbiamo scelto di non fermarci al prodotto: accompagniamo l’onboarding con un’assistenza dedicata proprio perché decidere cosa l’agente deve ricordare, cosa deve dimenticare e quando, è un lavoro di taratura sui vostri processi, non una configurazione da manuale. Un agente ben calibrato su poca memoria pertinente batte un agente che ha letto tutto.
Se avete un processo aziendale su cui state valutando un agente AI e vi trovate davanti proprio questa domanda, quanta memoria, quale, gestita come, potete parlarne con noi. Guardiamo insieme il caso concreto e cosa serve davvero per farlo funzionare oltre il pilota.
Fonti:
- IBM Research — How Much Memory Does Your Agent Actually Need? (ALTK-Evolve)
- IBM — ALTK-Evolve: on-the-job learning for AI agents (annuncio ufficiale)
- AppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents (ACL 2024)
- Anthropic — Effective context engineering for AI agents
- Chroma Research — Context Rot: How Increasing Input Tokens Impacts LLM Performance (report tecnico completo)
- Machine Learning Mastery — 7 Steps to Mastering Memory in Agentic AI Systems
Domande frequenti
Dare più memoria a un agente AI lo rende sempre più accurato?
No. La ricerca IBM su otto modelli mostra tre comportamenti diversi: sui modelli più deboli il set completo di linee guida peggiora il rapporto costo-beneficio rispetto al recupero curato, sui modelli forti la dose piena aiuta ma costa fino al 78% di token in più, e su GLM-5 non produce alcun guadagno misurabile. La quantità di memoria è una dose da calibrare sul singolo modello.
Cos'è ALTK-Evolve e in cosa differisce dal fine-tuning?
ALTK-Evolve è il metodo IBM con cui un agente estrae linee guida comportamentali dalle tracce dei propri successi e fallimenti, le consolida e le riceve nel contesto al momento dell'inferenza. L'apprendimento avviene attorno al modello e non dentro di esso: nessun aggiornamento dei pesi, nessuna annotazione umana, nessun riaddestramento. Per questo lo stesso impianto gira su architetture diverse senza modifiche.
Perché un contesto più lungo può peggiorare le prestazioni di un agente?
Perché il budget di attenzione è finito: le relazioni a coppie fra token crescono col quadrato della lunghezza, e la capacità di richiamare accuratamente un'informazione presente nel contesto diminuisce man mano che il contesto cresce. La ricerca Chroma su context rot lo ha misurato su 18 modelli, riscontrando un degrado costante anche su compiti banali. L'effetto è più rapido quando l'informazione utile è semanticamente lontana dalla domanda.
