zep vs graphiti: temporal memory for AI agents — which one fits your stack?

The short answer: Both tools are from the same team (getzep), and both deal with the same hard problem — temporal knowledge graphs for AI agents (every fact has a "when asserted" and "when invalidated" timestamp). The difference is shape: zep is a ready-to-run server you boot with docker compose up and call via HTTP or Python SDK. graphiti is a Python library you embed directly in your own codebase, backed by Neo4j. Pick zep if you want a memory service with less code; pick graphiti if you're building a product on top of graph memory and want library-level control.

---

At a glance

| | zep | graphiti | |---|---|---| | Shape | Server (Docker) | Python library | | Primary use | Managed memory service for agents | Build-your-own graph memory | | Backend | Postgres + bundled vector/graph | Neo4j | | Interface | HTTP API, Python SDK | Python imports | | Install time | ~15 min (Docker) | ~30 min (including Neo4j) | | Best when | You want memory behind an API | You're building a product with graph-first architecture | | License | Apache-2.0 | Apache-2.0 | | Install guide | /memory/tools/zep | /memory/tools/graphiti |

What "temporal knowledge graph" means (and why it matters)

Most memory systems treat every fact as eternally true. "Amara is the CX lead." That's correct today; it might be false next quarter.

Temporal knowledge graphs bake time into the schema. Every edge has:

• asserted_at — when this became true
• invalidated_at — when this stopped being true (nullable)

So when your agent asks "who's the CX lead?", it can answer with who held the role as of the date of the question, not who holds it today. And when an auditor asks "what protocol was in effect on 2026-02-14?", you have the real answer, not a best guess.

This is the feature both zep and graphiti are built around. It's unusual and genuinely valuable in three domains: compliance-sensitive industries (healthcare, finance, aerospace), relationship-heavy work (agencies, VCs, sales orgs), and long-running agents where the world changes faster than the agent's beliefs.

When to pick zep

Pick zep if:

• You want memory as a service — spin it up, point your agent at it, move on.
• You're running agents in production and want the boring, reliable path.
• Your team writes Python, but you don't want to maintain graph database infrastructure or write custom ingestion pipelines.
• You need memory accessible across multiple surfaces (web app, CLI, customer agent) via an HTTP API.
• Audit trail matters, but you don't need to customize how the graph is stored.

zep is the "set it up once, stop thinking about it" option. Most production teams should pick this.

When to pick graphiti

Pick graphiti if:

• Your product is the graph — you're building a system where the knowledge model is the core differentiator, not an afterthought.
• You want direct control over ingestion, schema, and retrieval logic.
• You already run Neo4j (or are committed to running it).
• You want to inspect and query the graph with Cypher (Neo4j's query language) during development.
• You're comfortable writing Python code that directly orchestrates ingestion and retrieval.

graphiti is the right tool when you need library-level flexibility. It's what you reach for if you're the one building a product that might eventually look like zep for a specific vertical.

What's the same

• Both come from the getzep team. The core temporal graph philosophy is identical.
• Both handle the "every fact has a lifetime" model natively.
• Both work with any LLM (OpenAI default, but swappable).
• Both pair with Cognition CLO on top — CLO doesn't care which temporal graph is under it.

What's different in practice

Latency: zep's bundled setup has slightly higher end-to-end latency for ingestion (it goes through an HTTP boundary). graphiti can be faster because it's in-process, but that advantage disappears once your Neo4j is on a different machine.

Visibility: graphiti + Neo4j Browser gives you a visual UI to explore the graph during development. zep's admin UI is less mature but sufficient for production monitoring.

Swapping the backend: You can swap graphiti's backend from Neo4j to other graph stores (community plugins exist). zep is more opinionated — Postgres is the default and that's what it's tuned for.

A practical recommendation

If you're at a fork and you don't already have a strong preference:

• Just want temporal memory working? → zep
• Building a product where the memory model is the product? → graphiti
• Just experimenting? → Don't start with either. Use memory-mcp or mem0 first. Reach for temporal graphs once you've hit the "my agent thinks something false because it's working from stale facts" problem.

FAQ

Can I migrate from zep to graphiti or vice versa?

In theory, yes — both expose their data models — but in practice it's work. If you know you want graph-first, pick graphiti from day one. If you want memory-as-a-service, pick zep and stick with it.

Does this replace zep's cloud product?

zep is also offered as a managed cloud service. If you don't want to run Docker, that's the easiest path. For most indie teams, self-hosting is fine.

What's the Neo4j cost story for graphiti?

Neo4j has a free Community edition that runs great on a $10/mo VPS for small-to-mid use cases. You only need Enterprise if you have serious scale or specific compliance features. The graphiti docs walk you through Community setup.

Do these work with Claude Code via MCP?

Both have MCP bridges (community or first-party, depending on the week). Check the repos. In the meantime, both are callable from any Python code that your agent runs as a tool.

What if I want markdown-legible memory instead of a graph?

Neither is right for you. Look at gbrain or obsidian-mcp-tools — those keep memory as human-readable Markdown.

---

Full install guides: zep · graphiti.