Genesys vs Letta
Letta (formerly MemGPT) is a full platform for stateful agents, with OS-inspired tiered memory the agent manages itself. Genesys is a memory engine you drop under any agent over MCP, with an engine-managed causal graph. They sit at different layers of the stack — this is the honest comparison: what each is, how they differ, and the benchmark numbers under one frozen protocol.
Steelmanned.
Letta is the research-grade agent platform that came out of the MemGPT paper, and it is arguably the most conceptuallyinfluential system in this space. Its founding idea — treat the LLM context window like an operating system's RAM and page memory in and out — reframed agent memory for a lot of people. Letta ships an OS-inspired tiered memory architecture:
Crucially, Letta is not just a memory layer — it's a platform for stateful agents. It's open source (Apache-2.0), runs fully local with no account and with local models, and offers an SDK plus managed cloud. If you're building agents that learn and self-improve over time and you want memory management, tool use, and agent state in one runtime, Letta is a first-class choice — and a genuinely different product category from a drop-in memory API.
Agent-managed tiers vs. an engine-managed causal graph.
| Letta | Genesys | |
|---|---|---|
| Product type | Full stateful-agent platform / runtime | Memory engine + MCP server (drop into any agent) |
| Memory model | Tiered: core (in-context) / archival (vector) / recall (history) | One causal graph per user; layers are status tags on nodes |
| Who manages memory | The agent edits core memory and decides what to page | The engine scores, consolidates, ages, and prunes automatically |
| Relationships | Facts in archival vector store; agent-authored | Typed causal edges: caused_by, supersedes, context |
| Update model | Agent rewrites core memory / appends archival | memory_amend supersedes; old node kept, decays, is demoted |
| Forgetting | Paging / context management by the agent | Conjunctive prune: decay-score < 0.01 and orphaned and unpinned and not core |
| Explainability | Agent's memory edits are visible in its trace | memory_explain returns causal chain + live per-force score; memory_traverse returns edges |
The cleanest way to state the difference: Letta makes the agent responsible for memory; Genesys makes the engine responsible for it.In Letta, an LLM decides what to promote to core memory, what to archive, and what to recall — powerful and flexible, but the quality of memory management is the quality of the agent's own decisions, and those decisions cost tokens and vary. In Genesys, a deterministic scoring formula (relevance × causal connectivity × reactivation frequency) and a status FSM decide what stays alive, independent of any single model's judgment on a given turn. Letta's memory is agent-authored and legible in the trace; Genesys's memory is engine-scored and legible in the graph.
They also sit at different layers of the stack, which matters for adoption. Letta wants to be your agent runtime. Genesys wants to be the memory underneath whatever runtime you already use — it speaks MCP, so it can be the memory for a Letta agent, a Claude session, or a ChatGPT one. These aren't strictly either/or.
Same yardstick, both numbers.
Genesys scores 85.55 ± 0.37 — the mean of ten independent full runs under a frozen gpt-4o-mini answerer and judge at temperature 0 (n=1,540, LoCoMo categories 1–4; evaluated July 2026). The protocol is frozen and identical for every scored system: the answerer and judge are both gpt-4o-mini at temperature 0, over n = 1,540 questions in categories 1–4. The per-run figures and the exact quotable claim are on the LoCoMo benchmark page; the full method — frozen protocol, failure ledger, and measured ceiling — is the methodology dossier.
Letta has published a LoCoMo number — and we exclude it here for the same reason we exclude every vendor self-report. In August 2025, Letta reported 74.0%on LoCoMo using a filesystem-based agent on gpt-4o-mini (their “Is a Filesystem All You Need?” post). That run's judge and answer-verification setup is not specified against our frozen protocol, and it was scored by Letta, not by us — so it stays here in prose with its provenance, not in the comparison table. The same rule keeps Mem0's 92.5 self-report out of that table. Symmetric exclusion is the whole point: the table below contains only numbers produced under one identical, frozen configuration.
| System | LoCoMo J (frozen protocol) |
|---|---|
| Mem0 — published, comparable | 66.9 |
| Zep — corrected, comparable | 75.14 |
| Genesys — certified, 10-run mean | 85.55 ± 0.37 |
Comparability note.The table holds only systems scored under one identical, frozen configuration — same dataset, same J-score metric, same answerer and judge. Letta's 74.0 and Mem0's 92.5 are vendor self-reports under unspecified or different setups, so they stay in prose with their provenance rather than in the table. If Letta's 74.0 is re-run under this exact frozen configuration — or Letta publishes one that is — we'll add it to the table verbatim.
Worth stating plainly: a memory-recall benchmark under-measures the thing Letta is best at — end-to-end stateful agent behaviour— so even a fully comparable number would be a partial view of Letta's value.
Which one fits.
These aren't strictly either/or — Genesys can be the memory under a Letta agent. But if you have to choose a starting point, the split is clean.
- You want a full stateful-agent runtime, not just a memory layer — agent state, tool use, and self-editing memory in one platform.
- You believe the agent should manage its own memory (OS-style paging, self-editing core memory) and you want that flexibility over a fixed engine policy.
- You value the research lineage and openness: Apache-2.0, runs fully local with local models, no account required to start.
- You're building agents meant to learn and self-improve over long horizons, where memory management is inseparable from the agent loop.
- Your cost model fits Letta's: free local / self-host, Pro $20/mo (up to 20 stateful agents), or the API plan ($20/mo base + $0.10 per active agent + usage).
- You want memory as infrastructure, not an agent framework — Genesys drops in under any runtime over MCP, including a Letta agent, instead of asking you to adopt a new agent platform.
- Causal recall matters: you need to traverse why a memory exists and what it superseded — memory_explain returns the chain and a live score — rather than reconstructing it from an agent's edit trace.
- You want deterministic, engine-managed lifecycle: consolidation, dormancy, reactivation, and conjunctive forgetting decided by a scoring formula you can audit, not by an LLM's per-turn judgment.
- Explainability matters at the memory layer: every recall carries an inspectable activation; every prune obeys a rule you can check.
- You want one portable, user-owned graph across ChatGPT, Claude, and any MCP client — inspectable and theirs.
- You want a certified recall number: 85.55 ± 0.37 under a frozen protocol with an open harness you can run yourself.
Where these facts came from.
genesys.astrixlabs.ai/benchmarks/locomo.Related.
LoCoMo results
The number and how to cite it, with the comparability caveats spelled out.
What is an AI memory layer?
Vector stores, temporal knowledge graphs, and causal graphs — and the honest tradeoffs.
How we measure
The frozen protocol, the failure ledger, and the measured ceiling — the full dossier.
Genesys overview
An engine-managed causal-graph memory you drop under any agent over MCP.