Memoria negli agenti AI: stato dell'arte 2026

Apri una scheda del browser, cerchi "AI agent memory framework". Mem0 ti promette il "memory layer for AI" in tre righe di codice. Letta ti vende l'agente come sistema operativo con tiered memory. Zep ha un knowledge graph temporale che batte MemGPT sul DMR benchmark. Cognee ha appena chiuso un seed da 7,5 milioni. LangMem è "componibile". E poi c'è Pinecone, Weaviate, Chroma, Qdrant — i vector DB che fino a due anni fa erano la risposta. Cinquanta opzioni, tutte serie, tutte con paper e numeri.

Sotto a quella schiuma di marketing, però, succede una cosa che quasi nessuno racconta in questi termini: i tre attori più seri del 2025-2026 — Anthropic, lo standard AGENTS.md donato alla Linux Foundation, e Andrej Karpathy con il suo LLM Wiki di aprile — sono convergono indipendentemente sulla stessa risposta noiosa. File markdown su filesystem. Niente vector DB. Niente embedding. Niente knowledge graph. File di testo letti e scritti dall'agente con i tool che già aveva.

Della teoria della memoria — working, episodica, semantica, procedurale, perché il context window si rompe nel mezzo, il context rot — ne ho parlato qui. Questo pezzo non la rifà. Fa il punto pratico su cosa sta funzionando adesso, in produzione, per chi sviluppa agenti.

Tre stack, tre domini

Prima della carrellata, una mappa. Nel 2026 i sistemi di memoria che hanno trovato un loro pubblico sono divisi in tre famiglie nette, e fanno cose diverse. Non sono alternative tra loro su lo stesso problema: hanno vinto domini diversi.

Il primo è memoria file-based markdown, che ha vinto il coding agentico. Il secondo è la memoria conversazionale dei provider (ChatGPT, Claude, Gemini), che gestisce il caso assistente personale. Il terzo è la memoria framework-based (Letta, Mem0, Zep, Cognee, LangMem), che si è ritagliata lo spazio degli agenti production-grade con entità persistenti — CRM, customer support, project management.

Confonderli è il modo più rapido per spendere male. L'errore tipico — "mi serve memoria, prendo un vector DB" — copre il dominio sbagliato per il 90% dei casi reali in cui chi mi legge la cerca davvero.

Stack 1 — File markdown nel repo

Il pattern è semplice al limite del banale. Metti un file AGENTS.md o CLAUDE.md alla root del progetto, dentro ci scrivi convenzioni, comandi, vincoli, contesto. L'agente lo legge a ogni sessione. Aggiungi nested per sottocartelle. Versioni il file con Git. Fine.

AGENTS.md è nato ad agosto 2025 come formato aperto, donato il 9 dicembre 2025 alla Agentic AI Foundation sotto la Linux Foundation insieme a MCP (Anthropic) e Goose (Block). Oggi è supportato da OpenAI Codex, GitHub Copilot, Cursor, Google Jules/Gemini, Factory, Amp, Windsurf, Zed, RooCode, Augment. Più di 60.000 repository pubblici su GitHub lo usano. È diventato — silenziosamente — il primo standard cross-vendor dell'ecosistema agentico.

