Episodic memory for AI agents

A reference page. Version 1.0 · 3 November 2026 · Maintained at episodicmemory.ai

#1. What the term means

Episodic memory is memory for events: what happened, where, when, and to whom. Endel Tulving introduced the distinction in 1972 between episodic memory, which stores specific episodes tagged with their context, and semantic memory, which stores facts stripped of the occasion on which you learned them. Knowing that Lisbon is in Portugal is semantic. Remembering the afternoon you found that out is episodic.

The distinction matters to software because the two are stored, indexed and retrieved differently. A fact can be overwritten when it changes. An event cannot: the record of what the system saw at 14:02 on a Tuesday stays true as a record even after the world moves on.

#2. Why agents fail without it

An agent without episodic memory restarts the world every session. Three failures follow, and they are the ones that show up in production.

• Repeated questions. The user has already stated the constraint; the agent asks again because the state did not survive the context window.
• No account of itself. When asked why it took an action last week, the agent can only reconstruct a plausible story, not read a record.
• Silent contradiction. A preference established on Monday is violated on Thursday, and nothing in the system notices the conflict.

Retrieval-augmented generation does not fix this. RAG reads a corpus that someone else wrote; episodic memory writes a record of what this agent did and saw, then reads it back later. The write path is the part that RAG does not have.

#3. Four stores, not one

Agent memory is usually described as one thing. It is at least four, and conflating them is the most common design error.

Episodic memory is the store that feeds the other three: consolidation turns episodes into semantic facts, and repeated successful episodes become procedural shortcuts. Skip the episodic layer and the other three have nothing to consolidate from.

#4. What an episodic store has to do

Seven requirements, in the order they tend to bite.

1. Timestamp and order. Every record carries when it happened, in a monotonic order, separate from when it was written. Backfilled and late-arriving records must not reorder history.
2. Context binding. An event without its participants, place and preceding state is not episodic, it is a log line.
3. Write cheaply, read selectively. The write path must not block the turn. Retrieval must be able to answer "what happened around this time" as well as "what is similar to this".
4. Consolidation. Periodic jobs summarise episodes into facts, and mark which episodes produced which facts. Without this the store grows without becoming more useful.
5. Decay and forgetting. Access counts and recency set retention. A store that never forgets becomes slower and less accurate, and eventually unaffordable.
6. Provenance. Every consolidated fact points back to the episodes it came from. This is what makes an answer auditable and a wrong belief correctable.
7. Deletion that means deletion. Erasure must reach the raw episodes, the derived facts, the embeddings and the backups. Consolidated memory that cannot be un-consolidated is a compliance problem, not a feature.

#5. Patterns that work

The event log is the source of truth. Vector indexes, graphs and summaries are derived views that can be rebuilt. Systems that treat the vector store as primary cannot answer temporal questions and cannot delete cleanly.

Two retrieval paths, not one. Similarity search answers "what is like this". Temporal queries answer "what happened between these points". Episodic memory needs both; most implementations only build the first.

Consolidation on a schedule, not on every write. Summarising during the turn adds latency and produces worse summaries, because the episode has not finished.

Salience before storage. Not every observation deserves an episode. Scoring at write time — novelty, user emphasis, task relevance, error — is cheaper than pruning later.

Explicit conflict handling. When a new episode contradicts a stored fact, the fact is superseded with a pointer to the contradicting episode, not overwritten silently.

#6. How to evaluate it

Two benchmarks carry most of the weight, and they test different things.

• LoCoMo (Maharana et al., 2024 — arXiv 2402.17753) evaluates very long-term conversational memory: questions asked many sessions after the events, including temporal and multi-hop reasoning over the history.
• LongMemEval (Wu et al., 2024 — arXiv 2410.10813) isolates five abilities: information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention when the answer is not in memory.

Three traps when reading results:

• Context stuffing is not memory. Passing the entire history into a long-context model can beat a memory system on a benchmark while costing more and failing beyond the context limit. Compare at matched token budgets.
• Benchmark contamination. Public question sets leak into training data. Report on held-out sets or private variants.
• Accuracy without latency. A memory layer that adds two seconds per turn will be disabled in production regardless of its score.

#7. Implementations worth reading

• Letta (formerly MemGPT) — arXiv 2310.08560. Treats the context window as main memory and pages older material to external storage, with the model deciding what to move.
• Mem0 — arXiv 2504.19413. An extraction-and-update pipeline that maintains a compact memory set rather than a growing log.
• Zep / Graphiti — temporal knowledge graph approach: entities and edges carry validity intervals, which makes "what was true then" answerable.
• Generative Agents — arXiv 2304.03442. The reference design for a memory stream with importance scoring, reflection and retrieval by recency, importance and relevance.
• A-MEM — arXiv 2502.12110. Agentic organisation of memory notes with links between them, closer to a Zettelkasten than a vector index.
• Framework modules — LangGraph, LlamaIndex and similar expose checkpointer and memory abstractions that are a reasonable starting point, provided you keep the event log separate from the index.

#8. Open problems

Forgetting that is principled rather than incidental. Retention policies are mostly ad hoc: a TTL, a token cap, or nothing. There is no accepted model for what an agent should forget.

Cross-agent memory. Two agents working on one task produce two histories with different perspectives on the same event. Merging them is unsolved in practice.

Memory as an attack surface. Anything an agent writes into long-term memory can be read back later, which makes poisoning persistent. A record must be treated as untrusted input at read time, exactly as a retrieved document is.

Evaluation beyond conversation. LoCoMo and LongMemEval are chat-shaped. Memory for tool-using, long-running agents — where the "event" is an action and its side effect — has no standard benchmark.

#9. Further reading

• Tulving, E. (1972). Episodic and semantic memory. In Organization of Memory.
• Park, J. S. et al. (2023). Generative Agents: Interactive Simulacra of Human Behavior. arXiv 2304.03442.
• Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv 2310.08560.
• Maharana, A. et al. (2024). Evaluating Very Long-Term Conversational Memory of LLM Agents. arXiv 2402.17753.
• Wu, D. et al. (2024). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. arXiv 2410.10813.
• Xu, W. et al. (2025). A-MEM: Agentic Memory for LLM Agents. arXiv 2502.12110.
• Chhikara, P. et al. (2025). Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv 2504.19413.