Skip to content

Memory Architectures in Production

Two memory products, Mem0 and Zep, publish competing benchmark scores on the same public test (LoCoMo, a standard test set for how well a memory system answers questions about long past conversations). Mem0's own paper reports 66.88% accuracy for itself. Zep publicly disputed how Mem0 had configured Zep in that same test, published a rebuttal titled "Lies, Damn Lies & Statistics," and posted a corrected score for itself of 75.14% — higher than Mem0's own number. Neither side is lying exactly; they disagree about whose test setup was fair. The lesson here isn't which number to trust. It's that a single leaderboard score was never a sound way to choose between them in the first place, because Mem0 and Zep aren't even competing at the same job.

Before you start

Prerequisite: Lesson 21, "File-based and reflexive memory, shared memory for multi-agent systems, and the CRUD++ operations" — you should know the nine CRUD++ operations and have seen hybrid retrieval beat naive vector search on a real query set. After this lesson, you can: place any memory framework you encounter into one of three architectural archetypes, and explain why a benchmark leaderboard position is not sufficient grounds to pick between them.

There are dozens of memory frameworks with GitHub stars and product pages — Letta, Mem0, Zep, and others less widely known. Rod Rivera's own read, after reviewing production systems across this field: underneath the marketing, there are three architectural patterns. Everything else is a variant or specialization of one of these three, and knowing which one you're actually looking at is what turns a framework-shopping exercise into an engineering decision.

The three archetypes

ArchetypeReference implementationCore idea
Hierarchical / OS-styleLetta (formerly MemGPT)LLM as CPU, context as RAM, vector store as disk — tiers with explicit promotion
Extract-store-retrieve layerMem0Framework-agnostic library: an LLM extracts facts, stores them, retrieves on demand
Temporal knowledge graphZep / GraphitiEntities plus relations plus bi-temporal validity — "what was true when?"

Pick the archetype that matches the problem, not the framework with the best landing page.

Letta: treat the LLM like an operating system

Letta traces to the MemGPT paper (Packer et al., October 2023, arXiv:2310.08560), rebranded to Letta in May 2025 — "MemGPT" now names the research architecture, "Letta" the company and platform. The OS metaphor runs deep: the LLM is the CPU, the context window is RAM, a vector store or database is disk, tool calls are syscalls, memory-tier promotion is virtual-memory paging, and sleep-time agents are daemon processes.

Three tiers, and the agent moves data between them itself via tool calls:

CONTEXT WINDOW (always visible) system prompt, core memory blocks (persona, human), recent messages | tools RECALL MEMORY (searchable conversation history) conversation_search(query) -> top-k messages | tools ARCHIVAL MEMORY (long-term facts) archival_memory_insert(text) / archival_memory_search(query) -> top-k facts

The most interesting recent addition is Sleep-Time Compute (April 2025): a second background agent shares memory blocks with the primary agent, runs every N steps (default 5), and consolidates conversation into denser, less noisy memory — moving expensive reasoning off the critical path into idle time. Reported results: roughly a 5x reduction in live token budget, with same-or-better accuracy on AIME and GSM benchmarks. Claude Code shipped essentially the same pattern in Q1 2026 as "Auto Dream" — a background sub-agent that consolidates /memories during downtime. Same idea, different vendor.

Letta's strengths are real: the most mature memory-first framework, a genuine production story, a clean memory-block abstraction, and model-agnostic tool-calling. Its weaknesses are structural, not incidental: Letta is a full agent runtime, not a memory library — adopting it means rebuilding your app inside Letta, not adding a dependency. Every memory operation costs inference tokens, because the agent has to reason about what to store. And the LLM-OS metaphor leaks exactly where lesson 20 flagged it would: in a real OS the kernel is privileged, but in an LLM-OS the "kernel" reasoning about memory promotion runs in the same probabilistic stream as the untrusted "userland" — which is the memory-injection attack surface lesson 26 exploits directly. Use Letta for an all-in-one agent platform; avoid it if the goal is a memory layer bolted onto an existing stack.

Mem0: memory as a library, not a runtime

Mem0 (Chhikara et al., "Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory," April 2025, arXiv:2504.19413) takes the opposite bet from Letta: a framework-agnostic memory layer. Nothing gets rebuilt — memory.add() and memory.search() get called from LangChain, CrewAI, AutoGen, or a hand-rolled loop, and Mem0 handles fact extraction, dedup, and contradiction handling behind those two calls.

EXTRACTION PHASE UPDATE PHASE (user_msg, asst_msg) For each candidate fact: + summary + last 10 msgs - retrieve top-10 similar | - LLM decides: LLM extractor ADD / UPDATE / DELETE / NOOP | Atomic candidate facts

The paper's own LoCoMo benchmark numbers: Mem0 at 66.88% LLM-as-judge accuracy, 0.15s p95 search, 1.44s p95 end-to-end, and roughly 1,764 tokens per conversation, against a full-context baseline that scores higher on accuracy (72.90%) but costs vastly more — 17.12s end-to-end and roughly 26,000 tokens. Reported: a 26% improvement over OpenAI's own memory feature, 91% lower p95 latency than full-context, and 90%-plus token savings.

This is the dispute from the top of this lesson: the Zep team publicly disputed this benchmark, claiming their system was misconfigured in Mem0's test setup, and published a corrected Zep LoCoMo score of 75.14% — higher than Mem0's reported number here. Benchmark wars in this space are real, ongoing, and often won by whoever ran the last correction. Don't cite a single number as gospel; cite the archetype fit instead.

