Letta vs Mem0 for agent memory: architecture, privacy, and cost

Bottom line

Letta and Mem0 both address the problem that an agent loses useful state when a model call or session ends. That shared outcome makes them appear interchangeable. Their architectural boundaries are different enough that a feature checklist can produce the wrong decision.

Letta is a platform for stateful agents. Its documented model puts editable memory blocks inside the agent’s active context, alongside conversation state, tools, execution, and deeper archival material. The agent can participate in managing what remains visible. A team choosing Letta is therefore choosing an agent runtime and its memory model together.

Mem0 is positioned as a universal memory layer. An application sends interactions or facts to it, and later asks for relevant memories. Its open-source documentation describes both an embeddable library and a self-hosted server. A team can retain its existing agent loop, model client, user experience, and orchestration while delegating memory extraction, storage, and retrieval.

That is the decision: adopt a memory-native agent runtime, or add a memory service to an architecture you already own. Letta is the more coherent candidate when the agent itself should manage evolving state and context. Mem0 is the lower-boundary-change candidate when the application already works and needs persistent facts across users, sessions, agents, or organizations. Neither choice establishes accurate recall, correct forgetting, privacy, or production reliability without a representative evaluation.

This is a source-verified comparison. ToolVerse did not install, deploy, use, benchmark, security-test, or load-test Letta or Mem0.

Who it is for

This comparison is for teams that can name a persistent-memory job more specific than “make the agent remember.” Useful requirements include maintaining a user preference across sessions, preserving the state of a long-running task, sharing an approved organizational fact across agents, recalling a past decision with provenance, or replacing a stale fact without resurfacing the old one.

Letta deserves a shortlist when the product is fundamentally an ongoing agent. The team may want memory blocks that remain in context, agent-driven edits, shared blocks, conversation history, archival retrieval, tools, scheduled work, and execution records under one runtime. That can reduce glue between separate orchestration and memory systems. It also means the application is accepting more of Letta’s agent model.

Mem0 deserves a shortlist when an application or framework already owns the agent loop. A support assistant, tutor, companion, workflow system, or multi-agent service may need a consistent add-and-search boundary without being rebuilt around a new runtime. The open-source library path is especially relevant when developers want to select their own language model, embedding model, vector store, and reranker.

Before selecting either product, use the agent memory architecture guide to separate working context, episodic history, durable facts, task state, and organizational knowledge. Those categories need different write, retrieval, retention, and authority rules. A single “memory” requirement conceals those differences.

Who should skip it

Skip both when ordinary application state is sufficient. An order status, account tier, approved address, workflow step, or policy version belongs in an authoritative database with typed fields and deterministic update rules. A language-model-mediated memory layer should not become the source of truth merely because an agent reads the value.

Also skip a specialized memory system when a short bounded conversation already fits safely in context, or when the job is retrieval from a controlled document corpus. Document search and relationship memory overlap technically, but they have different ownership and freshness requirements. Buying agent memory to compensate for weak source retrieval adds another failure surface.

Letta is a poor fit if the team wants to preserve its current runtime and add only a narrow memory API. Its value comes from integrating state, context management, and agent execution; using it as if it were only a vector-search wrapper ignores that value and may create unnecessary migration work.

Mem0 is a poor fit if the team wants the agent’s identity, active context, tools, long-running execution, and memory policy to be one opinionated runtime. Mem0 can support applications and agent frameworks, but the surrounding control loop remains the application’s responsibility.

Skip production deployment of either product when no owner can define memory authority, inspect writes, resolve conflicts, honor deletion, evaluate retrieval, patch dependencies, restore storage, and investigate an incident. Persistent memory turns a transient model error into durable state. That deserves stronger controls, not a casual SDK call.

Capabilities and limitations

The fairest comparison starts with architecture rather than counting similarly named features.

Decision area	Letta	Mem0	What to validate
Primary abstraction	Stateful agent runtime with memory built into agent state and context	Memory layer called by an existing app or agent stack	Which system should own the agent loop?
Write model	Agent-managed and application-managed memory blocks, conversation state, and archival paths	Extraction and memory operations submitted through a library, API, or server	Which facts are accepted, rejected, merged, or replaced?
Retrieval model	Always-visible blocks plus searchable conversation and archival material	Search over stored memories using configured retrieval components	Is every returned memory relevant, current, authorized, and supported?
Sharing scope	Blocks can be attached to multiple agents	Memories can be scoped through application identifiers and metadata	Can one user or agent receive another’s memory?
Deployment	Cloud plus current local app, CLI, SDK, and App Server paths; legacy V1 Docker surface is deprecated	Managed Platform plus open-source library and self-hosted server	Which components and providers remain external?
Extensibility	Models, tools, MCP, memory blocks, runtime behavior, and app-server integration	LLM, embedder, vector store, reranker, framework integrations, and API	Who owns compatibility and regression tests?

