mem0 vs Zep, and where Memtro fits
Two memory layers for the agents you build, compared on their own terms, and when a memory that sits in front of your tools is the better shape.
This comparison describes mem0 and Zep as we understand them at the time of writing from their public documentation. Products change; check the current details before deciding. Memtro makes neither product, and the closing section is the only part that is about us.
Both are memory layers for AI applications that you call from your own code around your own model calls. They solve the same problem — an agent that forgets everything between sessions — and they solve it differently enough that the choice matters.
mem0 is a managed memory layer for AI apps and agents, available as a hosted platform with a dashboard and as an open-source SDK you run locally. You send it messages; an LLM extracts the durable facts and stores them additively, without overwriting what was there; at query time a search returns the most relevant memories for the model's context. Memories are scoped by user, agent, app and run. On the platform, graph memory — entities extracted from memories and linked, used to boost retrieval for multi-hop questions — is built in and always on.
Zep describes itself as a unified context layer for enterprise data. Its unit is the Context Graph, a temporal knowledge graph of facts, relationships, source episodes and changes over time for a user, customer, account or project, built on Graphiti, Zep's open-source temporal graph framework. You create users and threads, add messages, and ask for a context block: an assembled string of the relevant context to put in front of the model. Business data — JSON, text and messages — can be ingested into the graph alongside conversation, and when new data invalidates a fact, the time it became invalid is stored on the fact's edge. Zep is a hosted service with Python, TypeScript and Go SDKs.
Where they differ
| mem0 | Zep | |
|---|---|---|
| Unit of memory | Extracted facts, stored additively and searched | A temporal knowledge graph of facts, relationships and episodes |
| Shape | Hosted platform, or open-source SDK run locally | Hosted service (Zep Cloud); Graphiti, the graph engine, is open source |
| Scope | User, agent, app, run | User graphs, threads, and shared graphs addressed by id |
| Time | Memories added without overwriting; a history endpoint lists changes to one | Facts carry when they became invalid; the graph records changes over time |
| Retrieval | Search for the most relevant memories, boosted by entity links on the platform | A context block assembled from the user's graph |
| Business data | Not the focus; your application decides what to store | JSON and text ingested into the same graph as conversation |
| Getting started | add and search around a model call | Create user, create thread, add messages, get context |
Choosing between them
Choose mem0 when you want the simplest memory primitive inside an application you are building: store what the conversation reveals, retrieve what is relevant, and scope it by user or agent. Its open-source SDK lets you keep it local, and its platform removes the infrastructure.
Choose Zep when the memory has to hold structure and time as well as text: accounts, customers and projects with facts that change and need to be read with their validity, with business records ingested into the same graph as conversation, and a context block you can hand straight to the model.
Both expect you to write the application. Neither has an opinion about which model you use, what tools the agent can reach, or who in the company is allowed to see what.
When a proxy-shaped memory fits better
If the "application" is the tools a team already uses — Claude Code, Cursor, Open WebUI, Slack, the OpenAI and Anthropic SDKs — then an SDK you integrate is the wrong shape, because there is no application code to integrate it into. Memtro is a memory that sits in front of those tools instead: an OpenAI-compatible endpoint and an MCP server that inject the company's memory into every request, learn from every answer, and let the model read the systems the company runs on through connectors. Its memory is a bitemporal knowledge graph, like Zep's, with facts superseded rather than overwritten and readable as of any date; its scope is the organisation, with personal and shared facts classified per fact and permissions per team; and the model is chosen and capped by routing rather than by your code.
For a product you are shipping to your own users, mem0 or Zep is the right tool, and the two detailed comparisons say where each stands against Memtro: Memtro vs mem0 and Memtro vs Zep. For a company that wants its own people and agents to share one memory, with nothing to build, the proxy is the shorter path.