We're hiring! Come build with us →
Zep
AI Agents Guide

What Is a Context Lake?

A Context Lake is the infrastructure that implements agent memory at enterprise scale — a governed system of context graphs. The data-lake parallel, explained.

Agent Runtime

LangGraph·Vercel AI SDK·Pydantic AI·Google ADK·custom

Use the Zep SDK with your agent framework or custom application.

Ingestion

chat·JSON·documents·app events

Add conversations, JSON data, documents, and application events.

entity extraction·relationships·ontology·invalidation

Graphiti extracts facts and relationships to construct Context Graphs.

Context Assembly

context blocks·templates·token-efficient

Zep selects context and assembles it into blocks for agent prompts.

Retrieval

sub-200ms·auto-optimized·provenance-linked·policy-filtered

Zep selects context for the task within the specified token budget.

Governance

ABAC·multi-tenant isolation·customer key encryption·retention policies·audit·provenance

Zep applies access policies to reads and writes. It records source information and applies retention policies.

Konig

entities·facts & edges·decision traces·episodes

Konig serves Context Graphs with source information and records of changes over time.

Key takeaways

  • A Context Lake is the infrastructure that implements agent memory at enterprise scale — a governed system of context graphs.
  • It's the data-lake pattern applied to agent context: complementary, not competing — different data and consumers, the same governance rigor.
  • Powered by Konig with Graphiti; sub-200ms p95 retrieval across millions of graphs. S&P Global Market Intelligence named Zep a likely de facto partner in the enterprise agent stack (coverage).

A Context Lake is the infrastructure that implements agent memory at enterprise scale — a governed system of context graphs that manages, governs, and serves everything AI agents need to know. It is to agent memory what the data lake is to analytics: a single, governed data layer that holds many sources and serves many consumers. Zep is the Context Lake for AI agents.

The problem it solves

Giving one agent memory is straightforward. Running memory for an enterprise — millions of users, hundreds of agents, dozens of data sources, all under access control, retention, and audit requirements — is an infrastructure problem. Bolting memory onto each agent produces silos, inconsistent governance, and no way to audit what an agent knew or why it acted. The Context Lake solves this the way the data lake solved analytics sprawl: one governed system, many graphs, served as a platform.

The data-lake parallel

The analogy is deliberate and precise — and complementary, not competing:

Data
Your Data Lake

Structured, quantitative

Tables, transactions, logs, metrics.

Context Lake

Structured and unstructured data

Use records, documents, conversations, and events as sources of context.

Query model
Your Data Lake

SQL, batch analytics

Optimized for aggregation and retrospective analysis.

Context Lake

Graph traversal, semantic

Temporal context graphs with entity-aware retrieval.

Latency
Your Data Lake

Seconds-to-minutes

Batch jobs, scheduled pipelines, dashboard refresh.

Context Lake

Sub-200ms retrieval

Real-time context at agent inference speed.

Consumers
Your Data Lake

Dashboards & ML

BI tools, data scientists, reporting pipelines.

Context Lake

Agents & assistants

Agents and assistants retrieve context for their tasks.

Governance
Your Data Lake

Row & column ACLs

Table-level permissions, role-based access.

Context Lake

Entity-level ABAC

Attribute-based policies, retention rules, full audit trail.

A Context Lake doesn't replace your data lake. They hold different data for different consumers with different access patterns — but the same governance rigor. The data lake feeds analytics; the Context Lake feeds agents.

What a Context Lake is made of

  • Context graphs — temporal, bi-temporal graphs (one per user, team, or project) that track entities, relationships, and facts, with provenance and validity over time.
  • Konig — Zep's proprietary graph database service that persists and serves millions of these graphs with sub-200ms p95 retrieval regardless of graph size or count, using a hot-graph memory strategy (active graphs in memory, the rest snapshotted to cheap object storage).
  • Graphiti — the open-source library that constructs the context graphs from inputs. Graphiti runs on Konig when scaled with Zep.
  • Governance in the data layer — attribute-based access control (ABAC), retention policies with legal hold, and audit logging apply across every graph and every query, not bolted on per agent.

