> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://help.getzep.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://help.getzep.com/_mcp/server.

# Context Graph overview

> Learn how Zep represents enterprise, customer, account, and user context in temporal Context Graphs.

A Context Graph represents facts, their relationships, the source episodes from which Zep derived them, and how they change over time. Teams use Context Graphs for enterprise knowledge, agent memory, and customer or account context.

Zep uses [Graphiti](/graphiti/getting-started/overview), its open-source temporal graph framework, to derive graph artifacts from episodes. Konig is Zep's graph database service. You do not need to interact with Graphiti or Konig when you use the Zep service.

#### What is a Knowledge Graph?

A knowledge graph is a network of interconnected facts, such as *"Kendra loves
Adidas shoes."* Each fact is a *"triplet"* represented by two entities, or
nodes (*"Kendra", "Adidas shoes"*), and their relationship, or edge
(*"loves"*).

\


Knowledge Graphs have been explored extensively for information retrieval.
Zep autonomously builds temporal knowledge graphs, handling changing relationships
and maintaining historical context.

Zep builds a Context Graph from text, JSON, messages, and documents. The graph can represent a user, customer, account, project, product, organization, or other business subject.

A user graph is created for a Zep user and integrates with threads and user-specific retrieval. A Context Graph addressed with `graph_id` stores shared or domain context that is not owned by one Zep user.

Here's an example of how Zep might extract graph data from a chat message, and then update the graph once new information is available:

![graphiti intro slides](/_fern-files/zep.docs.buildwithfern.com/204428cea99ae5c2c2055235e6cab2c0b5bc5aad3d7fdfbb1e3792cf4cd9e8fb/images/graphiti-graph-intro.gif)

Each node and edge contains attributes. Zep stores each fact on an edge and keeps links to its source episodes.

Edge timestamps record when a fact becomes valid or invalid.

## Graph Data Structure

Zep's graph database stores data in three main types:

1. Entity edges (edges): Represent relationships between nodes and include semantic facts representing the relationship between the edge's nodes.
2. Entity nodes (nodes): Represent entities extracted from episodes, containing summaries of relevant information.
3. Episodic nodes (episodes): Represent source data stored in Zep through chat history or the `graph.add` endpoint.

Source episodes provide provenance for derived facts and graph artifacts. Provenance identifies the source data. It does not guarantee that a source or a derived fact is correct.

Every entity node reports the episodes that mention it in the `episodes` field (named `episode_uuids` in the v4 API). When the node has 100 or fewer live mention episodes, the list holds the complete set, newest first, and `episodes_truncated` (v4: `episode_uuids_truncated`) is `false`. When the node has more than 100, the list holds the newest 100 and the flag is `true`; read the full set with an episode list call filtered by `mentioned_node_uuids`.

## Working with the Graph

To learn more about interacting with Zep's graph, refer to the following sections:

* [How Graph Creation Works](/how-graph-creation-works): How Zep turns episodes into entities, relationships, and facts in the graph.
* [Documents](/documents): Group episodes of the same source the way threads group messages.
* [Adding Data to the Graph](/adding-context): Learn how to add business data, documents, JSON, and conversations.
* [Searching the Graph](/searching-the-graph): Explore techniques for efficiently searching the graph.
* [Governance](/governance): Control access to context and review dashboard and API activity.

These guides will help you use Zep's knowledge graph in your applications.