On this page
Put Coworker to work on your stack.
Connect Salesforce, Slack, Jira and run your first agent in minutes.
Comparisons
Mem0 vs Zep vs Letta: AI Agent Memory Frameworks Compared
Coworker AI compares Mem0, Zep, and Letta on architecture, memory model, and fit, plus where a developer framework stops being the right answer.
Mem0, Zep, and Letta are the three open-source projects that define AI agent memory for developers. They solve the same headline problem, giving an agent recall beyond its context window, and they solve it in genuinely different ways.
This comparison is about which architecture fits which job, and about the boundary where a developer framework stops being the right tool at all.
At a glance
| Mem0 | Zep | Letta | |
|---|---|---|---|
| Core architecture | Hybrid: vector store plus knowledge graph | Temporal knowledge graph (Graphiti) | Agent-managed context paging |
| Origin | Open-source memory layer for LLM apps | Graphiti graph, arXiv paper 2501.13956 | MemGPT paper, arXiv 2310.08560 |
| Strongest at | Per-user facts, preferences, history | Facts that change over time, relations | Long-running autonomous agents |
| Handles contradiction by | Updating extracted facts | Fact succession with validity periods | Agent rewriting its own memory blocks |
| Open source | Yes, plus managed cloud | Graphiti open, Zep managed | Yes, plus managed cloud |
| Scope | Per application or per user | Per application, enterprise-oriented | Per agent |
Mem0: extraction-first memory
Mem0 sits between your application and the model, watching conversation and extracting the parts worth keeping. Rather than storing raw transcripts, it distils them into discrete memories and retrieves the relevant ones on later turns.
Architecturally it runs a dual store: a vector database for semantic similarity, and a knowledge graph for entities and relationships. That combination is deliberate, because similarity search alone cannot answer questions about relations, and a graph alone is a poor fit for open-ended recall.
Where it fits. Consumer and prosumer products where the value is that the assistant remembers you: preferences, past requests, ongoing projects. The extraction-first design means you get useful memory without designing a schema.
Honest limitations. Automatic extraction is lossy by nature, and what it decides to keep is not always what you would have chosen. Its centre of gravity is the individual user rather than an organization, which is a design choice rather than a flaw, but it matters if you were hoping for shared team memory.
Zep: memory that knows when things were true
Zep is built on Graphiti, its open-source temporal knowledge graph, and the temporal part is the whole argument.
In a conventional store, when a fact changes you have a problem. The account owner was Dana, now it is Sam. Store both and the agent sees a contradiction. Overwrite and you have destroyed the ability to answer anything historical.
A temporal graph records that the first fact was valid until a date and the second is valid from it. Queries about now resolve correctly, queries about last quarter also resolve correctly, and nothing has to be deleted.
The Zep paper on arXiv reports outperforming MemGPT on the Deep Memory Retrieval benchmark, and Zep's own materials report figures on LongMemEval alongside substantial latency reductions. Those latter numbers are vendor-published, so treat them as a claim to verify on your own workload rather than a settled result. The architecture argument stands on its own regardless.
Where it fits. Domains where facts have a lifecycle: customer state, org structure, project ownership, anything an enterprise tracks. It is also the most governance-oriented of the three.
Honest limitations. A temporal graph is more machinery than many applications need. If your agent's memory is "the user prefers metric units," the succession model is overhead. Extraction quality still gates everything, as it does for any graph system.
Letta: the agent manages its own memory
Letta, formerly MemGPT, comes from a different premise. The MemGPT paper framed the limited context window as an operating-systems problem: give the agent tools to page information in and out of its own context, and let it decide what to hold.
So in Letta the agent edits its own memory blocks. It decides what is important enough to keep resident, what to archive, and when to go fetch something back. Memory is an agent behaviour rather than an external service the application calls.
Where it fits. Long-running autonomous agents that operate over extended horizons and need to manage their own state. It is the most conceptually elegant of the three and the most agent-native.
Honest limitations. Handing memory management to the model means memory quality inherits model judgement, which is variable. It is also the most per-agent of the three, and the hardest to reason about when you want a shared picture across many agents.
How to choose
| If you need... | Look at |
|---|---|
| An assistant that remembers individual users | Mem0 |
| Facts with a lifecycle, and audit of what changed when | Zep |
| An autonomous agent managing its own long-horizon state | Letta |
| Structured questions: counting, enumeration, multi-hop | Zep, or a graph approach generally |
| The simplest path from zero to working memory | Mem0 |
| Shared memory across an entire company | None of these, see below |
A practical note on evaluation: benchmark numbers in this category are mostly published by the vendors whose systems they favour, and the benchmarks themselves are young. The comparison that will actually decide your choice is running two of them against a week of your own traffic and reading what each one chose to remember. Extraction quality is the variable that dominates, and it is workload-specific.
Coworker
Put an AI agent to work on your stack
Connect Slack, Salesforce, and Jira and run your first agent in minutes.
Try the no-code AI agent builderWhat are the best Mem0 alternatives?
Beyond Zep and Letta, the four Mem0 alternatives worth testing are Supermemory, Cognee, Hindsight and LangMem. All four are open source and, like Mem0, are memory layers you build into your own applications and agents.
| Tool | What it stores | Where it runs | License | Best fit |
|---|---|---|---|---|
| Mem0 | Facts distilled from conversations, scoped to users, agents, apps and runs | Managed platform or self-hosted | Apache-2.0 | Per-user memory with the least setup |
| Supermemory | Memories, documents and user profiles in one store | Managed API or one self-hosted binary | MIT | Memory plus retrieval over files and synced apps |
| Cognee | A knowledge graph plus vectors, shaped by custom ontologies | Locally, in Cognee Cloud or in your own cloud | Apache-2.0 | Graph memory that several agents share |
| Hindsight | Memory banks of facts, experiences and observations | Self-hosted on Postgres, or Hindsight Cloud | MIT | Agents that should learn from past runs |
| LangMem | Memories and prompt updates on LangGraph's store or another | Inside your own agent code | MIT | Teams already building on LangGraph |
| Coworker | Organizational memory built from 50+ connected work tools | Coworker's apps or any MCP client | Commercial | Shared memory of the company for people and agents |
Supermemory
Supermemory puts memory, document retrieval and user profiles behind one API. It extracts facts from conversations, keeps a profile of each user's stable facts and recent activity, and handles updates, contradictions and expired information. It can also sync Google Drive, Gmail, Notion, OneDrive and GitHub. The engine is MIT-licensed and runs as a managed service or as a single self-hosted binary. In September 2026 Supermemory shut down its company-brain app to focus on the memory engine, so treat it as infrastructure for agents you build.
Mem0 vs Supermemory
The difference is scope. Mem0 concentrates on memory distilled from conversations, with scopes for users, agents, apps and runs. Supermemory bundles that memory with retrieval over documents and synced sources, so one store serves both personalization and grounding. Mem0's own comparison page recommends Supermemory when your app depends on ingesting documents, web pages or third-party sources.
On benchmarks, each vendor shows itself ahead on LongMemEval. Mem0's page lists Mem0 at 94.4 and Supermemory at 85.2. Supermemory's own comparison reports 95% with GPT-4o and 85.2% with Gemini 3 Pro, so the two pages are citing different configurations. Test both on your own data before trusting either chart.
Cognee
Cognee (Apache-2.0) turns documents, code and conversations into a knowledge graph that agents can search, with remember, recall, improve and forget operations and support for custom data models and ontologies. It is the closest of these to company memory: it connects Slack, GitHub and Linear and pitches one shared memory for many agents rather than one per user. It is still a developer platform: your engineers connect it to their agents, whether it runs locally, in Cognee Cloud or in your own cloud.
Hindsight
Hindsight, from Vectorize, stores memories in banks and exposes three operations: retain, recall and reflect. In the background it consolidates related facts into observations that keep their supporting evidence, so an agent learns from experience instead of only recalling chat history. It is MIT-licensed and self-hosts on Postgres, with a hosted option. Its README says its LongMemEval results were independently reproduced by researchers at Virginia Tech and The Washington Post.
LangMem
LangMem is LangChain's MIT-licensed memory library. It gives an agent tools to save and search memories during a conversation, runs a background manager that extracts and consolidates memories afterward, and can refine the agent's prompt from past interactions. It works with any storage system and integrates natively with LangGraph's long-term memory store, which makes it the natural pick if your agents already run on LangGraph.
Where Coworker fits
Mem0, Supermemory, Hindsight and LangMem are memory engines for an app or agent you build: you decide what goes in and which user or project each store belongs to. Cognee reaches further into company knowledge, but you still build the agents and decide what it ingests. Coworker starts from the company side. Its organizational memory is built continuously from 50+ connected tools such as Slack, Salesforce, Jira and Google Drive, recalls only what the person asking can see in the source tool, and is shared by every person and agent, in Coworker's apps or through MCP in clients like Claude, ChatGPT and Cursor. If you are building a product, pick a framework from this list. For company-wide memory, read the next section first.
---
Where a developer framework stops being the answer
All three are libraries you wire into an application. You decide what gets written, you own the store, and the memory belongs to that application.
That is the correct shape for building a product. It is the wrong shape for an enterprise, for a reason that is structural rather than a matter of features.
Per-agent memory does not compose. A company running twenty agents each with its own memory has twenty partial pictures that never reconcile. The support agent knows what support learned. The sales agent knows what sales learned. Nothing connects the churn signal in a support thread to the renewal that sales is forecasting, because no layer holds both.
Organizational memory is a different thing:
- Sourced from systems, not just chat. Meetings, tickets, documents, and messages, not only what a user typed at one agent.
- Shared across people and agents, so there is one picture rather than many.
- Permission-aware by inheritance, so access rules from the source systems travel with each fact. Without this, a memory layer becomes a route around access control.
- Continuously maintained, pruning and retiring facts rather than accumulating contradictions.
Coworker AI works at that layer. It connects to 50+ tools, maintains organizational memory across them, and runs agents that act on what they find rather than only retrieving it. It also exposes that memory over MCP, so the context is available inside the AI tools your team already uses.
These are not mutually exclusive. If you are building a product, use a framework. If you are trying to make your company's AI understand your company, that is a different layer.
Book a demo to see the difference in practice.
If you plan to use these through Claude or Cursor rather than an SDK, see the best MCP memory servers, including Mem0's hosted MCP and Zep's Context MCP Server.
Frequently asked questions
What is the main difference between Mem0 and Zep?
Mem0 is extraction-first, distilling conversation into facts held in a hybrid vector and graph store, and it is oriented around remembering individual users. Zep is built on a temporal knowledge graph, so facts carry validity periods and can supersede one another, which suits domains where information changes and history matters.
Is Letta the same as MemGPT?
Letta is the productized continuation of MemGPT. The MemGPT paper introduced the idea of an agent managing its own context like an operating system pages memory, and Letta is that concept built into a framework with a managed option.
Are Mem0, Zep, and Letta open source?
All three have open-source cores and commercial managed offerings. Zep's temporal graph, Graphiti, is open source while Zep itself is offered as a managed service. Check each project's current licence before committing, since licensing in this category has changed before.
Which agent memory framework is best?
There is no single best. Mem0 is the fastest path to working per-user memory, Zep is the strongest where facts change over time and governance matters, and Letta is the most agent-native for long-running autonomous work. The deciding test is which one remembers the right things from a week of your own traffic.
Can these frameworks give an agent memory of my whole company?
Not on their own. They store what a given application or agent observes. Company-wide memory requires ingesting from systems of record rather than conversations, sharing one picture across agents and people, and inheriting permissions from the sources. That is a platform concern rather than a library concern.
Do I need a knowledge graph for agent memory?
Only if your users ask structured questions. Similarity search over vectors handles "find something like this" well and fails at counting, enumeration, negation, and multi-hop traversal. If those questions matter, you need graph structure. If they do not, a vector store is simpler.
Related reading
- What Is AI Agent Memory? Types and Architectures
- What Is MCP (Model Context Protocol)?
- What Is an LLM Gateway?
- LLM Agent Architecture
- AI Agent Orchestration Platforms
- Agent Workflows Explained
- Enterprise AI Agents
- 16 Ways to Use AI For Knowledge Management
- 8 Best AI Agent Builders for Enterprise Teams
For how retrieval and the connection layer differ, see RAG vs MCP.
Ready to get started?
Put Coworker to work inside your actual stack
Connect Salesforce, Slack, Jira, whatever you use, and run your first agent in minutes.