Zep's distinctive design choice is **first-class temporal awareness**. Every fact in its store carries explicit timestamps for **when it became true** (valid-from) and optionally **when it stopped being true** (invalid-from).
The engine underneath is called **Graphiti**. It extracts entities and relationships from dialogue and stores them as graph edges. Each edge has temporal metadata. When the user says 'I work at Anthropic' on one date and 'I just moved to OpenAI' on a later date, Graphiti does not overwrite the first fact, it marks it as invalid as of the new date and creates a new edge for the new employer.
**Why this matters in 2026.** Most memory frameworks treat memory as approximately atemporal: the newest fact wins, the older fact is discarded or soft-deleted. That works for most chatbot use cases. It breaks the moment your product needs to answer a question like 'what was the user's job title in March?' or 'when did the user change their dietary preference?' Those are **point in time queries**, and they require explicit temporal modeling.
The other options in the question describe things Zep is not:
- A pure vector store stores embeddings without structured metadata. Zep stores graph edges with rich metadata including timestamps.
- Zep does not replace the LLM's context window. It sits behind the window and feeds it relevant facts at retrieval time.
- Short-term sliding-window conversation history is a separate concern. Zep handles long-term memory with temporal facts, not the immediate conversation buffer.
Use Zep when your product genuinely needs to reason about historical state. Use a simpler framework (Mem0, LangChain memory) when newest-wins is enough.
**Zep's central design choice is first-class temporal modeling.** Every fact stored is a graph edge with explicit `valid_from` and (optionally) `invalid_from` timestamps. This is what distinguishes Zep from generic vector stores, flat fact stores like Mem0's default, and from LangGraph's typed-state model.
The **Graphiti engine** (Zep's open-source memory engine, available standalone) does three things between turns of a conversation.
First, it runs an **extraction pass** that identifies entities and relationships in the dialogue. 'User' is an entity. 'works at' is a relationship. 'Anthropic' is an entity. The result is an edge: `User -[works at, valid_from=2024-01-01]-> Anthropic`.
Second, it performs **temporal updates** when new facts modify existing ones. If a later turn says 'I just moved to OpenAI,' Graphiti does not delete the Anthropic edge, it sets its `invalid_from` to the new date and creates a new edge to OpenAI with `valid_from` matching. The old edge is preserved with its temporal bounds.
Third, it supports **temporal retrieval** at query time. The retriever runs a hybrid of vector search (find candidate entities), graph traversal (find connected facts), and temporal filtering (return only facts valid at the query time, if a date is specified). The agent can ask 'what was the user's job title in March 2024' and get the right answer even though the user has changed jobs since.
**Why none of the other options fit Zep.**
*Storing dense vectors without structured metadata* is what a pure vector database does (Pinecone, Weaviate in their simplest configurations). Zep stores rich metadata on graph edges; the vectors are auxiliary, not primary.
*Replacing the LLM context window with a graph query* is not what Zep does. Zep is a retrieval-augmentation layer: it sits behind the prompt and produces context that gets injected into the window.
Quick reference
TL;DR
Zep's Graphiti engine stores facts as graph edges with explicit valid-from and invalid-from timestamps, enabling point in time queries that flat vector stores cannot answer natively.
Imagine a notebook of facts about your friend. A normal notebook just says 'works at Anthropic' and overwrites that line when the job changes. Zep's notebook keeps both lines,'worked at Anthropic from 2024 to 2026' and 'works at OpenAI from 2026 onward.' Now if anyone asks 'where did they work in early 2025,' the notebook can answer. Most memory stores cannot do this without losing information; Zep was designed for it from day one.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Chatbots that only need the latest user preference and never surface historical state The temporal modeling is overhead. Mem0 or LangChain memory is simpler and sufficient.
Stateless tools where the user has no continuity across calls There is no history to model. Any memory framework is overkill.
Workloads where the cost of running extraction plus a graph database is not justified by query requirements Zep is more expensive per turn than simpler stores. If the product never asks point in time questions, the cost has no payoff.
Quick scan · 2–4 min
Everything important, quickly.
Identify the temporal modeling as Zep's differentiator. Describe the Graphiti engine, the valid-from and invalid-from edges, the extraction process, and the hybrid retrieval. Walk through a concrete example like a user changing jobs and how Zep preserves the history rather than overwriting. Identify workloads where temporal queries justify the cost (compliance, audit, longitudinal) and workloads where simpler stores fit better. Close with the architectural composition: Zep behind an orchestration primitive like LangGraph state.
Real-world examples
Real products, models, and research that use this idea.
1Zep is used by support-automation products that need to reconstruct customer state at the time of a past complaint
2Healthcare-focused AI products use Zep-style temporal modeling to track medication and condition changes over time
3Graphiti (Zep's open-source engine) is used independently by teams building custom temporal memory layers
4Compliance-heavy fintech assistants in 2026 use Zep to produce point in time audit trails of agent reasoning
5Longitudinal user-modeling products (habit trackers, coaching assistants) use Zep to reason about how preferences evolve
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does Zep's temporal model interact with conflict resolution when two facts seem contradictory?
Sign in or go Pro to see the approach for this follow-up.
QWhen does the cost of running Zep outweigh the benefit of temporal queries?
Sign in or go Pro to see the approach for this follow-up.
QHow would you architect a system that needs both LangGraph state for orchestration and Zep for long-term temporal memory?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating Zep as a generic graph database or as just another vector store with retrieval, missing that the temporal dimension is the differentiator.