Guida alla memoria per gli agenti: tra RAG, contesto e nuovi framework

Nel 2024 la conversazione sulla memoria dei modelli linguistici si giocava quasi tutta su un asse solo, RAG contro finestra di contesto lunga, come se dovesse vincere uno dei due. Nel 2026 quella domanda è diventata quasi ingenua. Chi progetta agenti oggi non sceglie una tecnologia, compone uno stack, mettendo insieme recupero di conoscenza esterna, contesto immediato, competenze interiorizzate nel modello, accesso a sistemi operativi in tempo reale e una qualche forma di continuità tra una sessione e l'altra. Il problema non è più "quale tecnica useremo", è "quale livello di memoria serve a quale pezzo del problema, e quanto costa sbagliare la scelta".

Questa guida prova a mappare le opzioni disponibili oggi, con i loro pro, i loro contro, i casi in cui brillano e quelli in cui sono un errore. Non è una classifica, è più simile a una cassetta degli attrezzi: alcuni strumenti sono cacciaviti, altri sono martelli, e usare il martello per avvitare produce solo frustrazione.

RAG classico: origini e crepe

Il retrieval augmented generation viene spesso raccontato come un'invenzione nativa dell'era dei modelli linguistici, ma è una semplificazione. Recupero e generazione, raffinamento delle query, verifica delle risposte erano già temi centrali della ricerca in information retrieval e question answering ben prima dei transformer, come racconta questa ricostruzione storica del RAG. I grandi modelli hanno aggiunto un'interfaccia linguistica fluida sopra un'architettura che l'informatica documentale conosceva da tempo, un po' come Toy Story ha aggiunto un volto simpatico a decenni di ricerca in computer grafica.

Il meccanismo di base resta semplice da descrivere: un corpus viene spezzato in frammenti, i frammenti diventano vettori in un embedding space, una query viene proiettata nello stesso spazio, i frammenti più simili vengono recuperati e iniettati nel prompt. Le varianti più avanzate aggiungono ricerca ibrida, reranking, scomposizione delle query, e soprattutto due tecniche diventate quasi uno standard de facto. La prima è il Self-RAG o il Corrective RAG, dove il modello valuta la pertinenza di ciò che ha recuperato prima di generare, invece di fidarsi ciecamente del punteggio di similarità. La seconda è la Contextual Retrieval introdotta da Anthropic, che genera una breve sintesi contestuale per ogni frammento prima di indicizzarlo, così un pezzo di testo isolato porta con sé l'informazione su quale documento appartiene e di cosa parla, riducendo sensibilmente i fallimenti di recupero quando combinata con reranking.

I limiti restano strutturali, però. Spezzare un documento a blocchi fissi rischia di separare una domanda dalla sua risposta o di spaccare un ragionamento a metà. La similarità vettoriale non è la stessa cosa della rilevanza per un compito specifico, due frasi possono essere semanticamente vicine e completamente inutili per la domanda posta. Il recupero dei primi risultati non garantisce ragionamento multi-hop, e la base di conoscenza è trattata come sostanzialmente statica, ogni aggiornamento richiede nuova indicizzazione. Soprattutto, il RAG classico non ha alcuna nozione di continuità tra sessioni diverse, recupera conoscenza sul mondo, non memoria dell'utente. Ha senso per documentazione tecnica, policy aziendali, basi di conoscenza di dimensioni medio grandi dove tracciare la fonte è importante. Non basta per domini fortemente relazionali o per agenti che devono ricordarsi chi hanno davanti.

Contesto lungo: il mito dei megatoken

I modelli con finestre di contesto enormi hanno cambiato in modo concreto cosa è possibile fare senza pipeline di recupero. A metà 2026 Claude Sonnet 5 offre un milione di token di contesto nativo, Gemini 3.1 Pro arriva fino a due milioni di token in produzione, e GPT-5.5 si attesta su un milione. Numeri che, fino a due anni fa, sembravano fantascienza da laboratorio.

