Gli agenti AI progettati per lavorare su conversazioni, documenti e attività che si sviluppano nel tempo incontrano presto un limite concreto: la memoria. Quando un sistema deve recuperare decisioni precedenti, istruzioni, azioni eseguite, risultati intermedi e informazioni raccolte in più sessioni, il semplice accumulo del contesto diventa inefficiente. Le finestre contestuali si riempiono rapidamente, i sistemi di retrieval riportano dati poco rilevanti e il costo dell’inferenza cresce insieme al numero di token elaborati.
MRAgent è un framework sviluppato per affrontare questo problema con un approccio diverso rispetto ai sistemi che recuperano blocchi di memoria in modo statico prima di iniziare il ragionamento. Invece di eseguire un singolo recupero iniziale e usare il materiale restituito come contesto fisso, il framework ricostruisce la memoria in modo progressivo durante l’esecuzione del compito. L’agente parte da segnali ridotti presenti nella richiesta, raccoglie elementi di prova, aggiorna la propria direzione di ricerca e recupera nuove informazioni solo quando risultano necessarie.
Il modello organizzativo alla base del sistema viene definito Cue-Tag-Content. Le informazioni archiviate non sono trattate soltanto come testi da ricercare tramite embedding, ma vengono strutturate come un grafo associativo a più livelli. I cue rappresentano segnali granulari utili per avviare la ricerca, i tag sintetizzano relazioni e concetti ricorrenti, mentre i contenuti conservano il materiale informativo più dettagliato. Questa organizzazione consente all’agente di espandere il contesto gradualmente, passando da indizi iniziali a elementi sempre più specifici.
Il vantaggio principale è la riduzione del materiale inviato al modello durante una query. Nei test sul benchmark LongMemEval, MRAgent ha utilizzato circa 118.000 token per campione, contro circa 632.000 token richiesti da A-MEM e 3,26 milioni di token attribuiti a LangMem. La differenza non è soltanto numerica: in un agente utilizzato molte volte al giorno, ogni recupero di memoria troppo ampio può moltiplicare i costi di API, aumentare i tempi di risposta e rendere più difficile controllare il comportamento del sistema.
L’efficienza emerge anche sul tempo di esecuzione. Nel confronto con A-MEM, MRAgent ha ridotto il runtime da circa 1.122 secondi a 586 secondi. Questo risultato deriva dalla minore quantità di contesto processato e dalla capacità di evitare recuperi estesi quando la richiesta richiede soltanto una parte circoscritta della cronologia. Un agente non deve quindi rileggere l’intera memoria disponibile per ricostruire una singola decisione, ma può seguire collegamenti tra eventi, istruzioni e risultati pertinenti.
L’architettura è pensata soprattutto per gli scenari nei quali l’agente deve mantenere continuità tra molte interazioni. Rientrano in questo ambito gli assistenti aziendali che lavorano su pratiche complesse, gli agenti di supporto tecnico, gli strumenti che analizzano progetti software, i sistemi di ricerca documentale e le applicazioni capaci di svolgere attività in più passaggi. In questi casi la memoria non può limitarsi a conservare trascrizioni complete: deve selezionare, collegare e recuperare informazioni senza sovraccaricare il modello.
La costruzione iniziale del database di memoria richiede una fase di distillazione delle cronologie grezze. Il framework utilizza modelli linguistici per estrarre metadati, segnali, relazioni e contenuti da conservare nella struttura associativa. Questa operazione aggiunge un costo di ingestione, ma può rendere più sostenibile l’uso del sistema nel tempo, specialmente quando le stesse basi informative vengono interrogate in modo ripetuto.
La gestione della memoria sta diventando uno degli elementi centrali nell’evoluzione degli agenti AI. Aumentare la dimensione del contesto non risolve automaticamente il problema, perché un contesto molto esteso può contenere dati ridondanti, contraddittori o non utili per la richiesta corrente. Framework come MRAgent puntano invece a trasformare la memoria in un processo attivo, nel quale il sistema cerca le informazioni necessarie passo dopo passo e limita il consumo di token alle evidenze realmente rilevanti.