Graphiti (Zep)

What it is and how it works

Graphiti is an open-source framework for building temporally-aware knowledge graphs specifically designed to serve as memory for AI agents. It's the engine underneath Zep's hosted memory product, but the core library is Apache 2.0 and fully usable standalone. Where most "RAG memory" tools chunk text and stuff it into a vector store, Graphiti takes a structurally different approach: it extracts entities and relationships from conversational or document input and writes them as nodes and edges into a real property graph, backed by Neo4j or FalkorDB.

The defining architectural choice is the bi-temporal model. Every fact (edge) in the graph carries two independent time dimensions — when the system learned the fact (transaction time) and when the fact was actually true in the world (valid time, tracked via valid_from/valid_to). This distinction matters enormously for agent memory because conversations are full of statements that become stale or get contradicted later ("I work at Acme" today, "I left Acme for Globex" three months from now). A naive vector-store memory just retrieves both statements and lets the LLM sort out the mess at inference time. Graphiti instead runs contradiction detection at ingest time: when a new fact conflicts with an existing edge, it invalidates the old edge by setting its valid_to rather than deleting it, preserving full history while letting queries filter to "what's true right now" or "what did we believe as of date X."

Retrieval in Graphiti is hybrid by design — it combines semantic (embedding) search, BM25-style keyword search, and graph traversal (going N hops out from a matched entity to pull in connected context) into a single reranked result set. This is a meaningfully different retrieval shape than pure vector similarity: it can answer questions that require following relationships ("who did the person I met at the conference work with?") that a flat embedding lookup would miss entirely. Ingestion is also designed for incremental, streaming updates rather than batch reprocessing — new episodes (messages, documents, JSON events) get merged into the existing graph without requiring a full rebuild, which is what makes it viable as a live, continuously-updated agent memory rather than a static knowledge base.

Deployment patterns

Graphiti is a library plus a graph database dependency, not a single binary you download and run — this shapes how people actually deploy it. The minimal setup is: a Neo4j or FalkorDB instance (either can run in Docker on a laptop for development) plus the Python (or newer TypeScript) Graphiti package wired into an agent's memory layer, with an LLM (for entity/relationship extraction and summarization) and an embedding model configured. For solo development and prototyping, this typically means docker run for FalkorDB (the lighter-weight Redis-based option) alongside a local script calling Graphiti's add_episode and search APIs, often pointed at a cheap or local LLM for extraction to control cost.

For homelab or self-hosted team use, the pattern shifts to a persistent Neo4j deployment (Docker Compose or a managed Neo4j AuraDB instance) with Graphiti running as a service layer inside whatever agent framework or backend orchestrates the conversation loop — LangGraph, a custom agent loop, or an MCP server that exposes memory read/write tools to the agent. Because Graphiti itself has no built-in serving layer or auth, teams typically wrap it behind their own API rather than exposing it directly. For production or multi-tenant scenarios, the natural off-ramp is Zep's hosted cloud offering, which runs Graphiti under the hood with added session management, access controls, and a managed graph store — this is the intended upgrade path for teams that don't want to operate Neo4j themselves.

How it compares

The closest comparisons are Mem0 and Letta (formerly MemGPT), both of which target the same "give my agent persistent memory" problem from different angles. Mem0 is simpler to adopt — it defaults to a vector-store-plus-fact-extraction model without requiring a graph database, so it's faster to get running and has a lower operational footprint, but it lacks Graphiti's native temporal reasoning and structural relationship traversal; contradictions in Mem0 are handled more heuristically rather than through an explicit bi-temporal edge model. Letta takes a more agent-centric approach, treating memory as part of the LLM's context management (self-editing memory blocks, paging in/out of context) rather than an external queryable graph — it's better suited to single-agent conversational continuity than to building a structured knowledge base that multiple agents or tools query. Graphiti's tradeoff for its added rigor is real infrastructure weight: you need a graph database running, and graph schema/traversal concepts add a learning curve that a plain vector store doesn't have.

It's also worth distinguishing Graphiti from general-purpose RAG frameworks like LlamaIndex's knowledge graph indices — those can build similar-looking graphs but weren't purpose-built for the continuous, incremental, temporally-contradictory nature of agent conversation streams the way Graphiti was.

Best use cases and honest limitations

Graphiti fits well for agents that need to reason about change over time — customer support bots tracking account state, personal assistants tracking user preferences that evolve, or multi-session agents where "what did we last agree on" genuinely matters and contradicts earlier turns. The Apache 2.0 license and native bi-temporal model are real, verifiable strengths: valid_from/valid_to on every edge is not cosmetic, it's core to how queries resolve, and contradiction detection is noticeably more principled here than in competing tools.

The honest limitations: this is a younger project than Mem0 or Letta, so there's less production folklore, fewer battle-tested deployment writeups, and a smaller pool of people who've hit and solved the weird edge cases. The hard requirement on Neo4j or FalkorDB is a real operational cost — teams that just want "save some facts about the user" are taking on graph database administration for a problem that a vector store might solve adequately. If your use case doesn't actually need temporal contradiction resolution or relationship traversal, Graphiti is probably more infrastructure than you need. It's best suited to teams building serious long-running agents where memory correctness over time is a first-class requirement, not a bolt-on for a simple chatbot that just needs to remember a user's name.