Letta’s memory-block documentation says blocks are agent-managed, flexible, shareable, and always visible in context. This design makes a small amount of curated state immediately available without retrieval. It also creates a scarce-context and write-governance problem. The same documentation warns that a direct block update replaces the entire value and that concurrent modifications are last-write-wins. A team needs size budgets, edit policy, conflict handling, version evidence, and recovery for shared blocks.

Deeper material can remain outside the active context and be searched when needed. This tiered approach is meaningful because remembering a stable preference is not the same operation as searching a long conversation. Its quality still depends on model behavior, tool use, prompting, embeddings, and the surrounding agent policy.

Mem0’s open-source documentation describes a configurable extraction-and-retrieval stack. The library defaults documented on the verification date include an OpenAI model and embeddings, local Qdrant, and SQLite history; the server defaults use Postgres with pgvector and configurable providers. “Self-hosted” therefore does not necessarily mean model calls stay local. Operators must replace defaults or approve those external paths.

The current Mem0 repository describes a single-pass, add-only extraction algorithm, multi-signal retrieval, entity linking, and temporal reasoning. Those are vendor-maintained implementation and benchmark claims, not independently reproduced results in this review. Add-only accumulation also changes the acceptance questions: test contradiction, supersession, duplication, deletion, and whether an old fact can outrank the current state.

Both projects publish Apache 2.0 repository licenses for the cited code. That does not automatically license every hosted service, model, integration, dataset, or future component under the same terms. Record the exact repositories and revisions used, then have legal review map them to the planned distribution and service model.

The operational security boundary extends beyond memory storage. Tools and MCP servers can turn recalled state into action, and recalled untrusted text can influence tool arguments. The MCP security checklist provides the separate controls for server trust, scopes, approvals, egress, logging, and revocation.

Community feedback: consensus and disagreement

Public discussion supports two recurring themes, but it does not establish product-wide defect rates.

The first theme is that memory benchmarks are hard to compare. A Letta repository issue requested standardized LoCoMo, MemBench, and LongMemEval support and described the absence of a common comparison path. A separate Reddit discussion about Letta’s critique of memory-tool benchmarking debated whether retrieval-style benchmarks measure an agent’s ability to manage context at all. Together they support a practical conclusion: do not carry a vendor score from one model, prompt, corpus, or abstraction layer into a different system design.

The second theme is memory selection and correction. One Mem0 issue reports that a particular operator’s audit retained only a small fraction of extracted entries after applying its own quality criteria. A separate Reddit thread covering Mem0, Letta, Zep, and other systems asks how to represent temporal supersession and deterministic structure when memory tools retain generic facts. These reports support testing what gets written, how provenance is preserved, and how stale state is retired. The percentages and causes in the GitHub report remain one deployment’s anecdote; they are not generalized here.

Community disagreement often follows architecture. Some practitioners prefer a callable layer because it preserves an existing stack. Others prefer agent-managed memory because extraction outside the runtime can miss task state and intent. Both positions can be reasonable for different applications.

The independent sources reinforce that boundary without settling product performance. Hamza Shabbir argues that many applications should begin with a simpler database until they can name consolidation, decay, or shared-memory needs. Ken Huang analyzes memory as a lifecycle of selection, writing, storage, retrieval, and forgetting. We The Flywheel distinguishes Mem0’s drop-in layer from Letta’s stateful runtime. These are attributed analyses, not controlled tests commissioned by ToolVerse. Their product descriptions informed the decision axes; official sources govern capabilities, license, hosted and self-hosted boundaries, privacy, and price.

Cost and operational ownership

The July 29, 2026 Letta pricing page lists an API plan at $20 per month, active-agent and tool-execution charges, pay-as-you-go model usage, and a Teams Pro plan at $20 per seat per month. The same page is the authority for current limits and should be rechecked at purchase. Hosted cost must include model usage, agent activity, tool execution, storage, environments, and seats rather than only the base subscription.

The Mem0 pricing page lists a free Hobby tier, a $19 monthly Starter tier, a $249 monthly Pro tier, and custom Enterprise terms, with different add and retrieval request allowances and features. Enterprise lists on-prem deployment, audit logs, custom integrations, SSO, and support terms. Do not assume a capability shown in one plan exists in open source or a lower hosted plan.

