COMPARISON
causal-memory vs Zep
Zep models how facts change over time. causal-memory models how decisions cause outcomes — including the outcomes they prevented.
Updated · English
The short version
Zep approaches memory from the temporal side. Its Graphiti engine keeps entities and relationships in a knowledge graph where edges carry validity windows, so the system can answer 'what was true in March?' instead of flattening every fact into one undated blob. That is a real problem, solved properly, and it is a different problem from the one this project attacks.
causal-memory also stores temporal validity on edges — C5 temporal-causal is 90% on CausalEval — but the unit it is built around is the decision. A decision, the context it was made in, and its outcome become a typed edge. The graph then supports backward attribution, forward intervention simulation, and inhibitory spread for the approaches that made things worse.
The distinction is easiest to see in a postmortem. A temporal graph can tell you which service configuration was valid at 02:14. A causal graph can tell you that the configuration was changed because the previous one caused a timeout, and that the rollback is what prevented a full outage. Both are useful; only one of them warns you before the next deploy.
Zep is a service with a graph database behind it. causal-memory is a single binary over SQLite. That difference in operational weight matters more than any feature row for a small team.
One number belongs on every comparison page even when it is not about the competitor: on fact recall causal-memory trails mem0, 79.1% against 91.6% on LoCoMo with a strict judge. Zep has not been measured on that suite by us, and this page does not guess a score for it.
causal-memory vs Zep, capability by capability
The last block of this table is deliberate: it lists the places where causal-memory is the weaker choice. A comparison page that only has winning rows is an advertisement.
| Capability | causal-memory | Zep |
|---|---|---|
| Unit of memory | Decision → context → outcome causal edges, plus facts and temporal state | Entities and relationships in a temporal knowledge graph (Graphiti) |
| Time model | valid_from / valid_to on edges; temporal-causal ordering scores 90% on CausalEval | Bi-temporal edge invalidation is the core of the product and is more mature than ours |
| Causal semantics | Typed caused / enabled / prevented / no_effect with fixed spread coefficients | Relationship types are general-purpose; there is no built-in inhibited or prevented semantics |
| Pre-action check | intervention_query returns a ranked forward chain before the action | Graph retrieval answers questions about the stored past; no forward-simulation endpoint |
| Inhibition | prevented spreads −0.3 so failed approaches rank below neutral | No negative activation coefficient; ranking is relevance-based |
| Belief revision | Soft superseded_by keeps the falsified edge readable for counterfactuals | Edge invalidation preserves history, which suits facts that change over time |
| Operational footprint | One binary and one SQLite file; nothing else to run | Graphiti service plus a graph database; a managed offering removes that burden |
| Local-first | Yes — offline by default, optional local ONNX embeddings | Service-oriented architecture; cloud is the expected deployment |
| CausalEval numbers | C2 75%, C4 80%, C7 100% (140q protocol, v13) | Zep was not run on CausalEval, so this page publishes no Zep score |
| Fact recall (LoCoMo, strict judge) | 79.1% | Not measured for Zep; mem0 leads at 91.6% |
| Where causal-memory is weaker — read this before the pitch | ||
| Temporal query maturity | Validity windows exist, but bi-temporal invalidation is younger and less battle-tested | Bi-temporal modelling is the product's core and its most mature surface |
| Entity resolution at scale | SimHash pattern separation plus graph traversal; not a dedicated ER pipeline | Built for entity-heavy graphs with resolution as a first-class concern |
| Managed service | Hosted memory is early; self-hosting is the documented path | Managed cloud with the graph operations handled for you |
| Graph tooling and ecosystem | No graph UI; inspect through MCP tool output and SQLite | A graph engine ecosystem with its own tooling |
| Benchmark coverage | No published head-to-head against Zep on CausalEval | Also not measured by us — an absence of evidence on both sides |
| Distributed deployment | Single-node SQLite; multi-tenant HTTP runs one store per tenant | Service architecture designed to be deployed and scaled as infrastructure |
When to choose each one
Choose Zep when
- Your hardest questions are temporal: what was true at a given time, and which fact invalidated which.
- You want a managed graph service and do not want to run stateful infrastructure yourself.
- Your domain is entity-heavy — customers, accounts, contracts — with relationships that change independently of decisions.
- You need a graph database behind memory for existing analytics or tooling.
Choose causal-memory when
- Your agents make operational decisions whose outcomes you need to compare later.
- You need to know what prevented an incident, not only what happened during it.
- You want a pre-action warning before a risky command, not a post-hoc query.
- You want local-first memory with no graph database to operate.
The numbers, with their provenance
Source: causal-memory README v0.10.0 · CausalEval v13, read 2026-10-21. The baseline column is the mem0 run on the same 70-question protocol; we did not run this system on CausalEval and do not publish a score for it.
| Capability | causal-memory | mem0 (70q baseline) | What it tests |
|---|---|---|---|
| C7 Update | 100% | 80% | Supersede an old belief after it is falsified, and keep the old edge retrievable |
| C3 Counterfactual | 95% | 80% | Choose between alternatives with known outcomes |
| C2 Intervention | 75% | 40% | Forward prediction: if X happens again, what follows? |
| C4 Inhibition | 80% | 50% | Separate the root-cause fix from the blast-radius limiter |
| C1 Attribution | 85% | 90% | Walk a backward causal chain to the root cause |
| C5 Temporal-causal | 90% | 90% | Order events on a causal chain |
| C6 Lesson transfer | 20% | 30% | Cross-task analogy through meta edges — still an open limitation |
| Overall | 78% | 65% | All C1-C7 classes weighted equally |
The same table appears on every comparison page, with the same baseline, so the numbers cannot drift between pages. For the fact-recall suites where mem0 leads, see the mem0 comparison.
What the difference looks like in practice
Zep is the stronger choice for temporal fact graphs and for teams that want managed graph infrastructure. causal-memory is the stronger choice when the memory has to explain decisions and stop the agent from repeating a bad one. A team can reasonably use Zep for entity facts and causal-memory for the decision journal; they answer different questions and neither replaces the other.
- Both systems can be mounted at once. Nothing in causal-memory requires you to remove an existing memory layer.
- The comparison is about the stored object, not about which project is better engineered.
- Every claim about the competitor on this page is either a public product fact or a row from the causal-memory README differentiation table.
Zep questions, answered plainly
- Zep vs causal-memory in one sentence?
- Zep remembers what was true and when; causal-memory remembers what was decided, what happened, and what prevented a worse outcome. Temporal graph versus causal graph.
- Does causal-memory have temporal validity?
- Yes. Edges carry valid_from and valid_to, and temporal-causal ordering is one of the CausalEval classes (C5, 90%). It is not as mature as Zep's bi-temporal model, and the comparison table says so rather than hiding it.
- Can I use both?
- Yes. Entity facts belong in a temporal graph; decision edges belong in causal-memory. The two stores do not share state, so there is no consistency problem to solve — only two queries to route.
- Why are there no Zep numbers on this page?
- Because we did not run Zep on CausalEval. The published baseline is mem0 on the 70-question protocol. Inventing a competitor score would make every other number on this site untrustworthy, so the cell says 'not measured' instead.
- Which one is easier to self-host?
- causal-memory: one binary and one SQLite file, started over stdio or HTTP. Zep's graph architecture expects a service and a graph database, which is a reasonable cost if you need what that architecture provides.
Related
Use case
- Causal memory for an on-call agentAn incident timeline records what happened. Causal memory records which mitigation actually prevented the worse outcome — and which one only looked like it did.
- Causal memory for a trading research agentA P&L number tells you what happened. A causal decision journal tells you which part of your reasoning was wrong — and what you would have gotten if you had done the other thing.
Integration
- causal-memory with Claude CodeClaude Code already reads your repository. Give it the one thing a repository cannot store: why a decision was made, and what it prevented.
- causal-memory with DeepSeek HarnessA native plugin rather than an MCP bridge: 17 tools with clean names, plus a system-prompt section that makes the agent check memory before it acts.
Try causal-memory next to Zep
It installs as an MCP server, stores everything in one SQLite file, and does not require you to remove whatever you already use for facts.