You have decided your agent needs memory. The pillar guide covers why. This one answers the next question: which framework should provide it.

That question got harder in 2026, not easier. Two years ago, "agent memory" usually meant putting conversation history in a vector database and hoping the model kept track. Today it is a real category, with dedicated platforms, agent runtimes, and managed cloud services, each built on a different idea of what memory is. The choice matters more than it looks, because the architecture you pick decides what your agent can recall well and what it will quietly get wrong.

This guide compares the frameworks that come up most often. It organizes them by architecture and by the kind of question you need memory to answer, and it treats published benchmarks with more suspicion than most comparisons do. That skepticism is the right starting point, so it goes first.

The benchmark numbers do not agree

Before any recommendation, one thing has to be said plainly: the accuracy figures these frameworks publish are unreliable, and they contradict each other across sources.

Mem0 reports 92.5% on the LoCoMo benchmark on its own site. An independent reimplementation on the same benchmark measured Mem0 at 29.3%, more than sixty points lower.

Neither number is a lie. They come from different runs. Three variables move a memory score: the model used to generate answers, the separate model used to judge whether an answer is correct, and the retrieval stack wrapped around the memory layer. Change any of them and the number moves. Secondary sites then repeat a third and fourth set of figures that trace back to no original paper at all.

The practical consequence is simple. This guide labels every vendor accuracy claim as vendor-reported, and it does not rank frameworks by score. It ranks them by fit. Where a number appears, treat it as a signal of what a team optimized for, not proof of what you will get.

The Architectures Behind Every Framework

The frameworks differ less in features than in their underlying model of memory. There are five approaches in common use, and the category predicts fit better than any brand name.

An extract-and-retrieve system pulls discrete facts out of a conversation, stores them, and retrieves them later by similarity. It is fast to integrate and strong at personalization, and it is weak at reasoning about when something was true.

A temporal knowledge graph stores entities, the relationships between them, and the time windows during which each fact held. It handles change and contradiction well, at the cost of more overhead on every read and write.

A tiered, agent-managed system, modeled on an operating system, lets the agent move information between an in-context working set and external storage, deciding for itself what to keep. It suits long-horizon autonomy and carries the risk that the agent corrupts its own memory.

A managed cloud primitive hands the whole problem to a provider who runs the infrastructure behind an API. You gain operational relief and give up some control and portability.

A raw storage backend is the substrate the others are built on: a vector or key-value store you assemble into a memory system yourself.

The Frameworks

Mem0

Mem0 is the framework most teams try first. It works as a drop-in memory API: you send it conversations, it extracts the facts worth keeping, and it returns them by similarity when they become relevant. It maintains separate scopes for the user, the session, and the agent, so one deployment can serve many users without mixing their histories.

The core is Apache 2.0, and adoption is the widest in the category, at roughly 48,000 GitHub stars. Its research paper (arXiv:2504.19413, presented at ECAI 2025) reports a 26% relative improvement over OpenAI's built-in memory on the LOCOMO benchmark, with 91% lower p95 latency than passing full context.

The watch-out is commercial: graph-based memory, where Mem0's relational reasoning lives, sits behind a paid tier, and teams have reported a steep jump between plans as usage grows. Best fit: personalization and fast integration.

Zep

Zep takes a different route. Rather than storing flat facts, it builds a temporal knowledge graph through its open-source engine, Graphiti. Every fact carries a validity window, so the system can answer not only what is true now but what was true at a given moment, and it can resolve contradictions when a user's situation changes. Its paper (arXiv:2501.13956) reports 94.8% on the Deep Memory Retrieval benchmark against MemGPT's 93.4%, and higher accuracy at lower latency on the tougher LongMemEval.

Zep markets the enterprise controls regulated buyers ask for, including SOC 2 and HIPAA support and bring-your-own-key deployment. The cost is operational: a graph carries more read and write overhead than a vector store, and self-hosting means running a graph database. Best fit: temporal reasoning and regulated domains where facts expire, which describes much of the work in HealthTech and FinTech.

Letta

Letta, formerly MemGPT, is the most architecturally distinct option here. It is an agent runtime, not a library you attach to an existing agent. Memory is a first-class part of the system, organized in tiers modeled on an operating system: a small core held in context at all times, recent history kept nearby, and an unbounded archival store the agent queries on demand. The agent edits its own memory and decides what to promote or evict.

