Graphiti Explained: What Zep's Temporal Knowledge Graph Does, and When You Need More
How Graphiti builds a temporal knowledge graph, what running it actually costs, and the line where teams outgrow a self-operated library.
TL;DR
Sentra, the organizational memory layer, publishes this because Graphiti is the open-source library most teams evaluate first and the comparison is usually made badly. Graphiti, built by Zep, constructs a temporal knowledge graph from conversations and events so an agent can query entities, relationships and how facts changed over time. It is genuinely good, Apache-licensed, and at roughly 30,000 GitHub stars the most adopted library of its kind. What you get is a framework you operate yourself, scoped to what you feed it. This guide covers how it works, what running it actually costs you, and the specific line where teams outgrow a library.
What is Graphiti?
Graphiti is an open-source Python framework for building temporally-aware knowledge graphs for AI agents. Rather than chunking documents into a vector store, it extracts entities and relationships from what you send it and records when each fact was valid, so queries can ask what was true at a point in time rather than only what resembles the question.
The mechanics that matter:
1. Episodic ingestion. You pass in episodes: chat messages, JSON payloads, or text. Graphiti extracts entities and edges from each one, incrementally, without a full graph rebuild.
2. Bi-temporal edges. Facts carry validity periods, so a superseded relationship can be closed rather than deleted, which is what makes point-in-time questions answerable.
3. Custom entity types. You define the ontology, which means you control precision and you own the modelling work.
4. Hybrid retrieval. Semantic search, keyword search and graph traversal combine, so it degrades gracefully when one signal is weak.
5. MCP server. Graphiti ships an MCP server, so agents can query the graph over a standard protocol.
Adoption is real: around 30,000 stars, 3,000 forks, monthly releases through 2026. If you want a temporal graph you control, this is the default choice, and treating it as a toy would be a mistake.
What does running Graphiti actually cost?
The library is free. The operation is not, and these are the four costs teams discover after the prototype works:
1. LLM calls at ingest. Entity and relationship extraction is a model call per episode. At scale this is the dominant recurring cost and it recurs whenever you change the extraction prompt or schema.
2. A graph database to run. You provide and operate the store, including backups, upgrades and capacity.
3. Ontology design and maintenance. Custom entity types are the feature and the work. What you fail to model in month one is unanswerable in month six, and reshaping the schema means re-extracting.
4. Everything around correctness. Deduplication across sources, identity resolution when the same person appears three ways, deciding which of two conflicting facts wins, and permissions. The library gives you primitives; the policy is yours.
None of that is a criticism of Graphiti. It is what a framework is. The question is whether you want to be in that business.
Graphiti versus a managed organizational memory layer
| Dimension | Sentra | Graphiti (self-run) | Zep Cloud |
|---|---|---|---|
| Temporal fact model | Bi-temporal, maintained for you | Bi-temporal, you operate it | Bi-temporal, managed |
| Who designs the ontology | Sentra, adapted per org | You | You, within their platform |
| Ingests human work: meetings, email, calendar, tickets | Yes, natively | Only what you write code to feed it | Sources your agent touches |
| Cross-system identity resolution | Yes | You build it | Within their graph |
| Contradiction handling | At write time, with authority rules | Primitives provided, policy yours | Platform-managed |
| Per-fact permissions inherited from sources | Yes | You build it | Attribute-based access control |
| Operational burden | None | Database, extraction pipeline, schema | None |
| Cost shape | Subscription | Your infra plus LLM extraction calls | Credit-based, published tiers |
| Right when | The company needs one governed memory across tools and people | You want control and have engineers to spend | You want managed agent memory and will feed it yourself |
The honest read of that table: for a team building one agent, with engineering capacity and a clear schema, Graphiti is an excellent choice and you should use it. The line gets crossed when memory has to serve people as well as agents, span systems nobody wrote a connector for, and answer to an auditor.
The distinction that actually matters
Both approaches build a temporal graph. The difference is what feeds it.
Graphiti records what you pass in, which in practice means what your agent touched. That is a complete record of agent activity and a partial record of the company. The commitment made on a customer call, the decision reversed in a thread, the ownership change announced in a meeting: none of it is an app event, so none of it reaches the graph unless someone builds that path.
An organizational memory layer starts from the opposite end. It ingests where humans work first, resolves what was said into facts with provenance and permissions, and then serves those facts to agents. Same graph technology, opposite direction of travel.
That is why the two are not really substitutes at company scale. One is memory of what your software did. The other is memory of what your company decided.
FAQ
Is Graphiti free to use commercially?
Do I need Zep Cloud to use Graphiti?
Does Graphiti replace a vector database?
How is Graphiti different from GraphRAG?
When should I not use Graphiti?
The decision rule
Choose Graphiti when you want a temporal graph you control and you have the engineering appetite to own extraction, schema and policy. Choose a managed organizational memory layer when the memory has to know what the company knows rather than what your agent saw, because that gap is not a library problem and no amount of graph tuning closes it.