Self-hosting replaces subscription line items with infrastructure and labor. For either product, model and embedding calls may dominate variable cost. Add database, vector indexing, backups, replicas, network egress, observability, secret management, security review, upgrades, evaluation runs, deletion workflows, and incident response. Letta adds ownership of an agent runtime; Mem0 adds ownership of the application-to-memory contract and whichever OSS components are selected.

Privacy terms also differ by service path. Letta’s policy says hosted services collect data used to render them, including hosted request and response content, and describes possible service-improvement use. Mem0’s policy distinguishes Free and Paid plans for model training and says it does not train on paid-plan prompt and user-generated content. These policies concern hosted processing and can change. Contract terms, data-processing agreements, provider subprocessors, regions, retention, and deletion must be checked for the exact plan.

Local operation narrows but does not erase data movement. Inventory prompt text, extracted facts, embeddings, conversation history, active blocks, archival passages, metadata, tool inputs, traces, backups, support artifacts, and telemetry. For each field, record processor, location, encryption, access, retention, deletion, and recovery.

Alternatives

A typed Postgres table is the first alternative. It can be the safest choice for durable facts with clear owners, explicit timestamps, deterministic updates, and modest scale. Add vector search only where semantic retrieval is necessary.

Zep or Graphiti may fit teams that prioritize temporal relationships and graph-shaped context. LangGraph or another orchestration framework with an application-owned store may fit teams that want explicit workflow state without adopting a complete memory-native runtime. A document retrieval stack remains the better alternative when the job is answering from governed content rather than remembering a relationship.

The agent runtime platform selection guide helps decide how much runtime ownership to delegate. Compare one adjacent architecture, not a long catalog of nearly identical demos.

Recommendation

Choose Letta when memory is part of the agent’s operating model: the agent should maintain compact active state, search deeper history, share approved blocks, use tools, and persist as one runtime. Accept that this is an architectural commitment and verify the current Agent SDK and App Server path. Do not design a new production deployment around the legacy V1 Docker server merely because an old guide still renders; Letta now labels that surface unsupported and points new work elsewhere.

Choose Mem0 when the application and agent loop already exist, and the desired change is a memory boundary with add, search, configuration, and managed or self-hosted options. Preserve authoritative business state outside extracted memory, and test the write pipeline as rigorously as retrieval.

Run the same pilot for both:

1. Define twenty to fifty representative facts, corrections, deletions, and forbidden memories.
2. Replay identical events through the complete Letta agent and the existing application plus Mem0.
3. Test direct recall, temporal change, multi-hop use, irrelevant prompts, cross-user isolation, and prompt-injection attempts.
4. Inspect every accepted write and retrieved item for source, scope, freshness, and authorization.
5. Measure task success, supported recall, false recall, stale-memory rate, latency, model calls, tokens, storage, and operator time separately.
6. Exercise export, deletion, backup, restore, version upgrade, model change, and incident investigation.

Use the coding-agent memory audit guide to build the record format, even for non-coding agents. Approve a bounded workload only when memory improves the user job without creating unacceptable stale-state, privacy, security, or operating risk.

For product context after the architecture decision, inspect the live Letta profile and Mem0 profile. Directory records help track positioning and alternatives; they do not replace the official terms or this representative pilot.

Method and limitations

ToolVerse reviewed the cited public sources on July 29, 2026. The official layer includes product documentation, repositories, licenses, self-hosting routes, privacy policies, and public pricing for both Letta and Mem0. Official sources govern statements about architecture, storage defaults, hosted and self-hosted boundaries, privacy, license, and pricing.

The community layer includes public issues from each declared repository and Reddit discussions. Repeated themes were used to define validation questions. A single deployment’s figures remain an anecdote. Reddit identity, configuration, version, and incentives are usually unverifiable.

The independent layer includes attributed analyses by Hamza Shabbir and Ken Huang plus We The Flywheel Research & Analysis. They offer useful architecture and necessity frameworks, but this review does not adopt their rankings or unverified quantitative claims. None substitutes for a controlled comparison on the reader’s data, models, policies, and workload.

ToolVerse did not inspect private source code, contracts, enterprise controls, customer deployments, network traffic, model prompts, stored memories, deletion behavior, or benchmark implementations. Product surfaces, prices, defaults, and policies change quickly. Recheck every official route, pin versions, and preserve the evidence used for the final decision.