Il vantaggio è la semplicità architetturale, non serve un vector store, non serve una pipeline di retrieval, si carica il testo e si interroga il modello. Per compiti che richiedono di vedere tutto insieme, come sintetizzare un documento lungo o ragionare su una base di codice contenuta, il contesto lungo può battere il RAG proprio perché non introduce la perdita informativa del chunking. Il rovescio della medaglia sono costo e latenza, elaborare un milione di token a ogni query costa ordini di grandezza più di un recupero mirato, e le inferenze su contesti enormi possono richiedere decine di secondi contro il tempo di risposta quasi immediato di un RAG ben progettato. C'è poi il fenomeno noto come "lost in the middle", per cui anche con un contesto sterminato l'attenzione del modello non è distribuita in modo uniforme e le informazioni sepolte nel mezzo rischiano di essere sottoutilizzate, un problema discusso a fondo in questa analisi sulle architetture di memoria per agenti. Infine, e questo è il punto che spesso sfugge, il contesto lungo è una proprietà a turno singolo, non dà continuità tra conversazioni diverse né gestisce lo stato di un utente nel tempo, come chiarisce bene questo confronto tra RAG e finestre ampie. Ha senso per corpus piccoli e ben delimitati, prototipazione rapida, ragionamento globale su un singolo documento. Diventa un anti pattern in applicazioni enterprise ad alto volume di query, dove il conto a fine mese può essere brutale.

Fine-tuning e pre-addestramento continuato: competenze, non fatti

Adattare direttamente il modello, tramite fine-tuning completo o continual pre-training, serve a internalizzare stile, formato, convenzioni di dominio, non a immagazzinare fatti che cambiano ogni settimana. Un modello addestrato su linguaggio giuridico impara come si scrive un parere, non impara il contenuto aggiornato di ogni norma. Il vantaggio è che, una volta addestrato, non serve alcun retrieval a runtime per quelle competenze specifiche, e su task ripetitivi con formato fisso, come estrarre entità secondo uno schema preciso, il fine-tuning batte spesso soluzioni basate su pochi esempi nel prompt, come illustrato in questa panoramica sulle alternative al RAG.

Il rovescio è netto, non è una base di conoscenza dinamica, richiede dataset curati, infrastruttura di addestramento, valutazione continua, e se il dominio evolve il modello va riaddestrato o rischia di diventare obsoleto in modo silenzioso. Ha senso per competenze stabili nel tempo, non ha senso quando il valore principale sta nella conoscenza fattuale che cambia di continuo.

Tool-use agentico: la memoria vive altrove

C'è un'intera categoria di problemi dove la risposta giusta non è "ricordare meglio" ma "non fidarsi della memoria e andare a controllare". Un agente che chiama un'API di ticketing, interroga un CRM o esegue una query su un database non sta leggendo un corpus statico, sta chiedendo la verità a chi la possiede in tempo reale, come descritto in questa guida sul recupero di contesto in produzione. Il vantaggio è ovvio, i dati sono sempre aggiornati, le policy di accesso si applicano a livello del sistema sorgente, e le allucinazioni su fatti dinamici si riducono perché il modello non sta indovinando ma leggendo.

Il costo è nella complessità di integrazione, servono schemi di input e output, gestione degli errori, limiti di frequenza, autenticazione, e la latenza dipende da sistemi che l'agente non controlla, per cui una catena di più chiamate può rallentare tutto in modo significativo. Nel 2026 buona parte di questa integrazione passa ormai attraverso il Model Context Protocol, uno standard che ha reso molto più semplice collegare agenti a strumenti esterni senza reinventare ogni volta l'interfaccia, e che è diventato anche il modo con cui i framework di memoria descritti più avanti si espongono agli agenti. Il tool-use ha senso per conoscenza critica in sistemi transazionali e per compiti che richiedono azioni, non solo risposte. È un errore quando il dominio è principalmente documentale e stabile, o quando le API esterne non offrono garanzie di affidabilità.

GraphRAG: la conoscenza come rete

Invece di recuperare solo frammenti di testo, si può costruire un grafo di entità, relazioni e attributi e fare retrieval su nodi e percorsi. La differenza pratica si vede su domande del tipo "quali progetti hanno usato un certo modello e hanno avuto incidenti di sicurezza", dove serve attraversare più salti relazionali che la similarità testuale da sola non può cogliere, un punto approfondito in questa guida alle tecniche RAG avanzate del 2026 e nel mio precedente articolo sulla costruzione di wiki autogenerate per gli LLM. Ricerche indipendenti presentate a eventi di settore hanno mostrato guadagni sostanziali in accuratezza fattuale quando si passa da un puro recupero vettoriale a un grafo interrogabile, come racconta questa analisi sulla memoria agentica oltre i vettori.

Il grafo rende esplicite relazioni che il testo lascia implicite, e permette query strutturate oltre alla similarità semantica. Costruirlo e mantenerlo, però, è lavoro intensivo, serve estrarre entità e relazioni, pulire, allineare ontologie, e la pipeline complessiva diventa più complessa da monitorare, con parti simboliche e neurali che devono coesistere, come nota anche questa guida ai database a grafo per agenti AI. Non tutto il dominio si presta a modellazione a grafo, spesso serve un ibrido tra grafo e testo puro. Funziona bene per organizzazioni aziendali, reti di prodotti e componenti, catene causali di incidenti. È uno spreco di risorse su corpus prevalentemente narrativi o poco strutturati.

