Zep builds governed context graphs for business AI agents

Zep turns conversations, documents and business records into context that an AI agent can retrieve for a particular task. Its current platform organises that information in temporal graphs and adds governance around access. The useful distinction is between storing more information and supplying the right evidence: an agent handling an account renewal needs the current commitment, its source and the authority to see it, rather than an indiscriminate transcript dump.

01 / ProductContext connects records rather than merely collecting them

The platform overview describes ingestion from business data, documents and conversations, followed by graph construction and task-specific retrieval. Its governance proposition includes policies and access logging. For a buyer, the question is whether the resulting context preserves the relationship between a fact, the account it concerns and the source from which it was derived.

The Context Lake description positions multiple context graphs as a shared enterprise system, supported by Zep’s Konig graph database service. This is broader than remembering a single user’s chat preferences. A business may need a graph for a customer account, another for a domain of knowledge, and clear rules for combining information when an agent serves a particular employee.

That structure introduces modelling decisions. An account name in a sales note may refer to a subsidiary rather than its parent, and the same person may appear in several systems. A useful pilot must demonstrate identity resolution on the organisation’s own records. More connected facts do not help if the connections silently combine unrelated customers or carry a former employee’s permissions forward.

02 / AudienceUseful when agents need changing relationships and commitments

Zep is a plausible candidate for account assistants, service workflows and enterprise applications where questions span several sources. A support issue may depend on a recent call, a contractual commitment and a current product configuration. The graph approach can make those connections available without asking each agent to rediscover the same relationships from full documents on every turn.

Compare Mem0 for the narrower decision of adding persistent memory to an existing assistant. Compare Neo4j when the central requirement is a graph database and the team wants to own more of the surrounding extraction and retrieval design. These are architectural comparisons, not a claim that one product provides an identical substitute for every Zep feature.

A team whose requirements are limited to searching a fixed document collection may need less context infrastructure. Conversely, a sensitive workflow with broad enterprise access should not begin with a permissive shared graph and add restrictions later. Identify the unit of isolation, the accountable data owner and the expected retrieval policy before deciding how much information to ingest.

03 / WorkflowProposed workflow: an account assistant that remembers a changed commitment

Use fictional account records representing a service agreement, a later conversation and a resolved support issue. Define the questions the assistant should answer: what the customer was promised, which promise is still current and what evidence supports the answer. Include two similarly named accounts so the evaluation catches accidental identity merging rather than only testing easy retrieval.

The custom graph structure guide explains domain-specific entity and edge types. Set the ontology before ingestion: the documentation says changes do not automatically re-extract existing data. For this pilot, model only the distinctions needed to answer the selected questions. An elaborate schema designed before inspecting real ambiguity can create unnecessary extraction and maintenance work.

Ingest the earlier commitment before the later correction, with clear source identifiers and dates. Retrieve context for a question about the present obligation and a separate question about historical commitments. Review whether the agent can explain the difference and cite the appropriate evidence. Do not reward a response merely because it repeats a recognisable phrase from one of the inputs.

If using Flex Plus or Enterprise, evaluate custom extraction instructions for terminology specific to the business. These instructions describe domain context and extraction scope; an ontology defines types. Keep the two configurations distinct. A useful instruction might explain what the company means by a renewal blocker, while a type describes the fields or relationships the application expects to retrieve.

Next, examine observations, which synthesise meaningful patterns across graph evidence. They are available on Flex Plus and Enterprise and are read-only derived constructs. Check whether a repeated pattern remains grounded when one of its supporting facts changes. A convenient summary can become misleading if the agent treats an interpretation as though it were the original contract.

Use the webhook guide to establish when ingestion has finished before running the next check. Available webhook routes report processing and batch completion; the receiving application must verify signatures and handle delivery safely. Keep evaluation failures separate from timing failures. Asking a question before its source has been processed is a different problem from retrieving the wrong fact after processing completes.

Finally, run the same questions through two authorised user roles and one role that should lack access. The acceptance result should show the correct evidence for permitted requests and an appropriate refusal or empty result for restricted context. Keep the baseline answer, returned context and source records together so a later extraction or model change can be tested against the same cases.

04 / PricingIngestion credits and plan gates shape the real budget

The current pricing page displays monthly USD plans, with a separate annual option. The table below uses the monthly view. Credits are consumed primarily by the size of ingested episodes, while the listed retrieval and storage operations are unmetered; request limits and plan features still apply.

An episode uses one credit for each 350 bytes or part thereof, and applicable webhook invocations use one eighth of a credit. This makes record size a budget input, not just the number of messages. The paid self-service plans automatically top up below the stated balance threshold. Confirm how that behaviour fits spending controls before connecting an unbounded source feed.

For a forecast, sample the actual payloads you intend to send, including metadata and repeated updates. Calculate ingestion separately from the model that consumes retrieved context. The free plan can establish basic integration, but it does not demonstrate every feature in the proposed workflow. In particular, a pilot relying on observations, extraction instructions and webhooks should be costed against a plan that includes them.

05 / DistinctionsDomain structure and derived context are separate controls

Zep’s graph customisation makes the extraction model explicit enough for teams to reason about it. The documentation distinguishes default types, custom types and stricter ontology behaviour, while some hierarchy capabilities are labelled closed beta. Keep a production design within features confirmed for the selected account. A documentation example is not an entitlement to every capability described alongside it.

Observations add another level of interpretation beyond individual facts. That can help an agent recognise a recurring issue without reading every event, but it also calls for targeted evaluation. Compare the observation with its supporting evidence and ask whether its wording would change the user’s decision. A concise but overstated summary can be more consequential than a harmless missing detail.

06 / QuestionsConfirm governance at the level of the actual contract

The pricing page separates enterprise deployment and governance features from self-service plans. Obtain the agreement that applies to encryption-key ownership, deployment location, logs and any required data-processing terms. Do not infer those rights from a general platform security statement. The appropriate arrangement depends on which records the agent can access and how widely the resulting context is shared.

Also resolve how source corrections and deletions propagate to derived facts and observations. A source system may change its retention or access settings independently of the context store. Demonstrate the expected result after such a change, and decide who investigates a mismatch. This operational ownership is central to trustworthy shared context, especially when several agents use the same account graph.

07 / DecisionChoose a graph boundary before expanding ingestion