If you searched for an agent memory survey, here is the whole field on one screen, then the detail underneath.
Agent memory in 2026 has two organizing questions. How long does a memory live? — short-term/working memory sits in the context window and dies with the session; long-term memory is persisted outside it and retrieved on demand. And, for long-term memory, what kind of thing is it? — the field has converged on three types borrowed from cognitive science: episodic (what happened), semantic (durable facts and preferences), and procedural (learned how-to). That taxonomy is stable now, and every product below is a different bet on how to store and retrieve those three.
The systems themselves fall into two camps plus an outlier. Vector-first stores — Mem0, Redis, MongoDB, Google's Vertex Memory Bank — are simpler and cheaper to write, and they shine at what did the user tell me. Graph and temporal-graph stores — Zep's Graphiti, Cognee — cost more to write but can answer what was true, and when, which pure similarity search cannot. And Letta is neither a library nor a database: it's an agent runtime where the agent edits its own tiered memory. Pick by the question you're answering, not by the leaderboard — because, as we'll get to, the leaderboards can't be trusted.
The taxonomy, in one pass#
The split most people start with is short-term vs long-term. Short-term memory is just context: the running conversation, a scratchpad, the last few tool results. It's bounded by your context window and it evaporates when the session ends. Long-term memory is anything you persist and fetch back later — and it's where all the product categories live. Our types of agent memory piece walks the full hierarchy; the three-tiers wiring guide shows how to actually plumb short, persistent, and long-term stores together.
Within long-term memory, the three content types are the vocabulary you'll see everywhere in 2026:
- Episodic — timestamped records of specific interactions: conversation turns, tool calls, observations. "On Tuesday the user asked for a refund."
- Semantic — generalized facts lifted out of any single event: "the user prefers email over SMS," "our return window is 30 days."
- Procedural — reusable how-to: skills, tool-use patterns, decision rules the agent has learned to apply.
Underneath the taxonomy sits the thing that actually determines cost and quality: the write phase versus the read phase. Reading (retrieve, rerank, inject into context) adds latency and tokens on every turn. Writing (extract candidate facts, dedupe them, resolve contradictions, update a graph or re-embed) is where the real expense and the real intelligence live — and systems differ enormously in where they choose to pay it. We put numbers on this in the token cost of memory, read vs write.
And retrieval, when it's done well, is almost never pure similarity. The dominant pattern blends recency (an exponential time-decay factor), importance (a stored salience score), and relevance (embedding similarity, often mixed with keyword and entity matching). Get the weighting wrong and the agent surfaces the loudest memory instead of the right one; our recency vs relevance vs importance breakdown is the one to read before you tune it.
The write phase is the whole game#
If writing memory were just appending, none of this would need products. It isn't, because new facts contradict old ones. The user was vegetarian in March and ordered ribs in June; preferred one vendor, now prefers another. An append-only log becomes a pile of mutually contradictory statements, and vector search — which returns whatever is most similar, not most current — will cheerfully hand back the stale one.
So production memory does real work on write: an extraction step pulls candidate facts from the latest exchange, and a consolidation step compares each against what's stored and decides to add, update, delete, or do nothing. That decision is the entire difference between memory and a RAG index that quietly rots — the full argument is in agent memory vs RAG, and the deterministic-vs-LLM tradeoff for making the call is in conflict resolution.
There's a second failure that's stranger and worse: because the agent authors its own store, it can poison itself. A wrong conclusion the agent reaches can be written back as a fact and retrieved later as ground truth, and every downstream turn inherits it while looking perfectly coherent. A RAG corpus can't do that to itself. If you take one security concern from this survey, make it agent memory poisoning — and consider whether your users need the right to make the agent forget.
The seven systems, and what each is actually for#
Mem0 is the fastest path to "my agent remembers the user." It's a vector-first memory layer with multi-level scoping (user, session, agent), a single-pass LLM extraction step that keeps write cost low, and a managed cloud or self-hosted option; you can wire it in a few lines. It's the most-starred of the group by a wide margin at the time of writing, and it raised a $24M Series A to build exactly this. Reach for it for personalization and preference recall when speed-to-ship matters more than temporal precision. (repo)
Zep, and its open-source engine Graphiti, take the opposite bet: a temporal knowledge graph where entities are nodes and facts are edges, and every edge carries a validity window — when a fact became true and when it was superseded. A contradiction closes the old edge instead of deleting it, so history stays queryable. That architecture, described in the Zep paper, is what lets it answer "what was the user's plan as of April," which a vector store simply can't. Reach for it when facts change over time or you need an audit trail. (Graphiti repo)
Letta — the project formerly known as MemGPT — isn't a memory library you bolt on; it's an agent runtime built around memory. It borrows the operating-system metaphor: core memory (in-context, the agent reads and writes it directly), recall memory (searchable history), and archival memory (a long-term store queried by tool call). In 2026 it added idle-time consolidation so the agent can rewrite its own memory blocks while the user is away. Reach for it when you're building long-running, autonomous agents that must manage their own memory over long horizons. (repo)
LangMem is LangChain's SDK for the same job — managing semantic, episodic, and procedural memory — designed to slot into LangGraph's long-term store but usable on its own, and agnostic about the backend. If you're already building on LangChain, it's the low-friction choice. (announcement)
Cognee is the self-hosted option for teams that want both similarity and relationships and can't send data to a managed service. Its extract-cognify-load pipeline turns ingested data into a knowledge graph plus vector embeddings, and it can run entirely on Postgres. Reach for it under data-sovereignty constraints. (repo)
Redis and MongoDB aren't dedicated memory frameworks — they're the "you already run this datastore" answer. Redis's Agent Memory pairs TTL'd session memory with Redis-backed semantic search; MongoDB colocates Atlas Vector Search with your operational documents. Both let you avoid standing up a second system, which is worth more than it sounds. If you're picking the store underneath any of this, start with the best vector database for AI agents. (Redis Agent Memory)
Google's Vertex AI Memory Bank is the fully managed route for Google Cloud shops: Gemini asynchronously extracts facts from session history, consolidates them, and resolves contradictions per user, so live-turn latency stays low. It entered public preview in July 2025 and integrates with ADK, LangGraph, and CrewAI. Reach for it if you're all-in on Vertex and want memory as a managed dependency rather than infrastructure you operate.
A note on OpenAI: as of this writing, OpenAI's "memory" is a ChatGPT product feature, not a first-class developer memory API on the level of the systems above. Treat it as a consumer/enterprise capability, not a framework peer.
Why you can't trust the benchmarks#
Every one of these systems will show you a number on LoCoMo (long-term multi-session conversation recall) or LongMemEval (500 questions across extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention). Ignore the ranking.
The scores are not apples-to-apples. Each system uses its own ingestion pipeline, its own answer-generation prompt, its own LLM-judge configuration, and sometimes a different base model — then publishes into a table that looks shared but that no third party can reproduce end to end. This isn't a hypothetical: the two most-cited memory companies have publicly disputed each other's LoCoMo figures, and once the methodology was reconciled the numbers moved by roughly 25 points — larger than the gaps the leaderboards claim to measure. One vendor's later self-reported figures use a third methodology again.
The practical rule: read a benchmark to understand what a system optimizes for — temporal reasoning, contradiction handling, raw recall — never to rank two systems against each other. Then run the only evaluation that counts, which is your own workload on your own data.
How to choose, this afternoon#
The decision is cleaner than the landscape looks once you lead with the question you're answering:
- Personalization and preferences, ship fast → Mem0 (managed), or Redis/MongoDB if you already run that infra.
- Facts that change over time; temporal or audit reasoning; enterprise → Zep (managed) or Graphiti (self-hosted).
- Already deep in LangChain / LangGraph → LangMem.
- Long-running autonomous agents that self-manage memory → Letta.
- Self-hosted, graph + vector, data sovereignty required → Cognee.
- All-in on Google Cloud / ADK → Vertex AI Memory Bank.
Two closing rules that outlast any specific product. First, most serious agents need two stores, not one — a vector store for "who is this user" and something graph-shaped for "what changed when" — and the classic mistake is pointing one index at both jobs and discovering weeks later that your "memory" is a RAG index quietly accumulating contradictions. Second, watch where each system pays its write cost: background or async consolidation (Letta's idle-time compute, Vertex's async extraction, Mem0's single pass) keeps live-turn latency down, while graph systems trade higher ingestion cost for richer queries. Match that tradeoff to whether your product is latency-bound or accuracy-bound, and the rest of the choice falls out. If you want the head-to-head rather than the landscape, Mem0 vs Zep vs Letta is the next click; for the state-and-portability angle, see agent memory and state and the portable stateful-agent format.



