Zep returns a blob.Statewave returns a receipt.
Zep models memory as a knowledge graph of entities and edges and returns retrieval as an optimized Context Block string. Statewave compiles typed, provenance-traced memories and returns a ranked bundle with explicit metadata per row: kind, confidence, validity, and the source episodes it came from.
A knowledge graph, or a typed-memory runtime
Zep stores memory as a graph: nodes are entities, edges are facts with valid and invalid timestamps, and the graph updates dynamically as new data arrives. Retrieval traverses that graph and returns an optimized Context Block. Statewave records each event as an immutable episode, compiles those into typed memories with confidence and validity, and assembles a ranked bundle the same way on every call.
Retrieval rides on the graph
Traversal and a managed reranker compose a well-shaped Context Block. You get a blob, not per-fact metadata; temporal validity lives on the edges, and the graph updates dynamically as new data lands.
Assembly is deterministic and inspectable
Given the same subject, task, token budget, and point in time, the assembler returns the identical bundle every run. Five signals set the order: kind priority, recency, task relevance, temporal validity, and semantic similarity.
Where each capability lives
Both give agents durable memory. They diverge on the shape of what comes back: a graph traversal's Context Block, or a ranked bundle of typed rows, and on what you can inspect once it has.
What comes back
- z
- An optimized Context Block: one string
- S
- A ranked bundle of typed rows with per-memory metadata
How context is selected
- z
- Graph traversal plus a managed reranker
- S
- Deterministic assembly, ranked to a token budget
Custom domain modelling
- z
- First-class entity and edge types (Pydantic-like)
- S
- Free-form metadata JSONB; typing carried in your app
Same query, same result
- z
- Not advertised; traversal and reranker can drift
- S
- Byte-identical bundle every run
Token-bounded output
- z
- Context Block size shaped by Zep
- S
- Explicit max_tokens; bundle reports token_estimate
Inspectable retrieval
- z
- Opaque string; no per-fact metadata in the response
- S
- Explicit kind, confidence, valid_from/to per row
Provenance
- z
- Edge timestamps for lineage; node history in the graph
- S
- source_episode_ids per memory; immutable episode chain
Temporal validity
- z
- Per relationship: edge valid_at / invalid_at
- S
- Per memory: valid_from / valid_to windows
Subject deletion (GDPR)
- z
- Remove nodes and edges from the graph
- S
- One call hard-deletes a subject’s episodes and memories
Memory model
- z
- Knowledge graph: nodes plus edges (Graphiti-based)
- S
- Typed memories (4 kinds) plus immutable episodes
Storage
- z
- Managed graph database under the hood; nothing to run
- S
- Postgres and pgvector; no proprietary store
Deployment
- z
- Cloud, BYOK, or BYOC; Community Edition discontinued 2025, repo stays Apache 2.0 unsupported
- S
- Self-hosted only
Best for
- z
- Graph-shaped reasoning and explicit entity modelling
- S
- Eval-driven, inspectable retrieval on a single Postgres
Zep is a Graph RAG memory product built on Graphiti, its open-source temporal-graph engine: nodes are entities, edges are facts with valid/invalid timestamps, and the graph updates dynamically in response to new data. Zep discontinued its self-hosted Community Edition in 2025. Cloud, BYOK, and Bring-Your-Own-Cloud are the only deployment options today. Rows reflect Zep's public docs as of August 2026.
Your domain has entities and explicit relationships the agent should reason about: "what connects Alice to BluePeak?" is a graph question. You want temporal validity on relationships for free, prefer defining custom entity types, and are fine running entirely as a managed cloud or BYOC service. Zep has no supported self-hosted edition.
Inspectable retrieval matters, determinism is part of the contract, and a single-Postgres, self-hosted footprint is operationally simpler than adopting a managed graph service. Most support, coding, and sales agents need "what did this user say, what's their plan, what's open": typed-fact retrieval covers that and skips the graph tax.
"Why did the agent say that?"
An agent resumes a returning customer and states a fact about them. Later, someone asks where that fact came from. The same history runs through each system: one returns a blob, the other a finite provenance chain.
Every call can leave a receipt
Zep tracks lineage as timestamps on graph edges and returns retrieval as an opaque Context Block. In Statewave assembly is governed on the read path and can emit an immutable receipt, with per-memory provenance back to the source episode, in the core, under Apache 2.0.
The same query returns the same bundle
Statewave is evaluated on two long-horizon memory benchmarks, and the scores are fixed: no model and no reranker sit on the read path, so the same subject, task, and budget return the same bytes every run. Zep publishes no number produced under the same conditions: graph traversal with a managed reranker composes the Context Block, and Zep's own docs describe the graph updating dynamically as new data arrives.
Zep doesn't advertise determinism: graph traversal and reranker behaviour are part of the managed retrieval, and the graph updates dynamically in response to new data. The same query can compose a different Context Block as index state shifts. help.getzep.com/concepts
Illustrative: Zep publishes no per-run determinism guarantee. Statewave's compile-time scoring and ranked-pack assembly return a byte-identical bundle for the same (subject, task, budget).
Moving from Zep to Statewave
The conceptual translation is straightforward, but the data shapes differ. Plan a parallel-run period: the cutover is typically read-then-write rather than a flag flip.
Relational facts that explicitly link two entities ("Alice works at Acme") don't survive directly: encode them in the subject's memory content, write to both subjects, or keep relationships in your own graph layer and use Statewave for episode and memory storage.
Frequently asked
How is Statewave different from Zep?
Zep is a Graph RAG product: it models memory as a knowledge graph of entities and edges and returns retrieval as an optimized Context Block string. Statewave compiles raw episodes into typed memories with confidence and validity, ranks them with a fixed scoring model to a token budget, and returns a structured bundle: per-row kind, confidence, validity, and source episode ids, with no graph to traverse.
Can I still do graph reasoning?
Not natively. Statewave has no graph-traversal surface, so "find everything Alice is connected to within two hops" isn’t its shape. If your domain needs entity-relationship reasoning, keep that in Zep or your own data layer, and use Statewave for episode and typed-memory storage.
What happens to relational facts like "Alice works at Acme"?
Facts about a single subject migrate cleanly. Relational facts that link two entities don’t survive directly. You encode the relationship in the subject’s memory content, write the memory to both subjects with cross-references, or keep the relationship in your application’s graph.
What makes retrieval deterministic?
The bundle is compiled and assembled the same way every run: four ranking signals (kind priority, recency, task relevance, and temporal validity) combined to a fixed token budget. The same subject, task, and point in time produce the same bytes. Graph traversal with a reranker can’t promise that, because index state and reranker variation introduce drift.
Do I have to run a graph database?
No. Storage is Postgres plus pgvector and nothing else, usually already in your stack. There is no separate graph store to operate, back up, or scale.
Does Zep offer a self-hosted option?
No. Zep discontinued its self-hosted Community Edition in 2025 and now concentrates its open-source work on Graphiti, the temporal-graph engine underneath; the memory API this page compares (thread.get_user_context, graph.search) is only available through Zep Cloud, BYOK, or Bring-Your-Own-Cloud. Statewave runs the whole stack, Postgres included, on your own infrastructure, with no cloud dependency and no usage credits to meter.
Does it work with Claude, Cursor, or Codex?
Yes. One command (npx @statewavedev/statewave) boots the runtime, and its shipped MCP server connects any MCP-compatible client: Claude, Cursor, Copilot, and agent runtimes. Zep is cloud-only; Statewave runs entirely on your own infrastructure.
Give your agent context it can prove
Self-host the Apache 2.0 runtime, wire it to your MCP client, and every context call can return a receipt.