Caching del contesto: velocità sui contenuti stabili

Quando lo stesso corpus viene riutilizzato in continuazione, ricostruire da zero il contesto a ogni chiamata è uno spreco evidente. Le principali piattaforme hanno risposto con soluzioni concrete, non solo teoriche. Il prompt caching di Anthropic permette di marcare blocchi stabili del prompt, come istruzioni di sistema o documenti di grandi dimensioni, e di riutilizzarli su richieste successive a una frazione del costo, con letture dalla cache tariffate anche a un decimo del prezzo dei token di input normali e riduzioni di latenza molto sensibili sui documenti lunghi. Google offre un meccanismo analogo con il context caching della sua API Gemini, pensato per non dover ripagare ogni volta l'elaborazione di codebase intere o trascrizioni di riunioni multi ora.

Il beneficio è concreto sui contesti riutilizzati intensamente, un assistente interno su manuali fissi o su una base di codice stabile ne trae vantaggio immediato in termini di latenza e costo. Il limite è altrettanto chiaro, questa tecnica aiuta poco su conoscenza che cambia spesso o su sessioni molto eterogenee tra loro, e introduce comunque una gestione non banale di invalidazione e coerenza della cache.

Tassonomia della memoria agentica

Qui si entra nel territorio più specifico degli agenti che devono comportarsi come se ricordassero qualcosa, non solo come se sapessero qualcosa. La memoria nel contesto immediato, gli ultimi scambi della conversazione corrente, è immediata e a costo infrastrutturale nullo, ma vale solo per la sessione in corso ed è molto in perdita se la finestra è piccola. La memoria episodica riassume sessioni passate, eventi salienti, decisioni prese, dando continuità tra una conversazione e l'altra a costo di una compressione che perde inevitabilmente dettagli. La memoria semantica somiglia al RAG ma pensata come memoria a lungo termine dell'agente, buona per fatti puntuali, debole sulle relazioni complesse se non affiancata da un grafo. La memoria procedurale, spesso realizzata tramite fine-tuning o configurazione esplicita dell'agente, cattura pattern di azione e competenze riutilizzabili, ma non è adatta a fatti che cambiano, un quadro ben tracciato in questa panoramica sulle architetture di memoria vettoriale, a grafo ed episodica e in questo confronto tra memoria personale e conoscenza recuperata.

I benefici generali di questo strato sono la continuità cross sessione e la personalizzazione, ma comportano rischi specifici, in particolare quello che si potrebbe chiamare memoria tossica, informazioni obsolete o sbagliate che restano incastrate e degradano silenziosamente il comportamento dell'agente nel tempo. Ha senso per agenti che interagiscono ripetutamente con gli stessi utenti, va tenuta minima o evitata in chatbot occasionali o in contesti con vincoli di privacy stringenti.

Il campo dei framework reali

La tassonomia teorica sopra prende forma concreta in una manciata di progetti che nel 2026 chiunque lavori su agenti conosce per nome. Letta, erede diretto del progetto MemGPT, ha reso popolare l'idea di un agente con una core memory di poche centinaia di token che il modello legge e scrive da sé tramite chiamate a strumenti, più una archival memory molto più ampia fuori dalla finestra di contesto, paginata dentro e fuori secondo necessità, come descritto in questo confronto tra i principali framework di memoria per agenti. Mem0 punta sulla semplicità di integrazione, un livello di memoria plug and play orientato a preferenze utente e sessioni, con retrieval basato su più segnali insieme.

Zep, costruito sopra il motore open source Graphiti, adotta un approccio diverso e piuttosto elegante, tratta ogni messaggio come fonte di fatti su entità e relazioni, e ogni fatto come un arco temporalmente delimitato nel grafo, con una finestra di validità che permette di invalidare un'informazione superata invece di sovrascriverla o lasciarla contaminare le risposte successive. Il Technology Radar di Thoughtworks ha promosso Graphiti alla fase di adozione sperimentale ad aprile 2026, citando benchmark che parlano di miglioramenti di accuratezza intorno al 18,5 per cento e riduzioni di latenza vicine al 90 per cento rispetto a un GraphRAG tradizionale, come si legge in questa scheda del radar tecnologico. Cognee segue una logica più vicina al grafo puro, con una pipeline di ricordo, recupero, dimenticanza e miglioramento pensata per documenti, entità e basi di codice.

