Data Sovereignty: Building the Context Store That Scales

There's a specific failure mode that experienced data engineers recognize immediately: a support routing agent classifying enterprise customers by a column that was semantically reclassified eighteen months ago. The column still exists, the values still look correct, but the business rule changed and nobody updated the record. The agent routes enterprise accounts to the wrong queue. The model isn't broken — it's missing the constraint that four people on the data team carry in their heads.

This is a data sovereignty problem. Not sovereignty in the compliance sense, but sovereignty in the sense that business context — the rules that make data mean something — is concentrated in a small number of people and has no formal representation that agents can query. Every question from an agent that touches business semantics goes back to the data engineer. They become the bottleneck, and adding more agents multiplies the load proportionally.

A context store is the structural answer: a versioned, governed, freshness-monitored layer that encodes what data means and what constraints apply — so agents can query it directly and data engineers own it systematically rather than answer it reactively. This article covers what goes in one, how to structure the schema, how to keep it current at scale, and the ownership inversion that makes it a force multiplier rather than another maintenance surface.

Research on NL2SQL agents confirms what practitioners already know from painful experience: data agents fail not from retrieval errors or model limitations, but because they form misconceptions about what data actually represents.^[1] They query the right column for the wrong semantic concept. They join on an ID field that was deprecated. They ignore the business rule that inventory counts below 5 are unreliable due to sync lag from a legacy ERP. The model did nothing wrong — nobody gave it the rules.

Meta ran into this at scale when building AI tools over their data pipelines. Only 5% of their 4,100+ code files across three repositories had any form of codified tribal knowledge — the institutional rules that experienced engineers applied automatically but had never written down. To address it, they built a pre-compute engine using 50+ specialized AI agents that systematically read code files and produced context documents encoding what the data meant, what to watch for, and how to navigate edge cases correctly.^[2] The output: structured guidance covering 100% of their code modules, up from 5%.

Most teams can't run 50 agents to extract the initial knowledge. But they face the same structural problem: business knowledge accumulates informally, agents query data without it, and the data team answers the same questions repeatedly rather than systematically. A data engineer who spends 30% of their week answering semantic questions from analysts won't survive an agentic system at any meaningful scale — agents ask questions continuously and at volume. The math doesn't work unless the questions stop routing to humans.

A context store is a versioned, governed semantic layer that gives AI agents the business rules, constraints, and freshness metadata they need to interpret data correctly — as a queryable, owned artifact rather than informal institutional knowledge.

It's not a RAG knowledge base. RAG retrieves document chunks based on semantic similarity. A context store serves governed business rules with explicit ownership, version history, and freshness SLAs. The difference matters operationally: a document in a RAG index becomes stale silently, and retrieval quality degrades as rules drift from reality. A rule in a context store has an owner who is responsible for keeping it current and a staleness state that agents observe at query time. RAG and a context store are complementary — RAG handles unstructured document retrieval; the context store handles governed business rule delivery.

It's also not a data catalog. A data catalog documents what data exists and where. A context store encodes what data means and what constraints apply to its use — the semantic layer on top of the catalog, containing the rules that can't be derived from column descriptions alone.

The Atlan context engineering framework describes this as treating every piece of context as a versioned, auditable data product with the same ownership and lifecycle management you'd apply to a core dbt model.^[4] The a16z framing is simpler: agents need a business knowledge layer that answers the questions raw data can't.^[5]

Context Kubernetes, a research architecture for managing enterprise context at scale, defines the components precisely: a Context Registry managing document identity, a Freshness Manager tracking four states (fresh, stale, expired, conflicted), a Permission Engine enforcing RBAC, and a Trust Policy determining which documents agents can act on without human verification.^[6]

Most teams that try to build a context store start by porting their existing data documentation — column descriptions, table readmes, data dictionary entries. That produces a searchable knowledge base. It does not produce a governed context store, because it's missing the three fields that make a context document agent-safe: constraints, freshness, and owner.

