Pick the design choice that Zep's temporal knowledge graph is specifically tuned for

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.