Claude Code ha la sua variante con quattro tier gerarchici (enterprise > project > project rules > user) e un meccanismo di import. La best practice ufficiale Anthropic è tenerlo sotto le 200 righe, perché ogni token finisce comunque nel context. Cursor ha i .cursor/rules/*.mdc con frontmatter YAML per scope e glob. Aider ha la convenzione CONVENTIONS.md. Stesso pattern, dialetti diversi.

Il colpo grosso è arrivato a settembre 2025 con il memory tool di Anthropic. Anthropic ha rilasciato un tool nativo per memoria persistente lato API, e ha fatto una scelta che vale la pena leggere lentamente: niente embedding, niente vector DB, niente knowledge graph. Sei operazioni sul filesystem (view, create, str_replace, insert, delete, rename) su una directory /memories. Stop. Il modello vede una struttura di file, naviga, legge, scrive. È letteralmente un filesystem virtuale.

E poi c'è Karpathy. Aprile 2026, gist pubblico: "LLM Wiki". Tre layer markdown organizzati come un wiki personale che l'agente consulta. La frase che ha fatto rumore è: "this replaces RAG". Detto da uno che ha lavorato a OpenAI e Tesla, non da un blogger.

Tre attori indipendenti — uno standard cross-vendor, un vendor di frontiera, una figura tecnica autorevole — convergono sulla stessa scelta architetturale nel giro di pochi mesi. Non se lo dicono apertamente, ma il messaggio è chiaro: per la memoria di lavoro di un agente che opera su codice e knowledge dell'utente, il filesystem markdown batte le soluzioni più sofisticate.

Perché funziona è quasi banale: leggibile dall'umano, debuggabile con un editor, versionabile con Git, controllabile riga per riga, portatile, zero infrastruttura. E l'agente sa già operarci — sa fare read_file, grep, bash. Niente nuovo SDK, niente nuova API. È memoria che vive nel posto dove l'agente già lavora.

Stack 2 — Memoria conversazionale dei provider

Qui il dominio è diverso: l'assistente personale che parla con te ogni giorno e dovrebbe ricordarsi chi sei.

ChatGPT ha un sistema aggressivo. Memorie salvate esplicitamente, riferimenti automatici alla cronologia, un dossier inferito che cresce in silenzio. Simon Willison l'ha definito "comprehensive but opaque": vedi una lista di memorie, ma il modello inietta autonomamente molto di più nel system prompt — preferenze inferite, biografia, topic ricorrenti.

Claude ha la filosofia opposta. Default: blank slate, ogni conversazione riparte da zero. La memoria si attiva solo via tool call esplicita, visibile nel trace. Projects per separare contesti. Il memory tool dell'API è file-based, ispezionabile. "Transparent but minimal", sempre Willison. Per chi sviluppa agenti aggiungo: c'è anche la feature Dreams — un processo background schedulato che riorganizza il memory store, riduce duplicati e contraddizioni. È la prima implementazione mainstream di "consolidation as a feature".

Gemini integra memoria via Google account history e Notebooks. Adoption più bassa lato dev rispetto agli altri due.

Non li confronto su chi è "meglio" — sono filosofie diverse non comparabili 1:1. Il punto pratico per chi sviluppa è un altro: se la tua app si appoggia a un provider per la memoria conversazionale, stai prendendo in casa la sua filosofia. Se costruisci sopra ChatGPT, l'utente avrà un'esperienza "il sistema sa molto di me, non so esattamente cosa". Se costruisci sopra Claude, l'utente dovrà gestire esplicitamente la memoria. Niente di drammatico — ma non è una scelta neutra, è una scelta di prodotto.

Stack 3 — Framework dedicati

Quando il dominio diventa "agente long-running che gestisce centinaia di entità persistenti", filesystem markdown e memory tool nativi non bastano più. Qui vivono i framework specializzati, e c'è del lavoro serio dentro.

Letta è il successore di MemGPT (paper UC Berkeley, "Towards LLMs as Operating Systems", 2023). Architettura tiered esplicita: Core (in-context, RAM-like), Recall (cronologia searchable), Archival (vector store via tool call). Oggi è una piattaforma per stateful agents, non solo libreria.

Mem0 ha chiuso una Series A da 24 milioni di dollari a ottobre 2025 (Basis Set Ventures lead, Peak XV, GitHub Fund, YC). 41k stelle GitHub, 14 milioni di download, da 35M API call in Q1 a 186M in Q3 del 2025. AWS l'ha scelto come exclusive memory provider per l'Agent SDK. Il pitch è "memory layer in tre righe", add/search/forget. È pulito.

Zep ha un approccio diverso: knowledge graph temporale (motore Graphiti, paper arXiv 2501.13956). Ogni fatto è un nodo con una validity window — "Kendra ama Adidas a partire da marzo 2026" — e il grafo gestisce contraddizioni e aggiornamenti nel tempo. Sul benchmark DMR raggiunge il 94,8% contro il 93,4% di MemGPT, e su LongMemEval documenta latenze ridotte del 90%. Integration AWS Neptune da settembre 2025. Sweet spot: agenti dove "chi possiede cosa, da quando" è il dominio centrale (CRM, project management, customer support con storia lunga).

Cognee — 7,5M seed — fa una pipeline ECL (Extract, Cognify, Load) che combina knowledge graph ed embedding, espone tutto via MCP. LangMem è componenti, non prodotto: SDK per costruirsi memory manager e prompt optimizer dentro LangGraph.

Quando ha senso adottare uno di questi? Quando hai un agente che lavora per molti utenti, molto a lungo, con entità identificabili e timeline. Customer support che deve ricordare anni di storia con migliaia di clienti. CRM agentico. Sistemi che hanno bisogno di gestire contraddizioni temporali e fatti che evolvono. Lì il knowledge graph di Zep o il tiered memory di Letta pagano i costi.

Quando non ha senso? Per il 90% dei casi pratici di chi sviluppa con un agente — coding tool, automazione personale, knowledge base interno, agente verticale su un dominio. Lì stai pagando complessità infrastrutturale che il filesystem markdown ti darebbe gratis.

Il vincitore silenzioso

Mettiamo insieme i pezzi. Anthropic, settembre 2025, rilascia un memory tool e sceglie esplicitamente di non usare vector DB. AGENTS.md, agosto 2025, diventa standard cross-vendor con 60.000+ repo. Karpathy, aprile 2026, pubblica un wiki markdown e dice "replaces RAG". Tre eventi indipendenti, tre attori non coordinati, stessa direzione.

Nessun titolo di blog l'ha messa in questi termini, ma il take è semplice: il vincitore silenzioso del 2026 è il filesystem markdown.

Non è un vincitore assoluto — i framework dedicati hanno il loro dominio, i provider hanno il loro, i vector DB hanno componenti reali in cui sono insostituibili. È vincitore nel senso che, per il caso d'uso di gran lunga più comune (memoria di un agente che lavora con un singolo utente o un singolo team su codice e contenuto), il pattern boring ha battuto le soluzioni fancy. E l'ha fatto perché ha quattro proprietà che nessuna altra soluzione mette insieme: leggibile, controllabile, versionabile, debuggabile con strumenti che esistono da quarant'anni.

C'è un parallelo che ho già fatto in un altro pezzo sul blog, quello sul 27B che batte il 397B: la fine della favola "più grande è meglio". Qui è la stessa famiglia di idee applicata alla memoria: la fine della favola "più sofisticato è meglio". La sofisticazione paga quando il dominio la richiede. Per il resto è overhead.

Vector DB: componente, non soluzione

Visto che i vector DB sono ancora il riflesso quando si sente la parola "memoria", vale la pena dirlo chiaramente. Sono ottimi strumenti — di retrieval. Sono pessimi sistemi — di memoria.

La differenza non è sottile. Un vector DB risponde alla domanda "quali documenti sono semanticamente simili a questa query". Una memoria deve rispondere a domande del tipo: "cosa ha deciso l'utente ieri?", "questo fatto contraddice un fatto precedente?", "questa informazione è ancora valida?", "quando è stata acquisita?", "questa azione è già stata fatta?". Il vector DB non sa rispondere a nessuna di queste — non per cattiva implementazione, ma per design.

La critica documentata (articoli VentureBeat, Medium, Dev.to del 2025-2026) gira intorno a cinque punti: storage non è understanding; similarità coseno non è rilevanza ("smoothie" e "peanut allergy" sono distanti, ma se l'utente è allergico la query "smoothie" deve attivare il vincolo); multi-hop reasoning fallisce su kNN; nessuna gestione delle contraddizioni; nessun forgetting. Tutto vero, tutto noto.

Il mercato si è aggiustato. Pinecone, Weaviate, Chroma, Qdrant non si vendono più come "agent memory" — si vendono come componenti di stack RAG e memoria. Crescono ancora come business proprio perché si sono componentizzati. Stessa direzione: il pure-play "vector DB = memoria" è morto. Il vector DB come pezzo di un sistema più grande è vivissimo.

E qui si chiude il cerchio con RAG vs long context: con context window da 1M token, RAG non scompare ma cambia ruolo. Da "soluzione di memoria" diventa "tecnica di retrieval su corpus grandi e statici". Che è quello che è sempre stato bravo a fare.

Cosa funziona, cosa è aperto, cosa è hype

Sintesi pratica per chi sviluppa oggi.

Funziona (provato, in produzione, scalato). File-based per coding agent: AGENTS.md / CLAUDE.md / .cursor/rules, maturo, debuggabile. RAG-light per knowledge base statiche: vector DB + chunking + reranker, niente lo batte come rapporto costo/qualità su Q&A documentale. Provider memory per consumer use: ChatGPT memory funziona "abbastanza" per uso personale, Claude Projects per separare contesti. Tiered memory in agenti verticali: Letta/Zep/Mem0 in CRM, customer support, PM con entità identificabili e timeline.

Aperto (problemi reali, soluzioni immature). Long-term episodic robusta: come ricordare quella conversazione di sei mesi fa senza esplodere i token. Multi-agent shared memory con conflict resolution: chi scrive vince? merge? CRDT-style? Il pattern è ancora immaturo — l'ho toccato di sbieco anche parlando di subagent, perché è esattamente lì che la memoria condivisa diventa il vero collo di bottiglia. Forgetting curves intelligenti: TTL fisso è brutale, salience-based è euristica. Memoria che si auto-debugga: Dreams (Anthropic) e Memify (Cognee) sono primi tentativi seri ma con failure mode noti.

Hype (cose che leggi e che non reggono al primo incontro con la produzione). "Vector DB = agent memory", narrativa 2023-2024 — superata, anche dai vendor stessi. "Agentic memory come passo verso AGI", marketing che a volte sfora — la memoria persistente è utile, non è coscienza. "Knowledge graph risolve tutto" — Zep e Cognee sono ottimi nel loro dominio, ma costruire e mantenere un KG è lavoro vero, non magia. "Memoria che impara da sola" — i sistemi di consolidation sono rule-based con LLM-as-judge, hanno bug e drift documentati.

Per chi sviluppa, oggi

Se stai costruendo un agente — non importa se è un coding tool interno, un assistente verticale, un workflow automation — la regola che spende meglio i tuoi token e il tuo tempo è questa: parti dal filesystem markdown.

Un AGENTS.md o CLAUDE.md alla root del progetto, scritto bene, breve, versionato. Connesso al pattern del grounding.md per le istruzioni che devono sempre vincere. Se il dominio cresce, aggiungi nested. Se ti serve cercare in molti documenti, aggiungi un retrieval RAG-light come componente — non come "memoria". Se stai costruendo un agente con migliaia di entità persistenti e timeline, allora valuta Letta o Zep, ma fallo con cognizione — non perché "tutti hanno il framework di memoria".

Quello che gli attori più seri stanno effettivamente facendo nel 2026 non è fancy. Tre file di testo, una directory /memories, un file alla root del repo. Sembra poco. Funziona meglio del 90% delle alternative perché è leggibile da chi lavora, controllabile riga per riga, e l'agente sa già operarci.

La memoria buona è quella che potresti scrivere a mano se avessi voglia. Tutto il resto è un componente — utile nei suoi casi, costoso fuori.

Fonti: