Context Lake
Context Lake is the platform’s shared operational brain: a graph-backed, queryable view of your stack built from live signals across your ecosystem. Agents and assistants use it as memory—so answers and actions stay tied to production truth, not a stale wiki or a one-off prompt.
Solution page: exemplar.dev/solutions/context-lake-ai-agents . Background: What is a Context Lake?
Why it matters
An agent that doesn’t know which team owns a service, what changed in the last deploy, or whether an incident is already open makes wrong decisions. Without a shared substrate, agents hit three failure modes:
- Stale context — the prompt was accurate once; production has moved on.
- Incomplete context — the agent sees the service but not the active incident on its upstream dependency, so it fixes the symptom.
- No context — general knowledge stands in for your specific environment.
The graph structure is what makes context useful: services have owners, owners have on-call schedules, services have dependencies, dependencies have incidents. Flat tables can’t represent that; a live graph can.
How it fits together
Integrations feed the lake; agents and the console read and act through the same graph and policies.
| Layer | Role |
|---|---|
| Integrations | Commits, resources, vulnerabilities, tickets, and alerts stream in continuously—ingestion, not exports |
| Context Lake | One linked operational model; “who owns what” and “what depends on what” have a single answer |
| Consumers | Agents, the console, and memory / context management all query the same graph |
What feeds the lake
| Source | What it contributes |
|---|---|
| AWS / cloud | Resource inventory, health, security groups, recent changes |
| GitHub | Repos, commits, open PRs, deployment events, code owners |
| CI/CD | Build status, deploy history |
| Kubernetes | Pod status, events, service topology |
| Incident management | Open incidents, on-call assignments |
| Observability | Alerts, anomaly flags, SLO status |
| Jira / Linear | Open tickets, sprint state, escalations linked to services |
| Snyk / security | Vulnerability findings, exposure severity |
Context Lake vs service catalog
A service catalog is an inventory: what services exist, who owns them, how they connect. Context Lake is the live operational graph: what is happening right now, and how it relates to everything else. The catalog is effectively a node inside the lake—it supplies the ownership and dependency relationships that give live signals their meaning.
One picture for agents and engineers
The same layer powers the agent in your IDE and the dashboard your on-call engineer has open at 2am:
- An agent proposes a rollback; the engineer verifies it against the same data the agent used.
- Policy is consistent—an agent can’t do what the console would block.
- Audit trails reference the same entities (service, incident, deploy) regardless of who triggered the action.
Capability checklist
- Real-time ingestion from Git, cloud, security, ticketing, and observability connectors
- Single linked knowledge graph of services, teams, dependencies, risk, and work
- Agent-ready memory—assistants query the same entities the dashboard uses
- Guardrails and audit on every read-and-act path through the graph
Context Lake is the substrate under Memory (durable facts), Context management (per-turn assembly), and the connector tools in Tools & MCP. Enable connectors under Getting started to populate it.
Related
- Context management — per-turn context assembly from the lake
- Memory — durable organizational memory linked to the graph
- Tools & MCP — connector tools that read and act on the same entities
- DevX Assist — operational workflows grounded in lake context