This guide shows you how to give your agent searchable knowledge graphs built from any text data using Zep’s Graph capabilities. Zep allows you to build knowledge graphs from unstructured text, JSON, or messages—including emails, Slack messages, transcripts, chunked documents, and inventory data. Unlike traditional RAG systems, Zep is designed for evolving, streaming data that continuously updates your agent’s knowledge.
Looking for a more in-depth understanding? Check out our Key Concepts page.
Set up your Python project, ideally with a virtual environment, and then:
After creating a Zep account, obtaining an API key, and setting the API key as an environment variable, initialize the client once at application startup and reuse it throughout your application.
Before adding data, you need to create a standalone graph. This gives you an independent knowledge graph that isn’t tied to individual users—useful for shared knowledge bases, domain-specific graphs, or specialized use cases.
Zep excels at building knowledge graphs from streaming data that evolves over time. You can add any unstructured text, JSON, or message data to build your knowledge graph. Common examples include:
Zep is optimized for evolving data, not static RAG. While you can add static documents, Zep’s knowledge graph construction shines when tracking relationships and facts that change over time.
One-time data uploads: If you have existing data to backfill (such as a set of documents or historical data), you can add it using a one-time data migration. Loop through your data and call graph.add for each item, or — for large backfills — use the Batch API.
Zep supports three data types when adding data to a graph:
Use message data when you have communications with designated speakers, such as emails or chat logs. See our Adding Data to the Graph guide for details.
Use text data for raw text without speaker attribution, like internal documents or wiki articles. See our Adding Data to the Graph guide for details.
Use JSON data for structured business data, REST API responses, or any JSON-formatted records. See our Adding Data to the Graph guide for details.
After adding data to your knowledge graph and before generating the AI response, you need to construct a custom context block from graph search results. Unlike user-specific context retrieval, knowledge graphs require you to manually search the graph and build the context block.
Why context block construction?
Knowledge graphs don’t have the concept of threads or conversation history, so you need to explicitly search for relevant information and format it into a context block. This gives you full control over what information is included and how it’s structured.
To build a custom context block, you’ll:
See our Advanced Context Block Construction guide for complete examples, helper functions, and best practices for building custom context blocks from graph search results.
Here’s a simplified example of searching a knowledge graph and building a context block:
For production use cases, refer to the Advanced Context Block Construction guide, which includes:
Once you’ve retrieved the Context Block, you can include this string in your agent’s context window.
You can append the context block directly to your system prompt. Note that this means the system prompt dynamically updates on every chat turn.
Dynamically updating the system prompt on every chat turn has the downside of preventing prompt caching with LLM providers. In order to reap the benefits of prompt caching while still adding a new Zep context block in every chat, you can append the context block as a “context message” (technically a tool message) just after the user message in the chat history. On each new chat turn, remove the prior context message and replace it with the new one. This allows everything before the context message to be cached.
Now that you’ve learned how to give your agent knowledge through graph capabilities, you can explore additional features: