mem0

Overview

mem0 (mem0ai/mem0) is a production-ready long-term memory layer for AI agents (60.6k⭐). It is listed in the vault’s Resources page and the comprehensive report as the leading memory-first system — a universal memory layer for agents.

Key Facts

• Stars: ~60.6k (the most-starred memory layer in the ecosystem)
• Type: universal memory layer for production agents
• Paper: “Mem0: Towards Production-ready Long-term Memory” (arXiv:2504.19413)
• Family: memory-first (retains facts/context across sessions)

Architecture (2026 refresh): add-only extraction

A pragmatic deep-dive (2026-09-02) walks through how Mem0 actually works today, correcting out-of-date writeups.

Early versions ran a two-step pipeline: extract candidate facts, then a second LLM pass deciding whether to add, update, or delete. That kept the store tidy (no duplicate/contradictory facts) but doubled the LLM calls per turn and erased history — once “works at Company A” was overwritten by “works at Company B”, the old employer was unrecoverable.

Sometime in early 2026 Mem0 dropped that second pass entirely. What ships now is single-pass extraction that only ever adds: nothing is updated or deleted when a new fact arrives; both versions persist, each timestamped. Deciding which fact is current is deferred to search time, where the engine blends several signals:

• Plain semantic similarity — embedding-based meaning match.
• BM25 keyword pass — keeps exact terms, version numbers, library names from being lost in embedding space.
• Entity linking — boosts anything sharing a name/place with the query; no longer needs a separate graph database.
• Temporal reasoning — attempts to favor whichever fact is more recent when the question is about current state.

This multi-signal retrieval is the same hybrid-retrieval family memory-retrieval-patterns catalogs. The efficiency numbers check out against what Mem0 publishes: roughly 2× faster extraction, background processing down ~90% vs full-context replay, retrieval under ~7k tokens/query.

Implications

Add-only preserves history (the Vault’s COMPOUND invariant mirrors this) but moves all conflict resolution to retrieval. Correctness at query time now depends entirely on whether the ranking signals reliably surface the current fact — which is the fragile part (next section).

Temporal Reasoning Weakness

The recency claim is the shakiest part. Open issue #4956 against the project lays out the expected failure: a user states an employer, states a different one three months later, and a later query about where they work can still surface the older answer, because the ranking signals don’t reliably weight recency the way the pitch implies.

Implications

For any use where the current fact matters — a support agent, a healthcare tool — don’t take the marketing at face value. Test recency on your own data before depending on it.

Benchmark Skepticism

The headline accuracy numbers floating around are self-reported, on each vendor’s own test harness, and outside audits disagree: OpenAI native memory ~53% on LoCoMo, Letta ~74, Zep 80-84 (disputed by Mem0), Mem0 low-90s (self-claimed) — but one independent evaluator scored Mem0 at 49 on a benchmark where Mem0’s own page claims 92. LoCoMo itself sits under a methodology audit.

Implications

The gap between self-reported (low-90s) and independent (~49) is the cautionary signal; the underlying multi-signal approach is probably sound even if headline accuracy claims are overstated. Treat any single number — including a chart row — as marketing copy first, evidence second.

Add-only Growth — No Auto-Expiry

Because nothing is deleted automatically, the store only grows. There is no built-in expiration or decay in Mem0 today (open feature request #5330). A deployment running for a year keeps accumulating stale facts, making retrieval noisier and quietly raising storage/embedding costs. The documented pattern for short-lived facts is storing them with explicit expiry in metadata and cleaning up yourself:

expiration = (datetime.now() + timedelta(days=14)).strftime("%Y-%m-%d")
memory_engine.add(
    [{"role": "user", "content": "Rolled my ankle, keep workout suggestions light for now"}],
    user_id=user_id,
    metadata={"memory_bucket": "constraints", "expires_on": expiration},
)

Implications

Add-only trades write-time correctness for write-time speed, and the operator owns forgetting. For long-running personal memory this is the “who deletes stale truth” burden memory-lifecycle describes — a live gap between the durability pattern and the shipped product. Contrast with a read-only vector store under plain rag, where contradictory facts pile up with no write-side or search-side resolution mechanism.

Privacy & Sovereignty Ladder

Three levels of data control, each exchanging convenience for sovereignty:

1. Scrub before embedding, no matter what. Background extraction embeds raw unstructured text; names, emails, phone numbers, card numbers become permanent vectors. Post-hoc delete can’t undo it — the vector carries meaning, and logs/caches may already hold the originals. Scrub at the write boundary with reversible tokens (Presidio: <PERSON>, <EMAIL_ADDRESS>, <US_SSN>, <CREDIT_CARD>). Test your entity list against every claimed category — credit-card detection was missing from earlier drafts despite being called out. Presidio also ships IBAN, US bank accounts, driver’s licenses, IPs, UK NHS, Indian Aadhaar.
2. Fully local. Swap OpenAI for Ollama (llama3.1:8b + nomic-embed-text, 768-dim) and point at your own Qdrant; nothing leaves the machine. Tradeoff: local embedders are weaker at semantic retrieval and extract facts less cleanly than text-embedding-3-small/GPT-4o-mini — you give up recall quality for data control.
3. From scratch (~60 lines). SQLite + sqlite-vec + fastembed (BAAI/bge-small-en-v1.5, 384-dim), no Docker, no server. One caveat flagged by the author: sqlite-vec extension loading alongside a SQLCipher encrypted connection is unverified — test that combination or fall back to full-disk encryption.

MCP portability. Wrapping memory in a FastMCP server makes it follow the user across apps (Claude Desktop, Cursor, etc.). Over local stdio the caller-supplied user_id is fine — the hosting app is the trust boundary. Exposed over HTTP, user_id becomes an authentication hole: any client can pass any id and read that person’s full history. Past local stdio, authenticate and derive user_id from the session. Snapshot configs also hold API keys in plaintext (claude_desktop_config.json) — load from the shell environment or keep that file out of version control.

Implications

model-context-protocol buys memory portability across apps, but the local-stdio trust boundary does not survive network exposure. Privacy controls must live at the write boundary (scrub before embed), never retroactively.

Open Questions

• Does search-time temporal reconciliation reliably beat write-time reconciliation for fast-changing facts? Issue #4956 suggests not always.
• If auto-expiry ships (#5330), what decay policy is safe without destroying history?
• Is the self-hosted/local recall gap acceptable for sensitive workloads, and is the sqlite-vec + SQLCipher combination actually safe?

Relationships

• agent-memory-systems — belongs-to: the flagship memory-first implementation
• llm-wiki — contradicts: memory-first vs artifact-first
• cognee — sibling-of: sibling memory engine (Cognee adds explicit graph)
• rightmemory — sibling-of: sibling agent memory substrate

Implications

mem0 is the reference for “memory that persists across sessions” — the memory-first counterpoint to the LLM Wiki’s artifact-first approach. Useful when the user wants agent memory more than a browsable wiki.

External Links

• Repository: https://github.com/mem0ai/mem0

Sources

^[wiki/concepts/resources.md]