You’ve probably had this experience: you spend half an hour explaining your situation to an AI customer service bot, laying out the context carefully, and the next day when you open the chat again, it treats you like a total stranger. You told it last week that a certain feature was causing problems. It suggests that exact feature to you again.
This isn’t the model being dumb. It simply has no concept of memory. Large language models are stateless by design. Once a conversation ends, whatever fit inside that context window disappears with it. If you want an agent to remember who a user is, where a conversation left off, or which preferences have already been confirmed, that capability doesn’t come from the model itself. It comes from a memory layer bolted on beside the model, one that extracts the important bits after a conversation ends and retrieves them before the next one starts.
That sounds simple in theory and turns out to be full of hard problems in practice. What to store, how long to keep it, how to resolve conflicting updates, how to rank results at retrieval time. Each of these questions has spawned its own technical approach, and the differences between approaches aren’t cosmetic. They shape whether your whole system ends up locked into a particular framework down the road.
Cognee is one of the better-known projects tackling this space. It turns conversation history, documents, and structured data into a knowledge graph, storing it in a graph database while pairing it with vector search for retrieval. The project has crossed thirty thousand stars on GitHub. But it isn’t the only answer. Around the problem of long-term agent memory, a handful of tools with fundamentally different philosophies have grown up alongside it: Mem0, Letta, Zep, and for teams who’d rather skip the packaged solutions entirely, plain vector database setups built from scratch.
Understanding what each of these actually solves matters more than memorizing star counts. Pick the wrong memory layer and the cost of switching later is higher than swapping out a database, because your agent’s behavior ends up architecturally dependent on how memory is structured underneath it.
What Cognee actually does
Cognee’s pipeline is pluggable. Data passes through chunking, extraction, and tagging steps before landing in both a graph database and a vector store. This design suits situations where the source data itself is messy and varied. You might be feeding it customer chat logs, product documentation, and PDFs a user uploaded, all at once. Cognee’s pipeline approach can process this heterogeneous input into a single graph structure, so whether you’re doing semantic retrieval or relationship queries afterward, everything lives in one place.
The project is open source (GitHub: topoteretes/cognee) and fully self-hostable. There’s also a managed cloud tier: $35 a month for the Developer plan, $200 a month for Team. One thing worth flagging up front is a dependency that’s easy to overlook: whether you self-host or use the cloud version, generating embeddings requires an OpenAI API key. Even a fully self-hosted deployment still leans on an external service for the vectorization step, and that’s a detail that matters when you’re running a data compliance review.
With that baseline established, the other tools in this space become easier to place, because they aren’t simple substitutes for each other. They’re different answers to the same underlying question.
Mem0: memory as a plain API
Where Cognee starts by building a graph and treats memory as a byproduct, Mem0 goes the opposite direction. It abstracts memory down to a basic interface: add, update, delete, retrieve. Developers who don’t want to think about whether the backend uses a vector store or a graph database can wire it into almost any agent framework with a handful of lines of code.
That lightweight integration model has made it popular with teams that need to validate an idea quickly. The project (mem0ai/mem0) has racked up close to sixty thousand stars on GitHub, is licensed under Apache 2.0, and self-hosting is free with no features held back. The managed platform splits into four tiers: a free Hobby plan capped at ten thousand memory writes and a thousand retrievals a month, a Starter tier at $19 a month, Growth at $79, and a top Pro tier at $249 a month that unlocks graph memory, more advanced retrieval, and compliance certifications like SOC 2 and HIPAA.
Lock-in with Mem0 is fairly light. It’s a memory service with a clean API boundary sitting between it and your agent framework or orchestration logic. If you decide to switch it out later, you swap the memory calls and leave the rest of the agent untouched. That’s a very different philosophy from Letta, which comes next.
Benchmark numbers here are worth treating with some caution. Third-party comparison articles report LoCoMo scores that don’t agree with each other. Some tables list Mem0 at 68.5, while Mem0’s own research page shows 92.5. Numbers reproduced by outside sources are best treated as a rough guide rather than a settled fact. Running your own evaluation on your actual workload is the more reliable path.
Letta: letting the agent manage its own memory
Letta used to be called MemGPT, and the rename reflects a sharpening of focus rather than a rebrand for its own sake. The idea traces back to a paper by Packer and colleagues (arXiv:2310.08560), and the core metaphor borrows from how operating systems manage RAM: core memory sits in the context window, functioning like CPU registers, while archival memory gets pulled in on demand, more like disk storage. The key difference is that the agent itself can edit its own core memory blocks, deciding what stays in the fast tier and what gets paged out.
This isn’t a memory API you call from outside. It’s a full runtime environment for the agent. Adopting Letta means handing over the agent’s operating logic to its framework. The upside is that memory management becomes something the agent can reason about on its own; the cost is that you aren’t just integrating a memory store, you’re adopting an entire agent operating system, with a much deeper degree of framework commitment.
There’s a detail worth spelling out here: the core memory blocks in Letta can be rewritten by the agent itself, which means the accuracy of what gets remembered depends partly on the agent’s own judgment. If the underlying model is inconsistent about summarizing or discarding information, the memory content will drift too, and that risk profile is different from systems like Mem0 or Zep, where memory writes are governed by external rules or algorithms rather than the model’s own discretion. Choosing Letta effectively hands part of memory management over to the model itself, which raises the bar for both model capability and prompt design.
Letta is also Apache 2.0 licensed (roughly twenty-three thousand GitHub stars), self-hostable with no feature gating, and its desktop ADE (Agent Development Environment) interface, once tied to a cloud requirement, now runs locally, lowering the barrier to entry considerably. Managed cloud pricing starts at $20 a month for the Pro tier, with higher tiers scaling based on active agent count and tool call volume, which fits teams running a fleet of long-lived agents.
Set against Mem0, Letta suits situations where you’re building a complex, autonomous agent from the ground up and memory is just one piece of that system. If you just want to bolt a memory layer onto something that already exists, Mem0’s lightweight integration will get you there with less friction.
Zep: knowledge graphs with a sense of time
Zep addresses a different problem: not just remembering what happened, but remembering when a fact became true and whether it’s since been superseded. Underneath, it runs on Graphiti, a temporal knowledge graph engine that stores relationships with timestamps and validity windows rather than static facts. Say a user mentioned last month they worked in Beijing, then this month said they’d moved to Shanghai. Zep can tell which fact is currently valid and which one is historical, rather than simply overwriting the old entry or letting the two contradict each other.
This time-aware memory model matters in situations where you need to track a user’s evolving state over a long stretch, customer service systems and personal assistants being the obvious examples. Zep’s published benchmarks show 94.7% on LoCoMo and 90.2% on LongMemEval, with response latency in the low hundreds of milliseconds.
It’s worth being precise about where Zep’s open source boundary sits. The Graphiti graph engine itself is open source under Apache 2.0, and you can pair it with Neo4j, FalkorDB, or Kuzu to self-host. The full Zep platform, particularly its enterprise governance features (data access control, retention policies, audit logs, SOC 2 Type II, HIPAA BAA) is only available through Zep Cloud, billed on a credit system. The Flex tier runs $25 a month for twenty thousand credits, scaling up to Flex Plus at $475 a month for three hundred thousand credits. The earlier Community Edition, which could be self-hosted as a complete package, has been discontinued. What remains on the open source side is Graphiti plus a separate graph database you manage yourself, a meaningfully different operational shape from Mem0’s install-and-run SDK.
Is rolling your own vector setup worth it?
The three tools above are all packaged products, but plenty of teams ask the obvious question: why not just spin up Chroma or Postgres with pgvector and build a memory layer yourself? Slice up conversation content, generate embeddings, store them in a vector database, and retrieve the most semantically similar entries at query time. The logic isn’t complicated, and tutorials for this pattern are everywhere.
The upside is that control stays entirely in your own hands. You’re not dependent on any third party’s uptime or pricing decisions, and your data never leaves your own infrastructure. The tradeoff is just as direct: memory scenarios involving entity relationships or facts that shift over time are a poor fit for plain vector retrieval, because similarity search alone has no structural way to reason about relationships. Write policies (what to keep, what to discard, how to deduplicate) and retrieval ranking logic are problems packaged tools have already solved for you. Building your own means solving them all again, and whatever integration cost you saved upfront tends to reappear later as maintenance debt.
There’s also a team scale factor that’s easy to underestimate. Packaged tools come with a community and documentation behind them when something breaks. A custom setup means the debugging falls on whoever built it. Teams without a dedicated owner for the memory layer tend to accumulate technical debt as the business grows more dependent on it, and by the time real problems surface, there’s often a fair amount of historical baggage already in place. The build-it-yourself path tends to work best for teams that already have vector retrieval experience and are confident they don’t need complex relationship reasoning, purely optimizing for cost and keeping data in-house.
Putting them side by side
Lining these tools up in a table, using dimensions that can actually be verified rather than subjective impressions of ease of use:
| Tool | License | Self-hosted | Cloud starting price | Core storage |
|---|---|---|---|---|
| Cognee | Open source | Supported | Developer $35/mo | Neo4j/NetworkX + Qdrant/Weaviate |
| Mem0 | Apache 2.0 | Supported, full features | Starter $19/mo | Custom vector store + graph (Pro tier) |
| Letta | Apache 2.0 | Supported, full features | Pro $20/mo and up | PostgreSQL/SQLite |
| Zep (Graphiti) | Apache 2.0 (engine) | Engine portion only | Flex $25/mo | Neo4j/FalkorDB/Kuzu |
| Custom vector setup | N/A | Fully independent | N/A (infrastructure cost only) | Chroma/pgvector, etc. |
What the table can’t capture is fit. These tools aren’t really competing for the same job. They’re answering different questions: whether you want a memory API you can drop into any agent, a full runtime where the agent manages its own state, or a graph built specifically to track how facts change over time.
Back to the scenario at the start: if the goal is just making sure a customer service bot remembers what a user said last time, Mem0’s lightweight integration is probably the highest-value choice for the effort involved. If you’re building a long-running, autonomous agent from scratch where memory management is one piece of a bigger system, Letta’s operating-system approach fits more naturally. If your business deals with a lot of facts that change over time (contract status, user identity details, order states) and you need to explain exactly when a given conclusion became true, Zep’s temporal graph is currently the one option purpose-built for that. As for Cognee, its knowledge graph pipeline suits situations where the data source itself is messy and needs entities and relationships extracted from documents and conversations. If your team has already accepted the OpenAI dependency that comes with it, its self-hosting flexibility is among the strongest of the options here.
None of these is the objectively correct answer. It depends on whether the problem you’re solving is integration, state management, or tracking facts across time. Getting clear on that question first is worth more than any GitHub star count or pricing page comparison.
Related reading
- Dragonfly vs Redis: Which In-Memory Database Should You Pick
- The Real Lock-In Was Never the Model: AI Memory Can Now Move With You
- AI Agent Memory Systems Compared: Letta vs Mem0 vs Zep – Best Choice for Your Agent Stack in 2026
Stay updated with our latest AI insights
