Context Lakes: The Infrastructure Layer AI Agents Need That Doesn't Exist Yet

If you're building production AI agent systems, you've probably assembled an architecture that looks something like this: a relational database (or document store) for current state, a feature store or Redis layer for derived signals, a vector database for semantic search, and some streaming infrastructure stitching everything together.

It works. Until it doesn't.

There's a category of correctness bug in this architecture that doesn't look like a bug at first — it looks like a slightly wrong decision, or an occasional inconsistency that's hard to reproduce. The root cause is something the architecture doesn't address: The context an agent sees at decision time is assembled from multiple systems that don't share a transactional boundary.

This post explains why that matters, when it matters, and what a different approach looks like.

The Architecture Has a Seam Problem

Here's the issue in plain terms. When an agent makes a decision in your system, it typically queries several things:

• The database: "What is the current state of this user/account/resource?"
• The feature store: "What are the pre-computed signals — velocity counts, spend patterns, behavioral aggregates?"
• The vector database: "What recent records are semantically similar to this one?"

Each query is fast. Each system is internally consistent. The problem: they're not consistent with each other. The feature store reflects state 200ms ago (because that's your pipeline latency). The vector index reflects state 300ms ago (because that's your indexing delay). The database is current.

The agent combines these three stale-at-different-rates views into a decision as if they were a coherent snapshot. They're not. In most cases, the difference doesn't matter. In specific cases — particularly under high concurrency, with rapidly changing shared state, making decisions that can't be reversed — it does matter.

A Concrete Scenario

You're building a system where AI agents approve time-sensitive transactions. Two agents are processing requests simultaneously, 80ms apart, both dependent on the same shared limit.

Agent A reads the feature store: Current utilization is at 90% of the limit. Runs decision logic. Approves.

Agent B reads the feature store 80ms later: current utilization is still at 90% (the feature store pipeline hasn't processed Agent A's approval yet). Runs decision logic. Also approves.

Both agents made correct decisions given what they saw. The combined outcome — two approvals that together push utilization over the limit — is wrong.

The fix isn't "faster pipeline." Faster pipelines reduce the window in which this can happen. They don't close it. The fundamental issue is that the feature store and the decision logic share no transactional boundary.

Why You Can't Compose Your Way Out

The natural response is to design around the seams: Add coordination, tighten the pipeline, use optimistic locking. These help at the margins.

A paper published in January (arXiv:2601.17019) makes a stronger claim: there's no composition of existing system classes — feature stores, vector databases, relational databases, stream processors — that can guarantee what the paper calls Decision Coherence.

Decision Coherence means: Every agent's decision is evaluated against a context that is (1) internally consistent, (2) includes derived semantic signals covered by that consistency guarantee, and (3) bounded in freshness.

The impossibility result: Satisfying all three across independently maintained systems requires distributed coordination that reintroduces exactly the latency and failure modes you're trying to avoid. The only way to enforce Decision Coherence is within a single system boundary that covers all required retrieval types.

What Retrieval Types Are We Talking About?

A complete agent decision in a real system typically requires:

• Point lookups: "What is the current state of entity X?"
• Range scans: "What happened with entity X in the last 10 minutes?"
• Aggregations: "How many events matching this predicate occurred in the last 60 seconds?"
• Similarity search: "What past records are semantically similar to this event?"

Today, these map to different systems. The first two go to your OLTP store or time-series database. The third goes to your feature store or a streaming aggregation layer. The fourth goes to your vector database.

None of these systems was designed to share a transactional boundary with the others. The seams are architectural, not incidental.

The Context Lake Concept

The paper defines a Context Lake as the system class that enforces Decision Coherence. The requirements follow from the correctness property, not the other way around.

The key design invariant: all four retrieval types above — plus semantic transformations (embedding computation, aggregate materialization) — must be handled within a single system boundary. The reason: if embeddings are computed outside the system and loaded into a vector index, they're asynchronous — there's no tie between when they were computed and when the records they were derived from were written. An agent reading both is reading across two independent timelines.

Inside a Context Lake, semantic transformations happen inside the boundary. An embedding computed from events up to time T, stored inside the same transactional scope, is consistent with those events. You can retrieve both the embedding and the events under the same snapshot.

The memory model:

• Episodic – raw events, time-ordered. The source of truth for what happened.
• Semantic – derived state: embeddings, aggregates, entity profiles. Computed from episodic events, managed inside the system boundary.
• Procedural – operational rules: which signals matter, how cohorts are defined, when derived state needs updating.

When This Matters (and When It Doesn't)

This architecture doesn't matter for every use case. The Decision Coherence requirement is meaningful when:

Decisions are irreversible. If an agent approves a payment, allocates an inventory item, or commits a resource, the decision can't be recalled. Wrong decisions produce real costs.

State changes fast. If the thing the agent is deciding about can change materially within hundreds of milliseconds — account balance, exposure limit, fraud signal — stale context at decision time produces wrong answers.

Concurrency is high. If many agents are acting on overlapping state simultaneously, the window in which seam-induced inconsistency can produce wrong outcomes is wider.

If you're building a recommendation system where agent decisions are suggestions that users can ignore, and the state being reasoned over changes slowly, Decision Coherence is probably not your primary concern. If you're building systems that approve financial transactions, allocate limited resources, or make risk decisions, it's worth understanding.

Getting Started

The full formal treatment is in arXiv:2601.17019. The practical canonical definition is at contextlake.org/canonical. If you want to assess whether your current architecture has a Decision Coherence gap, the questions are:

1. Does a single-agent decision require data from more than one independently maintained system?
2. Are semantic objects (embeddings, aggregates, entity profiles) computed outside your transactional store?
3. Is there a declared, enforced freshness bound on the derived context at decision time?
4. Do concurrent agent decisions act on shared state without transactional isolation?

If the answer to any of these is yes and your agents are making irreversible decisions, you likely have a gap worth closing.

This post is based on "Context Lake: A System Class Defined by Decision Coherence" (arXiv:2601.17019) by Xiaowei Jiang.