Come funziona davvero la memoria degli agenti
Fai la stessa domanda a un chatbot due volte in due sessioni e ti risponderà come uno sconosciuto entrambe le volte. Non è un bug — è il comportamento predefinito. Un modello linguistico grezzo non ha memoria tra una chiamata e l'altra. Tutto ciò che "ricorda" all'interno di una conversazione vive nella finestra di contesto, e quando quella conversazione finisce, scompare.
La memoria è il meccanismo che aggiungi per risolvere questo problema: i sistemi che decidono cosa un agente dovrebbe portare avanti, dove archiviarlo e come recuperare il pezzo giusto al momento giusto. Nel 2026 questo ha smesso di essere una missione secondaria ed è diventato una parte di prim'ordine del design degli agenti, con i propri benchmark, framework e una vera letteratura di ricerca. Questa pagina è la mappa.
- Capire perché una finestra di contesto non è memoria — e dove si trova davvero il confine
- Distinguere i quattro tipi di memoria che usano gli agenti: di lavoro, episodica, semantica, procedurale
- Confrontare i quattro pattern di archiviazione: full-context, vector/RAG, knowledge-graph e compaction/summarization
- Vedere come Claude, ChatGPT e Gemini implementano oggi ciascuno la memoria
- Scegliere un approccio alla memoria per il tuo agente senza sovra-ingegnerizzarlo
L'unica idea da tenere a mente: contesto ≠ memoria
La confusione più comune è trattare una grande finestra di contesto come "memoria". Non lo è. La finestra di contesto è spazio di lavoro per un singolo turno — viene riempita da zero a ogni chiamata, è finita ed è costosa. Anche l'attenzione degrada al suo interno (l'effetto "lost in the middle" trattato in Context Engineering).
La memoria è diversa in tre modi:
| Finestra di contesto | Memoria | |
|---|---|---|
| Durata | Una singola richiesta | Tra sessioni, giorni, per sempre |
| Dimensione | Tetto fisso di token | Praticamente illimitata (archivio esterno) |
| Costo | Pagato a ogni singolo turno | Pagato una volta per scrivere; economico da referenziare |
| Accesso | Tutto, sempre in vista | Selettivo — recupera solo ciò che è rilevante |
L'intero gioco della memoria degli agenti consiste nello spostare l'informazione giusta tra questi due: scrivere fatti duraturi fuori dalla finestra così da non pagarli a ogni turno, e riportarli dentro solo quando questo passo specifico ne ha bisogno. Se questo flusso è corretto, un agente può operare per settimane su una finestra di contesto che contiene sempre solo qualche migliaio di token rilevanti.
I quattro tipi di memoria
Prendendo in prestito (liberamente) dalle scienze cognitive, l'ecosistema degli agenti del 2026 è converso su quattro categorie. Raramente ti servono tutte e quattro — ma nominarle ti impedisce di costruire un unico blob che fa tutto male.
- Ciò che è nella finestra di contesto in questo momento — il compito corrente, gli ultimi turni, i risultati degli strumenti di questo passo. Volatile per design. È il blocco degli appunti, non l'archivio. Gestirla bene è context engineering; non è persistenza.
- Cose specifiche che sono accadute, con un timestamp. 'Martedì l'utente ha detto che il checkout era rotto; mercoledì il supporto l'ha segnato come risolto.' La memoria episodica è intrinsecamente temporale — l'ordine e il quando contano. È ciò che permette a un agente di ragionare su una storia anziché su un'istantanea.
- Fatti e preferenze duraturi, spogliati di quando li hai appresi. 'L'utente preferisce le unità metriche.' 'Questo cliente è sul piano enterprise.' La memoria semantica è in gran parte atemporale — rappresenta ciò che l'agente crede sia attualmente vero, non l'evento in cui l'ha scoperto.
- Come fare qualcosa — competenze, workflow e routine apprese riutilizzabili. La meno matura delle quattro nella pratica. In strumenti come Claude Code questa vive spesso come file di istruzioni (CLAUDE.md) e competenze riutilizzabili piuttosto che come archivio automatico.
Un test utile: se risponderesti con "quando è successo?" è episodica; se risponderesti con "cos'è vero?" è semantica; se risponderesti con "ecco come" è procedurale; e se conta solo per i prossimi secondi, è memoria di lavoro e non ha bisogno di essere persistita affatto.
I quattro pattern di archiviazione
Una volta che sai cosa ricordare, scegli come archiviarlo e recuperarlo. Ci sono quattro pattern dominanti, all'incirca in ordine di complessità. La maggior parte dei sistemi reali ne combina due o tre.
1. Full-context (mettici dentro tutto)
Mantieni l'intera storia e reinviala a ogni turno. Zero infrastruttura, richiamo perfetto — finché non raggiungi il tetto dei token, la curva dei costi o il "lost in the middle". Va bene per assistenti brevi; un vicolo cieco per qualsiasi cosa di lunga durata. Questa è la baseline che ogni altro pattern migliora.
2. Memoria vector / RAG
Scrivi ogni memoria come embedding in un database vettoriale; al momento della query, fai l'embedding del turno corrente e recuperi le top-k memorie più simili. Questa è la retrieval-augmented generation puntata sulla storia della conversazione invece che sui documenti. Economica, scalabile e il default per il richiamo semantico di fatti e preferenze.
Il suo punto debole: similarità ≠ rilevanza per le domande temporali o multi-hop. "Cosa abbiamo deciso dopo che il budget è stato tagliato?" è una domanda di ordinamento, e la cosine similarity non ha alcun senso del tempo né del concatenare due fatti insieme.
3. Memoria knowledge-graph
Archivia le memorie come entità e relazioni — nodi e archi, spesso con timestamp sugli archi. Per rispondere a una domanda attraversi il grafo invece di fare fuzzy-matching sui vettori. È questo che rende trattabile il ragionamento multi-hop e temporale ("chi ha sostituito la persona che gestiva l'account di cui l'utente si è lamentato?"). Framework come Zep/Graphiti hanno costruito tutta la loro proposta attorno ai knowledge graph temporali. Il costo è ingegneria reale: estrazione, entity resolution e mantenere il grafo dal marcire.
4. Compaction & summarization
Comprimi periodicamente la storia corrente in un riassunto distillato e continua da quello — scambiando il richiamo alla lettera per una finestra più piccola ed economica. È ciò che fa /compact in Claude Code, e ciò che fa l'"auto-summary" in molti prodotti di chat. È la forma più economica di memoria a lungo termine e spesso la prima di cui hai davvero bisogno. Il suo rischio: il riassunto scarta silenziosamente proprio il dettaglio che ti serviva. Vedi Long-Running Agent Harnesses per come questo si manifesta su esecuzioni di ore.
I sistemi reali stratificano questi pattern. Uno stack comune del 2026: compaction per la conversazione corrente, vector per i fatti semantici, e un graph in cima solo quando le query temporali/multi-hop si presentano davvero nel tuo traffico. Non costruire il grafo finché non senti il dolore che il grafo risolve.
Come lo fanno i tre grandi
Ogni assistente principale ora offre una qualche memoria. Non sono la stessa cosa, e le differenze contano.
| Prodotto | Cosa ricorda | Come funziona (all'incirca) |
|---|---|---|
| Claude | Due livelli: una memoria a livello di app delle tue preferenze, e un memory tool rivolto agli sviluppatori per gli agenti. | La memoria dell'app Claude archivia fatti tra le chat; il memory tool più context editing dell'API permette a un agente di scrivere note in un archivio lato client e di eliminare automaticamente i risultati degli strumenti obsoleti per sopravvivere a esecuzioni lunghe. |
| ChatGPT | "Saved memories" (fatti espliciti) più riferimento alle tue chat passate. | Un mix di fatti dichiarati dall'utente e preferenze estratte automaticamente, iniettati nel contesto di sistema nei turni successivi. Modificabile e attivabile/disattivabile dall'utente. |
| Gemini | Contesto personale tratto dalle tue chat e, opzionalmente, dalla più ampia superficie dell'account Google. | Richiama dettagli da conversazioni precedenti e può personalizzare usando il contesto dell'account, soggetto ai tuoi controlli sulla privacy. |
Due lezioni. Primo, la memoria consumer è per lo più semantica — preferenze e fatti — non un replay episodico completo. Secondo, se stai costruendo un agente, la memoria integrata del prodotto non è il tuo sistema di memoria; sei tu il proprietario di quel livello, usando primitive come il memory tool di Claude o un framework esterno.
Trasforma un modello grezzo in un agente che prende appunti (la memoria reale più economica)
You have a file called MEMORY.md that persists between our sessions. At the END of each session, append any durable facts worth keeping: - my stable preferences (tools, formats, style) - decisions we made and WHY - open threads to resume next time At the START of each session, read MEMORY.md first and use it. Keep it under 30 lines — when it grows past that, consolidate and delete anything stale. Never store secrets or credentials.
Quel singolo pattern — scrivere note durature su un file esterno, rileggerle la volta successiva — è l'80/20 della memoria degli agenti. La maggior parte del macchinario dei framework qui sotto è una versione più automatica e più scalabile esattamente di questo.
Misurare la memoria: il benchmark LoCoMo
Non puoi migliorare ciò che non puoi misurare, e la memoria era difficile da misurare finché non sono arrivati i benchmark. Il più citato è LoCoMo ("Evaluating Very Long-Term Conversational Memory of LLM Agents"): conversazioni multi-sessione molto lunghe — centinaia di turni attraverso decine di sessioni — con coppie domanda-risposta in cinque gusti: single-hop, multi-hop (cross-session), ragionamento temporale, open-domain e adversarial.
Ciò che LoCoMo rivela è il pattern attorno a cui progettare: i sistemi se la cavano bene sul richiamo fattuale single-hop e crollano sulle domande temporali e multi-hop. Quel modo di fallire è esattamente il motivo per cui esiste la memoria knowledge-graph — è il pattern che solleva di più quelle due categorie. Quando valuti la memoria del tuo agente, dai molto peso ai casi multi-hop e temporali; il richiamo single-hop lusinga quasi tutto.
Scegliere un approccio senza sovra-costruire
- Non fare nulla. La memoria di lavoro (la finestra di contesto) è sufficiente. Aggiungere un archivio di memoria qui è puro overhead.
- Inizia prendendo appunti su un file esterno, o con la memoria integrata del prodotto. Questo copre la maggior parte delle esigenze 'ricorda le mie preferenze' a costo quasi nullo.
- Aggiungi compaction/summarization. Mantieni i fatti portanti, scarta la cronaca dettagliata. È qui che vivono gli agenti di lunga durata.
- Aggiungi memoria vector/RAG. Recupera le top-k memorie rilevanti per turno invece di reinviare tutto.
- Solo ora ricorri a un knowledge graph — o a un framework gestito (Mem0, Letta, Zep, LangMem) che te ne dà uno senza dover fare a mano estrazione ed entity resolution.
La trappola è iniziare dal passo cinque. La graph memory è impressionante nelle demo e costosa in produzione. Sali la scala; fermati al primo gradino che risolve il tuo problema reale.
Check yourself
0/4In conclusione
La memoria non è una singola funzionalità che accendi — è un flusso che progetti: cosa lascia la finestra, dove viene archiviato e come torna indietro. Nomina i quattro tipi di memoria così da non costruire un unico blob per tutti. Inizia dal pattern di archiviazione più economico che risolve il tuo problema e sali solo quando senti il dolore del successivo. E misura con casi temporali e multi-hop, perché il richiamo single-hop fa sembrare tutto più intelligente di quanto sia.
La memoria è l'altra metà del Context Engineering: il context engineering decide cosa riempie la finestra in questo turno; la memoria decide cosa sopravvive tra i turni. Insieme sono ciò che separa un chatbot da un agente che migliora quanto più a lungo ci lavori.
Fonti e approfondimenti
- Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo) — il benchmark canonico; pagina del progetto.
- Effective context engineering for AI agents — Anthropic su compaction, note-taking e retrieval just-in-time.
- Claude memory tool & context editing docs — la primitiva rivolta agli sviluppatori.
- Agent Memory Techniques — 30 notebook eseguibili che coprono conversation buffer, vector store, knowledge graph, memoria episodica/semantica, Mem0, Letta, Zep, Graphiti e LoCoMo.
- The State of AI Agent Memory 2026 — report di un vendor su architetture di memoria e benchmark (da leggere con la solita cautela sui numeri auto-riportati).
- Correlati su AILmanac: Context Engineering · Long-Running Agent Harnesses · RAG · Claude app memory · Memory & Context Editing (API).