Accanto a questi ci sono progetti più di nicchia ma tecnicamente rilevanti. EverMind, con il suo EverMemOS, propone un'architettura a doppio strato tra memoria di lavoro e memoria a lungo termine sotto forma di grafo di conoscenza dinamico, e ha pubblicato una ricerca, di cui ho parlato in un articolo di maggio 2026, su un meccanismo chiamato memoria ad attenzione sparsa, pensato per gestire in modo efficiente contesti fino a cento milioni di token. Graphify, invece, si concentra sulla memoria per assistenti di programmazione, trasforma codice, documenti, commit e persino schermate del browser in un grafo unico navigabile, aggiornando solo i nodi effettivamente cambiati invece di rifare l'indicizzazione da capo, ne ho parlato in questo articolo di giugno 2026.

Chi deve orientarsi tra questi nomi farebbe bene a partire dal problema, non dalla popolarità del progetto. Se serve un runtime dove la memoria è il cuore stesso dell'agente, Letta è il punto di riferimento naturale. Se il problema è personalizzazione rapida con integrazione minima, Mem0 resta la scelta pragmatica. Se contano fatti che cambiano nel tempo e la loro validità storica, Zep con Graphiti è probabilmente la risposta più matura oggi disponibile. Se il dominio è intrinsecamente un grafo, documenti, entità, basi di codice, Cognee o Graphify meritano una valutazione seria.

Stack ibridi: la sintesi che funziona

Nessuna di queste tecniche, presa da sola, copre l'intero spettro dei bisogni di un agente serio. La comunità tecnica nel 2026 converge su questa idea in modo abbastanza compatto, il contesto lungo va trattato come complemento del RAG e della memoria, non come loro sostituto, secondo quanto emerge da questa analisi sulle architetture ibride per agenti AI e da questo confronto tra memoria a lungo termine e modelli a contesto lungo. Alcuni test comparativi tra architetture diverse, RAG puro, contesto lungo, file di memoria e approcci ibridi, hanno mostrato che la combinazione ottiene un tasso di richiamo molto alto a un costo sensibilmente più basso rispetto al contesto lungo usato da solo, un dato citato in questa guida pratica alle architetture di memoria, anche se conviene sempre verificare le condizioni specifiche di ogni benchmark prima di trasportarle acriticamente sul proprio caso d'uso.

Un pattern ragionevole per dimensionare lo stack parte dalla grandezza del corpus. Su cinquanta o cinquecento pagine, RAG per filtrare i passaggi rilevanti più contesto lungo per elaborarli insieme funziona bene. Oltre le cinquecento pagine, o su corpus in crescita continua, il RAG, eventualmente potenziato a grafo, diventa quasi obbligatorio, e il contesto lungo va riservato ai soli risultati del recupero. In un agente enterprise tipico convivono RAG su documentazione e policy, tool-use su sistemi operativi, memoria episodica e semantica per gli utenti, un grafo per le relazioni complesse tra prodotti, servizi e incidenti, come descritto anche in questa guida sull'ingegneria del contesto. Un copilota tecnico potrebbe combinare RAG sulla documentazione, un grafo per le dipendenze tra componenti, caching sulle sezioni stabili. Un tutor didattico potrebbe unire memoria episodica per lo studente, RAG sul materiale del corso, fine-tuning leggero sullo stile pedagogico.

Tabella comparativa

Linee guida pratiche per chi progetta agenti

Prima di scegliere un'architettura conviene rispondere a poche domande semplici ma spesso trascurate. Quanto è grande il corpus. Con quale frequenza cambia la conoscenza. Serve continuità tra utenti che tornano, o ogni conversazione può ripartire da zero. Quali sono i vincoli reali di costo, latenza e privacy. Servono ragionamenti che attraversano più entità collegate tra loro, o bastano risposte puntuali.

Da queste risposte discende quasi meccanicamente una prima bozza di stack, corpus piccolo e stabile suggerisce contesto lungo o un RAG leggero, corpus medio o grande richiede RAG, eventualmente arricchito a grafo, con il contesto lungo riservato ai risultati del recupero, utenti ricorrenti impongono uno strato di memoria episodica o semantica, dati operativi in tempo reale chiedono tool-use su sistemi esterni, relazioni complesse giustificano l'investimento in un grafo. Nessuna di queste scelte è definitiva, ed è proprio questo il punto più difficile da accettare per chi viene da un mondo di soluzioni uniche e definitive, la memoria di un agente serio si costruisce a strati, si rivede, e va trattata come un pezzo di infrastruttura da manutenere quanto il codice che la circonda, non come una funzione che una volta implementata si può dimenticare.