The AI memory market is getting crowded. At least five distinct architectural approaches have emerged in the last eighteen months, each backed by real funding, real users, and real engineering talent. They are not all solving the same problem — and that matters more than most comparison articles acknowledge.

Choosing the wrong approach doesn’t mean choosing a bad product. It means building on a foundation that doesn’t match your actual need. A temporal knowledge graph is brilliant if you need to track how facts change over time. It’s unnecessary overhead if you need a lightweight context layer across multiple AI tools. An agent runtime that manages its own memory is elegant if you’re building within that runtime. It’s a non-starter if you’re working across Claude, ChatGPT, Gemini, and Codex simultaneously.

Here are the five approaches, what each actually does, and the trade-offs nobody puts in their marketing copy.

1. Cloud-Extracted Memory: Mem0

Mem0 is the best-funded and fastest-growing player in the space. They raised a $24M Series A in July 2025 at a $150M valuation, backed by Y Combinator, Peak XV Partners, and the GitHub Fund. Their API calls grew from 35 million to 186 million in two quarters — a 5x increase that puts them ahead of every competitor on raw adoption, with over 100,000 developers on the platform.

The approach is straightforward: extract memories from conversations using an LLM, store them in their cloud, retrieve them via API. Four atomic operations — ADD, UPDATE, DELETE, NOOP — manage the lifecycle. Their retrieval returns roughly 1,764 tokens per conversation, which is efficient compared to dumping an entire conversation history into context.

What it does well. If you’re building a cloud application and need persistent memory across user sessions, Mem0 is the simplest path. “One line of code” is not far from the truth for basic integration. The managed service handles storage, extraction, and retrieval. You focus on your application logic.

The trade-off. Your data goes through their extraction pipeline. Every conversation is processed by their LLM to identify what should be remembered. For many use cases, this is fine. For privacy-sensitive workflows or organizations that need data to stay local, it’s a constraint. Mem0 does offer enterprise on-premises deployment, but the default path is cloud-first.

The deeper architectural limitation: Mem0 retrieves based on semantic similarity. It finds memories that are related to the current context. It does not classify what the current request actually needs before retrieving. The distinction matters — similarity-based retrieval pulls back what’s related, not necessarily what’s relevant to the specific task at hand.

Source: Mem0 Series A announcement, State of AI Agent Memory 2026

2. Temporal Knowledge Graph: Zep

Zep takes a fundamentally different approach. Where Mem0 extracts and stores discrete memories, Zep builds a temporal knowledge graph — a structured representation that tracks not just what’s true, but when it became true and what it replaced. They open-sourced the underlying library, Graphiti, and published peer-reviewed research on the architecture (arXiv, January 2025).

The results are real: 18.5% improvement on long-horizon accuracy benchmarks and 90% latency reduction versus their baselines. In a field full of unsubstantiated claims, Zep’s willingness to publish is notable.

What it does well. If your use case involves facts that change over time — customer preferences that evolve, project states that shift, relationships that develop — the temporal dimension is genuinely valuable. Knowing that a user’s preferred programming language was Python in 2024 but shifted to Rust in 2025 is more useful than just knowing both languages appear in their history. Zep’s graph captures that trajectory.

The trade-off. Zep raised only $500K in seed funding — significantly underfunded relative to their architectural ambition. Building and maintaining a temporal knowledge graph is computationally heavier than flat memory storage. The graph approach adds complexity that’s justified for temporal reasoning but unnecessary for simpler context needs.

And like Mem0, Zep retrieves based on graph traversal and similarity. The retrieval is more structured, but it still starts from the query and works outward to find related context. No pre-classification of what the request actually requires.

Source: Graphiti: Temporal Graph for Agentic AI, getzep.com

3. Self-Editing Agent Memory: Letta (MemGPT)

Letta — the company behind the MemGPT research — approaches the problem from the agent’s perspective. Instead of an external memory layer that stores and retrieves, Letta gives agents the ability to manage their own memory. The agent decides what stays in active context, what gets archived, what gets updated, and what gets forgotten.

They raised a $10M seed in September 2024 at a $70M post-money valuation, spinning out of UC Berkeley’s Sky Computing Lab. Jeff Dean and Clem Delangue (Hugging Face CEO) are angel investors — a signal that the research community takes the architecture seriously.

What it does well. The elegance is real. When an agent manages its own memory, memory decisions become contextual. The agent knows what it’s working on and can make informed choices about what to keep accessible and what to archive. The recently launched Letta Code product brings this to developer workflows with a full agent runtime and REST API.

The trade-off. Letta is a runtime, not a layer. You don’t add Letta to your existing setup — you adopt Letta’s execution model. If you’re building agents within Letta, that’s fine. If you’re using Claude Code on Monday, Cursor on Tuesday, and ChatGPT on Wednesday, Letta doesn’t bridge those tools. It’s not MCP-native. The memory lives within the Letta runtime, which means your context is only as portable as the runtime itself.

The social proof gap is also worth noting. Despite strong research credentials, Letta’s website shows no customer logos, no testimonials, and no adoption metrics. For engineering leaders evaluating production readiness, that absence is a data point.

Source: Letta: Our Next Phase

4. Framework-Coupled Memory: LangMem