The constraints field is the one almost nobody covers. It encodes what agents must not do with this data — the corrective knowledge that lives in experienced engineers' heads and routinely causes failures when absent. A rule that says "enterprise tier requires ARR >= $50K" is useful. A constraint that says "never use orders.customertier for current-state routing — use customers.currenttier" is the difference between a routing agent that works and one that silently misclassifies for months.

The freshness object anchors the SLA. Without it, the context document is a snapshot with no indication of when it expires or what drives it. Agents that can see freshness state can include uncertainty in their output when a rule is stale — instead of making a confident wrong decision.

Here's a minimal but complete schema for a context document:

Freshness monitoring is where most context store implementations fall apart in production. Teams build the initial schema, populate it with current rules, and ship it. Six months later, the business rules have drifted, the context documents haven't, and agents are confidently applying stale constraints to live decisions. The problem is that freshness degradation is silent by default. A stale context document doesn't throw an error — it just serves wrong information with full confidence.

The four-state model from the Context Kubernetes architecture maps this clearly:^[6]

• Fresh — document verified against its source within the SLA window; agents can act on it
• Stale — the SLA window passed but the document hasn't been explicitly invalidated; agents should note uncertainty
• Expired — the owner must re-verify before agents can use it; treat as unavailable
• Conflicted — two documents make contradictory claims about the same data; a human must resolve before agents proceed

Different context types warrant different SLA windows. Inventory levels or real-time pricing rules need freshness within seconds — a stale inventory rule causes agents to promise availability that doesn't exist. Financial reporting context can tolerate daily freshness. Customer support routing rules need near-real-time updates to avoid misrouting live cases.^[3] The freshness SLA belongs in the schema itself, not in a separate monitoring config, because agents need to inspect it at query time to decide whether to use the document or flag uncertainty to the caller.

The production-grade pattern is CDC-driven freshness, not polling. When the dim_customers table updates, the freshness monitor checks whether any context document's source field references that model and updates the staleness state automatically.^[3] Polling hourly means you can be 59 minutes behind a breaking rule change. CDC-driven updates catch it in minutes.

The traditional data engineering model is reactive: analysts ask questions, engineers answer them. When agents enter the picture, this model doesn't hold — agents generate questions continuously and at volume, with no natural throttle. A data engineer who spends 30% of their week answering semantic questions from analysts will hit a ceiling immediately when agents ask the same questions at 10x the rate.

The ownership inversion shifts the direction of the work. Data engineers become context publishers, not question answerers. They formalize the business rules they currently hold in their heads into governed context documents — and agents query those documents directly. The engineer's output changes from verbal explanations to schema artifacts. The questions stop routing to humans.

This is what a16z means by "your data agents need context":^[5] the move from data as a pipeline artifact to data as a context product, where the same formalized rule can be queried by any number of agents without increasing the data team's workload per query. One well-maintained context document serves a dozen agents consistently. The marginal cost of adding another agent drops near zero once the schema exists.

The friction is the quality of initial formalization. Getting data engineers to write constraints[] fields — not just column descriptions — requires a different mental model: writing not just what the data is, but what can go wrong if an agent uses it wrong. That's unfamiliar work, and teams that rush it produce context documents that are technically accurate but operationally incomplete. The most successful implementations treat initial formalization as a sprint goal, not a backlog item — and pair engineers with agents during the discovery phase to surface the questions the agents actually ask before writing the schema.

The context store isn't a new invention — semantic layers and data catalogs have existed for years. What's changed is the ownership model: treating every business rule as a governed, versioned, freshness-monitored artifact that agents query directly, rather than institutional knowledge that humans mediate on demand.

The teams that get this right are the ones where data engineers stop seeing themselves as answerers and start seeing themselves as publishers. The work is the same — encoding the rules they already know — but the delivery changes from a Slack reply to a schema artifact that serves every future agent automatically.

Start with the failures. Pick the five agent decisions that went wrong in the last sprint and trace each one back to the business rule that was missing or stale. Write those five rules as governed context documents. Add the constraints[] field. Set a freshness SLA. Ship them to a simple API and measure whether the same failures recur. That's a week of work and a meaningful signal about whether the pattern scales for your system.