The practice of designing, scoping, and managing the context AI agents need to reason, decide, and act.
Context engineering is the discipline of getting the right information to an agent at the right time. Not the prompt. Not the model. The information layer underneath — what the agent knows about the user, the business, the history, and the moment it’s reasoning about.
Every production agent does context engineering, whether intentionally or by accident. The choice is whether to design it.
Context engineering covers four questions:
When teams do this well, agents reason with the user’s full history and the business’s current state. When they don’t, agents hallucinate, contradict, or fail to act on what’s already known.
Agent memory is the category of infrastructure that makes context engineering possible at scale. It’s what an agent knows across time — about the users it serves, the business it operates in, and the work it has done before.
You can do agent memory badly: a file the agent writes to, a chat history buffer, a vector store that retrieves “similar” documents. You can do it well: a temporal graph that keeps facts current, governed at the entity level, served back to the agent at production latency.
Context engineering is the practice. Agent memory is what the practice produces.
The Context Lake is the infrastructure for agent memory at enterprise scale. Millions of context graphs, one per user, customer, team, or topic. Each captures the chat, documents, events, and business data tied to that subject, structured temporally and served back to agents on demand.
Chat, documents, events, business data — all unified into one graph per subject. No more stitching together a vector store, a chat buffer, and a database every time the agent needs to reason.
Attribute-based access control on every entity. Retention rules applied at ingest. Full audit. Context engineering at the enterprise level isn't possible without governance in the substrate.
Sub-200ms retrieval across millions of graphs. Vector, full-text, and graph traversal in one ranked answer. Context engineering ends at the moment the agent asks for context — the system has to be there.
Chat, business data, documents, events — ingested through a single SDK, unified in one graph per subject.
Every fact carries timestamps for when it became valid and when it stopped being valid. Point-in-time queries follow from the model, not from custom logic above it.
ABAC, retention, audit, and provenance are properties of the data model, not a layer bolted on. Every read and write is policy-gated.
We can easily see Zep becoming a de facto partner in this layer of the enterprise agent stack.
Prompt engineering is about how you instruct the model. Context engineering is about what the model sees alongside the instruction — the user history, business state, prior decisions, and current facts that shape the answer. Prompt engineering writes the question. Context engineering supplies the world the question is asked in.
Retrieval-augmented generation is one technique inside context engineering. RAG retrieves documents from a corpus and adds them to the prompt. Context engineering covers everything else as well: user memory, business data, event streams, temporal validity, governance, and how the retrieved context is assembled and ranked. RAG is a tactic. Context engineering is the practice.
For a single-agent prototype, no. For production agents at enterprise scale, yes. Context engineering for thousands of agents across every user, customer, and team requires infrastructure that handles isolation, governance, retrieval performance, and temporal correctness together. That's what the Context Lake is built for.