LangMem is not a product. It’s an open-source SDK from LangChain, launched in February 2025, that adds long-term memory capabilities to agents built on LangGraph.

The architecture defines three memory types: semantic (facts and knowledge), procedural (how to do things), and episodic (past experiences). Background extraction processes run after conversations to consolidate memories. The SDK works with any storage backend, and since it’s open-source, there’s no vendor lock-in on the memory layer itself.

What it does well. If you’re already building in the LangChain/LangGraph ecosystem, LangMem integrates naturally. The three-memory-type framework is well-thought-out — the distinction between knowing a fact, knowing how to do something, and remembering a specific experience maps cleanly to how humans organize knowledge. And it’s free. No usage fees, no per-memory pricing.

The trade-off. LangMem is tightly coupled to LangGraph. That coupling is a feature if you’re in the ecosystem and a wall if you’re not. If you’re using Claude Code, Cursor, ChatGPT, or any non-LangChain tool, LangMem doesn’t help. Your memory only exists within the LangGraph execution context.

LangChain itself positions memory as a feature within their broader agent engineering platform, not as the headline. LangSmith — their observability and evaluation product — gets the homepage. Memory is downstream. That’s an honest reflection of where memory sits in their architecture, but it also means LangMem gets less investment and attention than a standalone product would.

Source: LangMem SDK documentation, LangMem SDK launch announcement

5. Local-First MCP Context Engineering: grāmatr

Full disclosure: this is our product. I’m including it because leaving it out of a comparison we’re publishing would be more dishonest than including it with caveats. Here are the caveats.

grāmatr takes a different architectural approach than the other four. It’s an MCP server — Model Context Protocol, the open standard that Claude, ChatGPT, Gemini, VS Code Copilot, and Codex all support — that sits between you and every AI tool you use. It’s local-first: your data stays on your machine. No cloud extraction pipeline. No API calls to a remote memory service.

The core difference is pre-classification. Before any context gets retrieved, grāmatr classifies the incoming request — what type of work is this, what effort level does it require, what capabilities are relevant, what context would actually help. That classification runs in under 100 milliseconds on CPU. Then it delivers a targeted intelligence packet — typically around 1,200 tokens — rather than retrieving everything that’s semantically similar.

The learning dimension: corrections feed back into classification accuracy. Over 1,933 learning corrections across 5,830 routed requests, the system has improved its ability to identify what each request actually needs. The classification gets more accurate with use, which means the context delivery gets more precise.

What it does well. Model-agnostic across every MCP-compatible tool. Local-first with no data leaving your machine. The pre-classification approach means it delivers less context (1,200 tokens vs. the 40,000+ tokens typical of similarity retrieval) with better relevance, because it routes based on what the request needs rather than what’s semantically nearby.

The trade-off. grāmatr is earlier stage than Mem0 — private beta, smaller community, no $24M in funding. It doesn’t have 100,000 developers or 48,000 GitHub stars. If you need a production-ready managed service with enterprise compliance certifications today, Mem0 or Zep’s enterprise tier is a more established path. grāmatr’s strength is architectural — the pre-classification approach and cross-tool portability — but architectural advantages take time to compound into ecosystem advantages.

The Real Question

The comparison that matters isn’t “which is best.” It’s “which matches your architecture?”

Building a cloud API product that needs persistent user memory? Mem0’s extraction model fits. Simple API, fast integration, managed infrastructure.

Need to track how facts change over time? Zep’s temporal knowledge graph is the only approach that models the when dimension. If temporal reasoning matters to your use case, no other tool does this.

Want agents that manage their own context autonomously? Letta’s runtime handles it. The agent-as-memory-manager architecture is genuinely elegant — if you’re willing to adopt the runtime.

Deep in LangChain and need memory for your LangGraph agents? LangMem integrates naturally and it’s free.

Working across multiple AI tools and want your context to follow you everywhere? That’s where grāmatr sits. MCP-native, local-first, model-agnostic.

These are not competing answers to the same question. They’re different answers to different questions. The worst outcome isn’t choosing the “wrong” product — it’s choosing a product that solves a problem you don’t have while leaving your actual problem unaddressed.

What’s Missing from the Comparison

There’s one architectural dimension that only one of these five approaches addresses: pre-classification.

Every approach except grāmatr follows the same retrieval pattern: receive a request, search for related context, deliver what comes back. The quality of the delivery depends on the quality of the search — and similarity search, even with temporal graphs or structured memory types, returns what’s related. Not necessarily what’s needed.

Pre-classification inverts that sequence. Before any retrieval happens, the system determines what the request actually requires. A code review needs different context than a brainstorming session. A quick factual lookup needs different context than a multi-step architectural decision. Classifying first means the retrieval is targeted — the system knows what to look for before it starts looking.

The result: 1,200 tokens of targeted context instead of 40,000 tokens of everything-that-might-be-relevant. Not because the information was compressed. Because most of it wasn’t needed.

This is the architectural bet grāmatr is making. It might be the wrong bet — classification adds a step, and classification errors mean delivering the wrong context entirely. But if the bet pays off, the implications are significant: faster responses, lower token costs, better accuracy, and a system that improves its own context delivery over time rather than just accumulating more data to search through.

The market will decide. In the meantime, five approaches exist. They’re all real, they’re all shipping, and they all solve different problems. Choose based on yours.