Mem0 vs Letta: Memory Layer or Stateful Agent Runtime?

Mem0 vs Letta sounds like a comparison between two memory databases. It is not. Mem0 is primarily a memory layer you add to an existing application; Letta is a stateful agent platform in which memory management is part of the agent runtime. Choosing between them is therefore an architecture decision, not a benchmark leaderboard.

There is another useful boundary for durable project knowledge: your agent's memory can be files you can read, edit, diff, and self-host—not only facts reconstructed through an API. Meshnote exposes markdown wikis through MCP, so different agents can maintain the same inspectable knowledge without sharing a runtime.

The answer in 30 seconds

Choose Mem0 when an application already has an agent loop and needs a relatively narrow add/search memory service across users, sessions, or agents.
Choose Letta when you want long-lived agents whose identity, tools, messages, context, and memory live together, and you accept its runtime model.
Choose readable markdown over either for canonical runbooks, decisions, architecture notes, and policies that humans must approve or correct directly.

A hybrid is often strongest. Keep conversational preferences in Mem0 or Letta, but keep “how production deployment works” in a reviewed knowledge base. The self-hosted agent memory guide explains why storage ownership and operational ownership are separate questions.

What the leading comparisons get right—and miss

The current top results consistently identify the essential difference. Vectorize frames Mem0 as a pluggable layer and Letta as an agent runtime, then compares extraction, retrieval, developer experience, hosting, and pricing. Mem0's own comparison emphasizes integration friction, memory scopes, compliance, and its published 2026 benchmark claims. MCP Directory broadens the field to Zep and Cognee, with recipes and a useful taxonomy: stable preference memory, self-managed agents, temporal graphs, and document graphs.

Those pages are useful, but they mostly stop at selection. They do not show how to test whether you can leave. Below is a practical exit drill: export one agent's memory, reconstruct the facts a replacement would need, and measure what semantics disappear. Portability deserves a first-class acceptance criterion because an export file is not the same thing as a portable memory system.

Architecture: who owns the agent loop?

Mem0 sits beside your runtime. Your code decides when to submit messages for memory extraction, which scope identifiers to attach, when to search, and how retrieved facts enter the prompt. Current open-source documentation describes configurable LLM, embedding, vector-store, and history components; current releases also document hybrid search, entity linking, reranking, and a self-hosted server. That modularity is valuable when you already use LangGraph, the OpenAI Agents SDK, or a custom orchestrator.

Letta makes the persistent agent the primary object. An agent has model configuration, tools, messages, and memory blocks. Core blocks such as human or persona can remain in context, while larger data can live outside it and be searched or attached as needed. The agent can edit memory through tools. This makes statefulness coherent, but adoption reaches farther into orchestration than adding two memory API calls.

That boundary also changes debugging. With Mem0, inspect the application event, extraction result, stored record, retrieval query, and prompt injection. With Letta, inspect the agent's context and the tool call by which it changed memory. Neither is automatically more reliable; they expose different failure chains.

Mem0 vs Letta comparison

Decision	Mem0	Letta	Readable markdown via MCP
Primary abstraction	Memory service/layer	Stateful agent runtime	Shared wiki and tools
Write policy	Application submits content; extraction pipeline resolves memories	Agent/runtime can edit structured memory blocks	Agent writes named pages; humans can edit the same source
Best fit	Adding personalization or recall to an existing stack	Building durable agents as hosted objects	Canonical decisions, procedures, research, project context
Retrieval	Search over extracted memories; configurable hybrid/reranking options	In-context blocks plus agent/runtime retrieval	Page reads, links, backlinks, and text search
Migration cost	Memory adapter and data conversion	Agent state, tools, prompts, memory semantics, and runtime conversion	Low data-format risk; client tool wiring still changes
Weak spot	Extraction may discard wording or provenance your domain needs	Agent-directed writes can be harder to make deterministic	Not optimized for automatic recall from millions of chat facts

Zep is worth evaluating when facts change over time and temporal relationships are central. Native memory in ChatGPT or Claude is convenient for personal continuity, but it is tied to that product and is not a team-owned application datastore. These are legitimate choices; the right unit of comparison is the job the memory must perform.

The missing test: run a memory exit drill

Before committing, create a disposable agent and load these six cases. This is not a vendor benchmark. It is an operational test you can run against either system and repeat after upgrades.

Preference: “Use Celsius.” Verify recall under a differently worded weather question.
Correction: write “Project Atlas uses MySQL,” then correct it to PostgreSQL. Verify the obsolete fact does not win.
Scope: give two users conflicting preferences and prove retrieval never crosses user boundaries.
Provenance: record where the database decision came from. Ask for the fact and its source.
Deletion: delete one fact, then test direct search, semantic paraphrases, histories, and backups.
Export: export the agent and rebuild equivalent behavior in a blank environment without access to the original service.

For the export step, produce a neutral manifest rather than merely saving a vendor response:

{
  "subject": "project-atlas",
  "facts": [
    {
      "text": "Production uses PostgreSQL 17.",
      "scope": "team:platform",
      "source": "adr/0042",
      "valid_from": "2026-08-01T00:00:00Z",
      "supersedes": "memory-018"
    }
  ]
}

Map each source system into that shape and write down every loss: embeddings cannot be moved meaningfully between models; Letta memory blocks carry placement and runtime semantics; extracted facts may not retain the original passage; graph edges and temporal validity need explicit representation. Then import into a blank target and rerun cases 1–5. The important metric is not “export succeeded.” It is how many behavioral guarantees survived.

This drill is the original element most comparison pages omit. It turns vague lock-in concern into a testable migration budget. Run it with 100 representative memories before production, not with a million after a pricing or architecture change.

How to make the decision

Pick Mem0 if you can draw your agent runtime as one box and memory as another, and you want to preserve that separation. Pick Letta if the persistent agent itself is your application primitive and self-managed context is a feature, not an implementation detail. Pick neither as the sole source of truth when operators must review exact wording, approve changes, or recover a known page version.

Benchmark numbers can inform retrieval experiments, but vendor-reported scores are sensitive to model, prompts, corpus construction, token budget, and evaluation version. Reproduce tests on your workload. A support assistant needs correction and tenant-isolation tests; a coding agent needs exact commands, provenance, and rollback; a companion agent may prioritize preference recall.

For the last category—shared operational knowledge—Meshnote keeps memory in readable markdown and makes it agent-agnostic through MCP. Use the MCP memory server guide to understand the protocol boundary, or the Claude Code memory walkthrough for an integration example.