How it manages, governs, and serves

  • Manages: ingests any source (chat, business data, documents), constructs and continuously updates context graphs, and invalidates facts as they change.
  • Governs: enforces who can access what context, how long data is retained, and produces an audit trail of every request and policy decision — with provenance from every fact back to its source.
  • Serves: returns relevant, token-efficient context to any agent in milliseconds, across millions of graphs, in any deployment model (managed cloud, your own keys, or inside your VPC).

How it serves millions of graphs at low latency

The hard part of enterprise memory is serving many graphs fast and affordably. The Context Lake workload is the opposite of a traditional graph database's — not one giant graph, but millions of small, mostly-cold, all-temporal, all-governed graphs. Konig is built for that shape:

  • Tiered storage. Hot graphs live in RAM (microseconds), warm graphs on local NVMe, and cold graphs on object storage, rehydrated in milliseconds. Cost tracks active graphs, not total graphs — a deployment with a million graphs and 1% hot pays for roughly 1% of the memory.
  • Near-constant-time retrieval. p50 latency holds roughly flat from a thousand graphs to a million; production sustains thousands of queries per second across millions of graphs at sub-200ms p95.
  • Unified retrieval. Vector similarity, BM25, graph traversal, and pattern matching run over the same data and return one ranked answer — no separate retrieval stack to stitch together.

Architecture details: Konig and the Zep paper.

Deployment: the trust boundary moves with you

Enterprises rarely accept one-size-fits-all data handling, so a Context Lake offers a spectrum:

  • Cloud — Zep's managed service; nothing to run. SOC 2 Type II, HIPAA BAA.
  • Cloud + your own keys (BYOK) — Zep manages the service; you hold the encryption keys (AWS/GCP/Azure KMS), so data at rest is encrypted under keys you control.
  • Bring your own cloud (BYOC) — Zep runs inside your VPC: your network, your perimeter, your compliance boundary.

The same Context Lake, with the trust boundary placed where your security and compliance posture requires.

Who it's for

Engineering and AI leaders building agents at production scale — especially in regulated or data-sensitive environments (financial services, healthcare, enterprise support) where governance, provenance, and deployment control aren't optional. S&P Global Market Intelligence (451 Research) initiated coverage on Zep as a likely de facto partner in the enterprise agent stack, citing exactly this enterprise-plus-temporal-graph differentiation.

Related: What is agent memory? · Konig · Graphiti · Enterprise & deployment · AI agent memory guides

Frequently asked questions

Is a Context Lake the same as a data lake?

No, and it doesn't replace one. A data lake serves analytics; a Context Lake serves agents. Different data, different consumers, different access patterns — same governance rigor. They're complementary.

Is a Context Lake just a vector database or a knowledge graph?

No. It's a governed system that manages many temporal context graphs and serves them at scale with millisecond retrieval, access control, retention, and audit. A single vector store or graph database is a component, not the governed data layer.

How is a Context Lake different from agent memory?

Agent memory is the category — everything an agent knows over time. A Context Lake is the infrastructure that implements agent memory at enterprise scale.

What powers Zep's Context Lake?

Konig (Zep's proprietary graph database service) with Graphiti (open source) constructing the graphs on top of it.

How does a Context Lake scale to millions of users?

With tiered storage and a hot-graph strategy: only active graphs sit in memory; the rest are snapshotted to cheap object storage and rehydrated in milliseconds. Retrieval latency stays roughly constant as the graph count grows.

How is cost controlled at that scale?

Cost tracks active graphs, not total graphs — cold graphs live on inexpensive object storage, so a large deployment with a small hot fraction pays mainly for the active set.

Can I run a Context Lake in my own environment?

Yes — managed cloud, with your own encryption keys (BYOK), or inside your own VPC (BYOC). The trust boundary moves with the deployment.