That autonomy is both the appeal and the risk, since a reasoning error can corrupt what gets stored. Adopting Letta also means adopting its runtime. Best fit: long-running, autonomous agents that manage their own context over time.

LangMem

LangMem is LangChain's own memory layer, built for teams already working in LangGraph. It replaces the legacy memory modules LangChain has deprecated, adding long-term memory that persists across sessions. There is little to evaluate in isolation. If your agent already runs on LangChain, LangMem is the path of least resistance; if it does not, LangMem is rarely the reason to switch. Best fit: existing LangChain and LangGraph teams.

Cognee

Cognee builds a knowledge graph from source material rather than from live conversation. Point it at documents, past tickets, or runbooks and it turns them into a structured, queryable graph. It is open source, integrates over MCP, and runs locally, which suits privacy-sensitive deployments.

Graph construction costs more time and compute than embedding text, and the quality of the result depends on the model doing the extraction. Best fit: turning an existing corpus into memory an agent can use.

AWS Bedrock AgentCore Memory

AgentCore Memory is the managed option for teams standardizing on AWS. It is a fully managed service that handles both short-term session context and long-term retention with no infrastructure to run, and it works across frameworks, including LangGraph, CrewAI, and Strands, rather than locking you into one.

You trade some control and portability for the operational relief. Best fit: AWS-native teams that would rather not run memory infrastructure themselves.

Storage Backends and Adjacent Tools

A few tools sit next to this list without belonging on it. Pinecone, Weaviate, and Redis are storage backends, not memory systems; you supply the extraction and retrieval logic around them. Supermemory targets coding agents. Microsoft's Semantic Kernel and Kernel Memory suit Azure-native shops. LlamaIndex Memory fits document-heavy retrieval agents. Most production systems end up pairing a dedicated memory platform with one of these backends underneath.

The Benchmarks and How to Read Them

Three benchmarks dominate the discussion. LoCoMo, from Snap researchers, tests recall across long multi-session conversations. LongMemEval adds knowledge updates and questions the system should decline to answer, which maps more closely to enterprise use.

BEAM, introduced at ICLR 2026, stretches context to as much as 10 million tokens. All three measure the write-and-retrieve loop across sessions, a different problem from long-context attention over a single input.

The problem, as the opening section showed, is that the same system posts different numbers depending on how it was run. A published figure tells you what a team optimized for and roughly where its architecture lands. It does not tell you how the framework will perform on your traffic.

The only evaluation that settles the question is the one you run yourself. Take the two or three frameworks on your shortlist, load a representative slice of your real conversations, and measure retrieval accuracy, latency, and cost on the questions your users actually ask. That takes a few days and replaces an argument about leaderboards with evidence about your workload.

How to Choose: Match the Tool to the Question

The cleanest way to narrow the field is to state the question you need memory to answer.

Once the shortlist is down to two or three, score them on what will matter in production: retrieval accuracy on your data, latency against your response budget, temporal reasoning if your facts change, self-hosting if you have residency requirements, compliance controls, observability into what the agent stored and retrieved, and how cleanly the layer fits the stack you already run.

How We Choose a Memory Layer at Codebridge

Our approach follows the same order as this guide. We start from the access pattern and the compliance envelope rather than a leaderboard. We keep the raw event stream in infrastructure the client owns, so the framework stays replaceable. And we validate the shortlist on the client's own data before committing, because a score earned on someone else's conversations says little about yours.

Across our HealthTech and FinTech work, the constraint that usually decides the design is not accuracy on a public benchmark. It is data residency, auditability, and how the system behaves when a stored fact goes stale. Those are the questions we design around first, because they are the ones that surface in production long after the demo has impressed everyone.

Where the category is heading

The architectural lines are already blurring. Mem0 has added graph features, Zep has vector search, Letta has external stores, and the managed services are absorbing capabilities from all of them. By 2027, most frameworks will support the main storage patterns, and the differences will narrow to accuracy, latency, and how little operational weight a system carries. That convergence is one more reason to design for portability now instead of betting on a single vendor's current advantage.

Conclusion

Choosing a memory framework comes down to three habits. Start from the access pattern, not the leaderboard. Read every published benchmark as a signal rather than a verdict, and run your own on your own data. And keep the raw event stream portable, so today's choice does not become tomorrow's migration. Get those right and the specific framework matters less than the discipline behind the decision.

If you are weighing a memory layer for an agent, or want a shortlist validated against your own data and compliance requirements, our team can help you scope it.