The problem
An agent handles a customer over three sessions across two weeks. Session one, the customer explains they’re on the enterprise plan and their main pain is API rate limits. Session two, a different day, they ask a follow-up, and the agent greets them like a stranger, re-asks which plan they’re on, and re-explains the rate-limit basics it already walked through. Session three, the customer mentions they downgraded last week, and the agent cheerfully keeps citing enterprise-tier limits, because nothing told it the earlier fact had expired.
Everything in this series so far retrieves from a corpus that sits still. Memory is the part of the knowledge layer that has to remember things that happened: facts that accrue from the interaction itself, change over time, and contradict what was true last week. That’s a different write path, and the knowledge layer (the part of an agent system that decides reliability in production, and an engineering discipline in its own right) gets a lot harder once it has to update, not just retrieve. The vendors building agent memory have each bet on a different abstraction for that write path, and the bet they made determines what your agent is good and bad at remembering.
How agent memory works
Strip away the branding and there are three abstractions underneath every memory product. Most real systems combine two of them, and in my view every product I’ve looked at is a bet on which of the three to lead with, not a fourth kind. (The cognitive-science taxonomies add procedural memory, the learned skills and routines. It’s real, and it’s starting to show up as a feature, LangMem’s prompt-updating memory and Mem0’s procedural memory type among them, but no product leads with it yet, so it stays out of this tour.)
Semantic memory is the vector approach: extract the durable facts from a conversation, embed them, and retrieve the relevant ones later by similarity. It’s RAG pointed at the interaction history instead of a document corpus. Episodic / working memory keeps a running, self-editing representation of what happened (a summarized history, a persona block, a scratchpad) that the agent rewrites as the conversation grows, so the context window holds the gist rather than the raw transcript. Temporal knowledge graph memory stores facts as typed nodes and edges, each stamped with when it became true and when it stopped. Of the three, it’s the one that handles the downgrade in the opening story by construction: superseding a fact is a first-class, dated operation that keeps the old value in the timeline, rather than an update pass that has to notice the collision and get it right.
In practice: the vendor tour
This is the most vendor-heavy article in the series, because the memory space is where the abstraction choice is most visible in the product. Four worth knowing, each leading with a different bet.
Mem0 leads with semantic memory plus lightweight extraction. It sits next to your agent’s model calls: after each exchange it pulls the salient facts out and stores them as embeddings, and before each answer it recalls the relevant ones by similarity. It’s the vector bet, productised, with a focus on keeping the recalled context small. Mem0’s own paper (Prateek Chhikara and co-authors, Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory, [arXiv 2504.19413](https://arxiv.org/abs/2504.19413), April 2025, later published at ECAI 2025) frames the win as token efficiency: store a compact set of extracted facts rather than stuffing whole histories into context, and it reports a 91% lower p95 latency and over 90% lower token cost than a full-context baseline on the LoCoMo benchmark. Even the vector bet is being pulled toward time: Mem0 rewrote its extraction and retrieval algorithm in April 2026 (single-pass extraction, multi-signal retrieval), then in May 2026 added temporal reasoning and memory decay on top of it, which tells you where the pressure in this space is. It’s the easiest of the four to drop in, and the right default when “remember what this user told me” is most of what you need.
Letta leads with episodic / self-editing memory, and it’s the direct descendant of the MemGPT paper (Charles Packer and co-authors, MemGPT: Towards LLMs as Operating Systems, [arXiv 2310.08560](https://arxiv.org/abs/2310.08560), October 2023). The core idea is borrowed from operating systems: treat the context window like RAM and an external store like disk, and let the agent itself decide what to page in and out, editing its own memory blocks (a persona, a running summary, key facts) as the conversation evolves. The bet is that an agent which manages its own context beats one handed a fixed retrieval, and it’s the strongest fit for long-running conversational agents that need a coherent sense of the whole relationship, not just a bag of recalled facts.
Zep leads with the temporal knowledge graph, built on its open-source engine Graphiti. Every fact extracted from the conversation becomes a typed edge in a graph with validity timestamps, so the system knows not just what is true but when it was true and what superseded it (Preston Rasmussen and co-authors, Zep: A Temporal Knowledge Graph Architecture for Agent Memory, [arXiv 2501.13956](https://arxiv.org/abs/2501.13956), January 2025). This is the abstraction that handles change correctly (the downgraded customer, the moved deadline, the role that changed), and it’s where the memory question and the GraphRAG question from Article 4 turn out to be the same question asked of a different corpus.
A-MEM is the research frontier rather than a product, and it’s the one I find most interesting. Wujiang Xu and co-authors (A-MEM: Agentic Memory for LLM Agents, [arXiv 2502.12110](https://arxiv.org/abs/2502.12110), February 2025, published at NeurIPS 2025) borrow the Zettelkasten note-taking method: each memory is an atomic note that the system links to related notes and re-indexes as new memories arrive, so the memory structure evolves instead of sitting in a flat store. It’s a bet that the organisation of memory should be dynamic: the same instinct behind the schema-evolution problem, which is one of the genuinely unsolved problems in the area, and what draws me to it.
The temporal-graph case is the easiest to motivate. Take a media-analytics agent tracking a developing story: the signature question is “how did this narrative evolve over six weeks, and who introduced each turn?” That’s hard to answer with semantic memory alone, because the answer isn’t a set of recalled facts, it’s a timeline of who-said-what-when with each claim stamped and linked. A temporal graph stores exactly that; a vector store flattens it into a pile of similar-looking sentences with no order. The abstraction you pick is the set of questions you can answer.
Where it shines
Two situations where memory earns a dedicated system rather than a longer prompt.
The first is long-running relationships: an assistant a user returns to across days or weeks, a sales agent tracking a deal, a support bot that should know the customer’s history. Here the value is continuity: not re-asking, not contradicting, building on what came before. The opening story is this case failing, and it’s the one buyers feel most directly because it reads as the agent being dumb even when the underlying model is excellent.
The second is questions about change over time: anything where when a fact was true matters as much as the fact. Compliance histories, evolving narratives, account states that supersede each other, “what did we know and when.” This is the temporal-graph sweet spot, and it’s common in finance, journalism, and any regulated domain where an out-of-date fact stated confidently is a real liability, not a cosmetic miss.
Where it breaks
Memory is harder than retrieval, and the failure modes are quieter.
Stale and contradictory memory. The single worst failure: the agent confidently recalls a fact that was superseded, like the enterprise-tier limits after a downgrade. Semantic memory is especially prone to this, because two contradictory facts (”on the enterprise plan”, “on the pro plan”) embed to nearly the same vector, and a plain vector store has no native notion of one replacing the other. The vendors know it: Mem0’s paper describes an LLM pass that decides whether each new fact adds, updates, or deletes an existing memory, but that pass is another extraction call that can get the call wrong. If your domain has facts that expire, an abstraction without a time dimension will quietly serve the dead one.
Extraction errors compound. Every memory system that extracts facts from conversation can extract the wrong fact (mis-attribute a preference, capture a hypothetical as a commitment), and once a wrong memory is written, it gets recalled and reinforced. Unlike a bad retrieval, which is transient, a bad memory persists and poisons future answers until something deletes it.
Unbounded growth and recall noise. Memory accumulates, and a store that never forgets eventually recalls ten marginally-relevant facts for every useful one, drowning the signal and inflating the context bill. Deciding what not to remember (and what to forget) is an unsolved design problem that most teams discover only after the store is already bloated.
No standard for evaluation. Until 2024 there wasn’t a widely shared yardstick for any of this. LoCoMo (Adyasha Maharana and co-authors, [arXiv 2402.17753](https://arxiv.org/abs/2402.17753), ACL 2024) was the first purpose-built one to get wide pickup, and LongMemEval (Di Wu and co-authors, [arXiv 2410.10813](https://arxiv.org/abs/2410.10813), October 2024, ICLR 2025) put the harder numbers on it: 500 questions testing information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention across long histories, on which commercial chat assistants and long-context models showed a 30% accuracy drop.
The measurement problem has since moved rather than gone away. MemDelta (Kuan Wang, [arXiv 2606.29914](https://arxiv.org/abs/2606.29914), June 2026, preprint) re-ran memory systems against RAG and full-context baselines on LongMemEval, changing one component at a time. Swapping only the embedding model shifted accuracy by about 6 points, enough to flip the winner, and on some question types a managed memory layer matched plain retrieval at roughly fifty times the cost. The recommendation that follows, fix the embedding model across comparisons and report write-path cost before crediting the architecture, is the right one. If you’re not measuring memory against something like these, you’re shipping on vibes.
When not to use it
If your agent is stateless by nature (every query is self-contained, no continuity across turns matters, the corpus answers everything), then a memory system is complexity you don’t need, and you should stay with the retrieval stack from the earlier articles. A single-shot Q&A bot over a documentation set has no use for episodic memory; bolting one on just adds a write path to maintain and a new way to be wrong. Memory earns its keep when the interaction carries information the corpus doesn’t: when “what did this user tell me last Tuesday” is a question your agent actually needs to answer.
Cost / latency / setup effort:
Combinations and hybrids
The clean split in practice: use a vector store for “what does the corpus say” (RAG, Articles 2–3), and a memory system for “what do I know about this user / this session / this developing situation.” Most production agents need both, and the good ones keep them separate: corpus knowledge and interaction memory have different lifecycles, different freshness needs, and different failure modes, and fusing them into one store muddies all three. Inside memory, the strong hybrids pair episodic working memory (for the coherent gist of the conversation) with a temporal graph (for the facts that must stay correct as they change). That is, not coincidentally, the same vector-plus-graph pattern Article 4 landed on for retrieval. And the agent deciding what to commit to memory is itself a retrieval-as-decision problem, straight out of the agentic-RAG article. The techniques in this series are less a menu of alternatives than a set of parts that keep recombining.
Production checklist
Give facts a time dimension if anything in your domain expires: valid-from / valid-to, or you will serve superseded facts with confidence.
Log every memory write with its source turn, so a wrong memory can be traced to the exchange that created it and deleted.
Set an eviction / forgetting policy up front (decide what ages out and how) rather than discovering the bloat after the store is huge and the recall is noisy.
Separate corpus retrieval from interaction memory; don’t let one store do both jobs.
Measure recall quality against a memory benchmark (LongMemEval- or LoCoMo-style), not just anecdotes: track multi-session and temporal questions specifically, and hold the embedding model fixed when you compare systems.
Alert on contradiction: when a new memory conflicts with a stored one, surface it rather than silently keeping both.
Cap and monitor memory-write cost; every extraction is a model call, and at scale the write path can cost more than the reads.
The take
Agent memory isn’t one technique: it’s three abstractions wearing vendor logos, and the one you pick decides which questions your agent can answer. Vector memory for “remember what they told me,” episodic memory for “keep a coherent sense of the whole relationship,” temporal graphs for “track what’s true and when it changed.” Most real agents need a blend, all of them need a forgetting policy and a time dimension, and none of them should be shipped without measuring recall against something harder than your own optimism. Pick the abstraction that matches the questions you actually get asked, and budget for the write path, because remembering is more expensive than retrieving.
I take on a small number of advisory engagements each year for teams hitting exactly these problems. Reach out if that’s you.
What to read next
This series:
Article 1 — Your agent’s problem isn’t the model, it’s the knowledge layer
Article 2 — Naive RAG: the baseline you’ll always benchmark against
Article 3 — Advanced RAG: what you actually run in production
Article 4 — GraphRAG and friends: when entities and relationships beat similarity
Article 5 — Agentic RAG: when retrieval becomes a decision, not a pipeline
Article 6 — Vector vs graph vs episodic: a tour of agent memory systems
Article 7 — Context engineering: the discipline that replaces prompt engineering (coming soon)
External:
Packer et al. (October 2023), MemGPT: Towards LLMs as Operating Systems. https://arxiv.org/abs/2310.08560. The OS-for-context idea behind Letta and self-editing memory.
Rasmussen et al. (January 2025), Zep: A Temporal Knowledge Graph Architecture for Agent Memory. https://arxiv.org/abs/2501.13956. Memory as a temporal graph; the open-source engine is Graphiti.
Xu et al. (February 2025), A-MEM: Agentic Memory for LLM Agents. https://arxiv.org/abs/2502.12110. Zettelkasten-style atomic memory that re-links as it grows.
Wu et al. (October 2024, ICLR 2025), LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. https://arxiv.org/abs/2410.10813. The benchmark to measure any of this against.
Wang (June 2026, preprint), MemDelta: Controlled Baselines and Hidden Confounds in Agent Memory Evaluation. https://arxiv.org/abs/2606.29914. Why memory-vs-RAG comparisons flip when you change one component, and why write-path cost belongs in the report.