How Modern Systems Do It: MemGPT, Mem0, Zep, and the Assistants You Use
Everything so far - types, substrates, read path, write path - is the vocabulary. Now let’s read the real systems with it. Each case study below is a different bet about which part of the memory problem matters most; together they cover the entire design space you’d draw from when building your own.
MemGPT / Letta: memory as an operating system
The bet: the agent itself should manage its own memory, like an OS manages RAM and disk.
MemGPT (2023, later the company Letta) drew the founding analogy of the field. A computer has fast-small RAM and slow-big disk, and the OS pages data between them. An agent has a fast-small context window and slow-big external storage - so give the agent the paging tools.
Concretely, a Letta agent’s context contains editable memory blocks - typically a persona block (who am I, how do I behave) and a human block (what I know about this user) - each with a size limit. The agent has tools to edit its own blocks: when the user mentions moving to Pune, the agent literally calls a tool to rewrite its human block. When something doesn’t fit in-context, it pages out to archival storage (vector-searchable) and pages back on demand with search tools. Blocks = always-loaded core memory (Blog 5’s “profile” + Blog 6’s self-edited instructions); archival = the searchable long tail; and the read/write paths are agent-driven (Blog 8’s “memory as action”) rather than reflexes.
Letta’s second big contribution is sleep-time compute (Blog 9): a background agent that reorganizes and improves the main agent’s memory between sessions - consolidating, resolving contradictions, distilling “learned context.”
Read it as: maximal agent autonomy over memory. Most flexible; depends most on the model’s judgment.
Mem0: memory as a pipeline service
The bet: memory is an infrastructure layer - extraction and consolidation done for the agent, automatically.
Mem0 (the most widely deployed dedicated memory layer) is Blog 9’s pipeline productized. Your app sends each exchange to Mem0; an LLM extracts candidate memories; for each candidate the system recalls similar existing memories and an LLM reconciles - ADD / UPDATE / DELETE / NOOP; results live in a vector store (plus an optional graph variant that also extracts entity-relation triplets for relational queries). At question time, your app retrieves relevant memories and injects them - Blog 8’s automatic read path.
The pitch is economic, and it echoes this series’ core math: against feeding full conversation history, Mem0 reports on the LoCoMo benchmark roughly +26% answer accuracy, ~91% lower p95 latency, and ~90% fewer tokens. Better answers, faster, at a tenth the cost - the workbench argument (Blog 2) with a price tag.
Read it as: memory as a reflex, packaged. The agent doesn’t manage anything; the pipeline does. Easiest to adopt; less agent control.
Zep / Graphiti: memory as a temporal knowledge graph
The bet: the hard problem is time and truth (Blog 5’s truth problem), so build the store around it.
Zep’s engine, Graphiti, ingests conversations and business data into a knowledge graph where every edge (fact) carries four timestamps: when it became true and stopped being true in the world (t_valid, t_invalid), and when the system learned and superseded it. New information that conflicts doesn’t overwrite - it invalidates: the old edge’s interval closes, the new edge opens. “Maya deploys Fridays (Mar→Jul)” and “Maya deploys Tuesdays (Jul→now)” coexist; queries default to current truth, but “as of June?” still answers correctly.
Retrieval is hybrid - semantic + keyword + graph traversal fused - and benchmark results on temporal-reasoning-heavy tests (LongMemEval’s knowledge-update and temporal categories) are where graph-with-time approaches shine hardest.
Read it as: the strongest answer to fact-change, relational questions, and audit-grade history - at the cost of the heaviest machinery (Blog 7’s forklift warning applies).
LangGraph / LangMem: memory as a framework primitive
The bet: don’t impose one design - give builders the primitives. LangGraph (the dominant open agent framework) ships a persistent store (namespaced key-value + vector search: e.g., namespace = user, key = fact-id), plus checkpointing of agent state (working memory that survives restarts - a thread can resume mid-task days later). Its memory library exposes the taxonomy directly - you configure semantic / episodic / procedural managers and choose hot-path or background writing per Blog 9. Read it as: the concepts of this series as Lego bricks; you assemble the actual system.
The consumer assistants: the same anatomy, different trust dials
ChatGPT memory runs an implicit write path: it decides on its own what to save from your chats (a typical active user accumulates roughly 40-80 stored facts) plus explicit “remember this” saves, auto-injected into future chats - Blog 8’s reflex, Blog 9’s hot path, tuned for zero user effort.
Claude memory turns the trust dials the other way: conversations are synthesized on a roughly daily rhythm (a background write path) into a readable, editable memory profile; Claude indicates when a memory is being used; deleting a conversation deletes what was learned from it. Same anatomy - selection, consolidation, injection - but the product bet is legibility: memory you can audit beats memory you can’t.
Claude Code (the agent this series’ author lives in) is a nice full-stack specimen: CLAUDE.md = standing procedural memory (Blog 6); an auto-memory directory of markdown fact-files with an index = file-substrate semantic memory the agent itself reads and writes (Blog 7’s “files” bet); auto-compaction of long sessions = working-memory management (Blog 2); scratchpads and notes = structured note-taking. No vector database at all - proof that the concepts are the requirement, not any particular technology.
Reading the whole table
| System | Core bet | Types emphasized | Substrate | Read path | Write path |
|---|---|---|---|---|---|
| MemGPT/Letta | Agent manages its own memory | All four; self-edited blocks | Blocks + vector archive | Agent-driven | Agent tools + sleep-time |
| Mem0 | Pipeline service | Semantic (+episodic) | Vector (+graph option) | Automatic | Extract→reconcile (hot/background) |
| Zep/Graphiti | Time & truth first | Semantic, temporal | Temporal knowledge graph | Hybrid fused | Ingest→invalidate |
| LangGraph/LangMem | Primitives for builders | Configurable | KV+vector store, checkpoints | Either | Either |
| ChatGPT | Zero-effort personalization | Semantic profile | Managed | Automatic | Implicit hot path |
| Claude | Legible, controllable memory | Semantic profile | Managed | Automatic + cited | Daily background synthesis |
| Claude Code | Files + instructions | Procedural + semantic | Plain files | Agent-driven | Agent-driven + compaction |
Notice what the table really says: nobody skips the fundamentals - every system is some arrangement of selection → consolidation → storage → scoring → injection. They differ in who controls each stage (agent vs pipeline vs user) and which failure they fear most (staleness → Zep; cost → Mem0; opacity → Claude; rigidity → Letta/LangGraph). That’s the real lesson for your own product: choose your fears first, and the architecture follows.
Quick recap
- MemGPT/Letta: OS analogy - self-editing memory blocks, agent-driven paging, sleep-time consolidation.
- Mem0: the extract→reconcile pipeline as a drop-in service; the canonical “90% fewer tokens, better answers” economics.
- Zep/Graphiti: bi-temporal knowledge graph - facts get validity intervals; contradictions invalidate, never erase.
- LangGraph/LangMem: the taxonomy and both paths as configurable framework primitives.
- ChatGPT vs Claude vs Claude Code: same anatomy, opposite trust/control dials - implicit reflex vs legible synthesis vs plain files.
- Every system = the same five stages; architecture follows from which failure you fear most.
Next: squeezing the machine - context engineering and the optimization playbook (compaction, budgets, caching, and the cost math that makes memory profitable).