Mem0's genuine strengths: framework-agnostic, passive extraction that doesn't compete with the agent for inference tokens, a contradiction-handling DELETE path that actually works, and a graph variant (Mem0ᵍ) when relational reasoning is needed. Its weaknesses: extraction is opinionated with limited control over what gets kept, a flat fact list can miss nuance a hierarchical or graph structure would capture, and the extractor LLM is a single point of failure. Use Mem0 when the goal is adding memory to an existing agent without rewriting it.

Zep and Graphiti: time as a first-class citizen

Zep's architecture ("Zep: A Temporal Knowledge Graph Architecture for Agent Memory," Rasmussen et al., January 2025, arXiv:2501.13956) builds a temporal knowledge graph tracking not just facts but when those facts were true — the bi-temporal model lesson 19 introduced as a memory type, here evaluated as a shipped product. Every edge in Graphiti (the open-source core) carries the same four timestamps: t_created, t_expired, t_valid, t_invalid.

Three subgraphs do the work: an Episode subgraph holds raw events with original timestamps, an Entity subgraph (built via LLM extraction) holds deduplicated entities and temporally-scoped relationships, and a Community subgraph clusters related entities with summaries. Retrieval combines three modes — cosine similarity over BGE-m3 embeddings, BM25 full-text over Neo4j Lucene, and BFS graph traversal from seed nodes — reranked and assembled into a context string, with a reported P95 retrieval latency of roughly 300ms.

Zep earns its place for CRM and customer intelligence ("what did the customer prefer in February?"), legal and compliance use cases where every fact needs provenance and a validity window, long-running B2B agents whose customer state evolves, and multi-entity reasoning that genuinely needs a graph. Its cost is real: LLM calls extract entities and relations for every episode, making it expensive at ingestion; retrieval can lag until background graph processing completes; and it requires a graph database — Neo4j or similar — which is meaningfully more infrastructure than files or a vector table.

text
Archetype: hierarchical OS
Storage: tiers (core/recall/archival)
Update: agent-driven via tools
Best for: all-in-one agents, companions
Weight: heavy (full runtime)

Everything else worth knowing about — A-MEM's Zettelkasten-style linking, Cognee's ontology-driven graphs, LangMem's tight LangGraph integration, MemMachine's benchmark-leading scores as of March 2026, Memori's SQL-native ACID model, Supermemory's traceable atomic memories — is a variant or specialization of one of these three archetypes. The rule stands regardless of which honorable mention shows up next: pick one of the big three, or roll your own from files and vectors, and ship.

The Anthropic bet: the opposite of "more frameworks"

While most of the field spent 2024 and 2025 building more sophisticated memory frameworks, Anthropic shipped a memory tool that does almost nothing — a client-side filesystem, full spec unchanged from lesson 20: shipped September 29, 2025, beta header context-management-2025-06-27, tool type memory_20250818, six operations (view, create, str_replace, insert, delete, rename), default /memories directory convention. Client-side means the operator controls where and how memories are stored; Anthropic stores nothing. Move the agent to a new host and the memory comes with it — inspect it with cat, version it with git, diff it, delete it, no vendor lock-in.

Anthropic shipped context editing alongside the memory tool in the same release: the clear_tool_uses_20250919 strategy removes the oldest tool results in chronological order once input tokens cross a trigger value, and the two features are designed to work together — when context is about to be cleared, the model is warned so it can save anything important to /memories first. Anthropic's own reported numbers: a 39% improvement on agentic search tasks and an 84% token reduction on 100-turn web-search evaluations when both features run together — self-reported, worth validating against a real workload before repeating as fact.

Three archetypes, one filesystem bet underneath all of them

Why PyNanoClaw goes file-first

The choice for PyNanoClaw is not Letta, not Mem0 as the memory layer, not Zep for temporal facts. It's file-first, with an optional vector store for scale — closer to Anthropic's bet than to any of the big three. Five reasons, stated plainly rather than hedged: files are pedagogically clear, because a student can cat the memory and see exactly what the agent knows, where a vector DB requires writing a query just to debug. The pattern aligns with Karpathy's claws framing and NanoClaw's own conventions — inheriting CLAUDE.md makes the lineage visible rather than invented from scratch. It's cheap: no infrastructure, runs on a Mac Mini in /tmp for the labs. It's provider-agnostic: files don't care which LLM is doing the reasoning, so Nebius swaps for Anthropic or Together with zero refactor of memory code. And it's future-extensible: when files are outgrown, a vector store gets added next to them, with the file layer staying the source of truth and the vector store becoming an index over it.

Quick check — A team picks Zep over Mem0 because Zep's corrected LoCoMo score (75.14%) beats Mem0's self-reported number (66.88%). What does this lesson say is wrong with that reasoning?

What to carry into the next lesson

Three archetypes, one filesystem bet running underneath the field's actual convergence — and every one of them, at some point, needs an embedding model. The next lesson answers the question this course has been deferring since Type 5's associative-memory code: which embedding model, and why, and does it have to match the generation model at all.

Continue to Lesson 23

Why embedding and generation model choice are two separate decisions, the five questions that actually matter when picking an embedder, and Anthropic's Contextual Retrieval result in full.

Have a question about this lesson?

Reply here and it goes straight to Rod. Same as replying to one of his emails.