When my manager asks me “what was our profit margin last quarter,” I do not consult a document. I do not run a query to figure out what she means. I simply know that “last quarter” refers to our fiscal calendar, which runs February through January, and that “profit margin” carries a specific internal definition that excludes certain intercompany transfers. I know these things the way I know where the coffee machine is. It is tribal knowledge, absorbed somewhere along the way, and I apply it without noticing that I am applying it.
An AI system has none of this. Ask it the same question against your raw data and it will produce a confident, plausible, calendar-year answer that is wrong in a way nobody catches until it matters.
That gap, between what a human implicitly knows and what a machine must be explicitly given, is context. Context is everything a knowledgeable user needs to answer a question, defined in a machine-readable way so an AI can answer the same question correctly.
But assembling context is only half the problem. What the system does with that context, how it selects, resolves, applies, and corrects it, is where accuracy actually lives.
Why context is suddenly everyone’s problem
Model capability is commoditizing fast. Every enterprise now has access to roughly the same frontier models, which means the model itself is no longer the primary differentiator. What differentiates outcomes is what you feed the model. A frontier model with no context guesses at your revenue question. A far smaller model with the right context answers it correctly. The industry conversation has shifted from prompt engineering to context engineering for exactly this reason.
Is this a fad? We argue that it is not. Context is not a workaround for model weakness, so model improvement does not cause it to be obsolete. No future model, however capable, will know your fiscal calendar, your definition of churn, or which of your three customer tables is authoritative. That knowledge does not exist in any public training corpus. It exists in your analysts’ heads, your onboarding conversations, and documents unavailable in a frontier model’s training data.
What will change over time is the form context takes. This will move from ad hoc prompt stuffing towards managed, governed, versioned context layers, and the intelligence that operates over them.
The four types of context
In customer conversations, I find it useful to break context into four types, ordered by increasing distance from the raw physical data:
Technical context describes where the data is physically located, including metastore information, schemas, partitioning, data types, and freshness.
Semantic context describes what the data means, including measures, dimensions, defined joins, and a governed vocabulary. “Revenue” is a specific column with specific aggregation logic.
Business context describes how the business interprets and constrains that meaning, including business rules, entity information, exclusions, the fiscal calendar, and the knowledge that one customer table is deprecated while test accounts must be filtered out.
Operational context describes how to act on all of the above, including codified workflows that use technical, semantic, and business context accurately to complete a task, not merely answer a question.
Two caveats about this taxonomy. First, the boundaries are gradients, not walls. Whether “margin excludes intercompany transfers” is a measure definition or a business rule can be debated. Here, the taxonomy is a tool for thinking, not a rigid hierarchy. Second, the first three types are declarative knowledge, for example, facts about the world. Meanwhile operational context is procedural knowledge, for example, how to execute. This distinction matters when we get to containers.
A worked example: what happens when context is missing
Take the original question: “What was our profit margin last quarter?”
With full context, the system resolves “last quarter” to Q4 of the fiscal calendar (November through January), resolves “profit margin” to the governed measure definition (net revenue minus COGS, excluding intercompany transfers), identifies the authoritative revenue table (not the deprecated one that still sits in the warehouse), applies the exclusion filter for test accounts, generates SQL that enforces all of these constraints, and returns the correct number.
Now remove context at each layer and watch what breaks:
- No technical context: the agent picks the wrong table, or joins on a column with a type mismatch, or queries stale data from a partition that has not been refreshed.
- No semantic context: the agent finds a column called “revenue” and sums it, missing the aggregation logic that requires a weighted average across business units.
- No business context: the agent uses the calendar year instead of the fiscal year, includes intercompany transfers, and counts test accounts. The number is internally consistent and completely wrong.
- No operational context: the agent answers the “what” but cannot execute the follow-up: “break this down by the segments we report to the board, flag any that are below plan, and draft the talking points.”
Each failure mode is qualitatively different. A system that only governs semantic definitions will prevent the second failure and none of the others.
Is a traditional semantic layer enough?
First, credit where credit is due. Semantic layers solved a real problem, and solved it well. Governed metrics, consistent dimensions, defined joins, a shared vocabulary across BI tools. If you have one that is curated well, it is an asset that pays huge dividends. To be precise about terminology, when the industry speaks of a semantic layer, we generally mean the metric definitions, aggregation logic, and dimensional joins popularized by modern data stack tools. That layer remains necessary. But it was designed for a fundamentally different interaction model.
Semantic layers were built for deterministic queries through fixed interfaces, where a human selects from curated options. BI tools disciplined the questions that could be answered. A dashboard offers filters and drill-downs with dropdowns offering curated dimensions. Users learned to ask only what the interface could answer, and semantic layers were scoped to match that disciplined demand.
Conversational AI removed that discipline entirely. When the interface is natural language, people ask questions the same way they talk to a colleague, and nobody talks to a colleague the way they click through a dashboard. Instead, they ask what happened, immediately follow up with why, and then want to know what to do about it.
This single interface shift produces two distinct gaps.
Immediate ambiguity. The chat box invites the long tail of questions a metric store never anticipated. It forces the system to resolve ambiguities that a dropdown used to prevent. For example, the query “show me revenue by region” now requires deciding which revenue, which region hierarchy, and which calendar. It invites questions that span sources the layer never governed, joining CRM activity to warehouse facts.
Functional ceiling. Even a semantic layer with total coverage and zero ambiguity caps out at “what happened.” A semantic layer can tell you which stage of your sales pipeline deals are stalling in. But diagnosing why they stall requires reaching activity-level detail scattered across CRM, email, and unstructured documents, interpreted through tacit business rules. And recommending how to accelerate those deals requires operational context, as well as a codified understanding of the workflow itself. You cannot patch this ceiling by adding more tables to a metric store. Business and operational context need domain ownership, cross-source federation, and a new kind of intelligence layer.
The semantic layer did not fail. Its job changed. It becomes one component within a broader architecture, one that adds the intelligence and closed-loop correction the semantic layer was never designed to provide.
Context intelligence determines what the system must do with context
Assembling a library of definitions, rules, and workflows is necessary but not sufficient. The harder problem is what happens at query time, when the agent must select, rank, and apply the right context from a large and growing inventory. We call this context intelligence. It involves the runtime layer that turns a static context library into accurate answers.
Context intelligence is defined by four capabilities. Some are partially solved in production today Others are active areas of development across the industry. We describe them here as design goals, not as shipped features, because the architecture is converging and the distinctions matter even before every piece is fully built.
Resolution maps natural language terms to governed definitions. When a user says “revenue,” the system must decide which of several revenue measures applies, including gross, net, recognized, or billed revenue. Resolution uses the query, the user’s role, and the data product in scope to select the right one. Without resolution, the agent either picks arbitrarily or dumps every definition into the prompt and hopes the model sorts it out (it will not, reliably).
Schema linking connects resolved business terms to physical data. Once “profit margin” is resolved to a specific measure, schema linking identifies the tables, columns, and joins required to compute it. This is the bridge between the semantic and technical layers. It maps the business concept to the physical execution plan. At scale (hundreds of tables, thousands of columns), schema linking determines whether the agent even looks at the right data.
Ranking decides how much context to inject. More context is not better context. Early production deployments consistently show that agent accuracy degrades when the context window is overloaded with marginally relevant definitions. Ranking scores context elements by relevance to the current query and injects only what the agent needs. The optimal context set is specific to each question, not a fixed configuration.
Attribution traces a wrong answer back to the specific context element that caused it. When the agent returns a wrong number, was it the measure definition, a missing business rule, a bad join, or a stale schema? Attribution identifies the responsible element so it can be corrected. Without it, every wrong answer is a manual investigation. This is the hardest of the four capabilities and the one least solved by the industry today.
These four capabilities are AI problems, not metadata management problems. Resolution requires language understanding. Schema linking requires learned mappings between business vocabulary and physical schemas. Ranking requires relevance scoring under token constraints. Attribution requires causal analysis. This is why context intelligence sits above the semantic layer, not inside it.
Memory and governed context is where learned feedback lives
Context is not a static dictionary. It is a living system that learns from every interaction. But “learns” is a loaded word, and where feedback lives is a design decision with significant architectural consequences.
Two types of feedback continuously flow from agent interactions:
Corrective feedback addresses accuracy. When an agent returns a wrong answer, the correction (exclude test accounts, use fiscal year, fix the join condition) is a candidate addition to governed context. It is a fact about the business, not about the user.
Alignment feedback addresses intent. An answer can be technically correct yet fail to match the user’s implicit need. When a sales director asks about quarterly performance and expects pipeline risk metrics rather than historical revenue, that preference teaches the system intent.
A context system that cannot absorb both corrections and intent alignment is an inventory, not an intelligent system. The critical design question is where each type of feedback is stored and how it is governed. The wrong answer is “put it all in memory.” The right answer requires a clear boundary.
Memory is personal. It stores per-user preferences and disambiguation patterns: “when this user says revenue, they mean gross revenue,” “this user works primarily with EMEA data,” “this user prefers SQL in the response.” Memory personalizes the agent for an individual. It is mutable, ungoverned, and disposable.
Governed context is shared. When a user corrects a definition, that correction is a candidate change to the governed context layer, not a personal memory. It must be versioned, reviewed by the domain owner, tested against existing queries to verify it does not introduce regressions, and promoted into production context only after approval. This is the difference between “the agent learned something” and “the organization’s knowledge base improved.”
Why does this distinction matter? Because without it, feedback goes into a per-user store where it fixes the answer for one person and leaves it broken for everyone else. Worse, memory-resident corrections are invisible to audit, ungovernable, and cannot be attributed when something goes wrong. In regulated environments, an answer produced from ungoverned memory-resident context is an answer you cannot defend.
The architecture we are converging on treats memory as a personalization layer that influences how governed context is retrieved and presented. Corrections and new rules flow into a governed pipeline where they are reviewed, tested, and promoted. The domain expert becomes the approver, not the author, because the system drafts context from feedback at AI speed while governance gates it at human judgment speed.
How context can self-heal
The hardest operational problem with context is not assembling it. It is keeping it accurate as data, use cases, and the business itself change. A definition that was correct last quarter quietly drifts as schemas evolve, metrics get redefined, and the questions users ask keep expanding.
The answer is a closed-loop system that detects, diagnoses, and corrects context drift continuously. We have not seen this shipped end-to-end, but the architecture is well understood, and the components are being built across the industry. The four steps:
- Detect: Score the agent’s responses against known-good test cases. When a previously correct answer starts producing wrong results, flag it as a regression. The test corpus grows organically from user feedback (every confirmed correction becomes a regression test) and from synthetic generation (the system proposes test cases for context elements that lack coverage).
- Attribute: Trace the regression to the specific context element that caused it. Did a schema change invalidate a join? Did a new business rule conflict with an existing one? Did a measure definition drift from its data source? Attribution narrows a system-wide symptom to a specific, correctable cause.
- Correct: Generate a recommended fix and present it for review. The system proposes the change; a domain owner approves or rejects it. The level of automation is configurable: recommend-only for regulated environments, human-approves for most production deployments, fully automatic for low-risk, high-velocity use cases.
- Regress: Before any fix is promoted, run the full test corpus against the proposed change. Verify that fixing one answer does not break others. This is the step that makes correction safe, because context elements are interdependent, and a change to one definition can cascade through dozens of queries.
This loop is what will separate a living context system from a maintained catalog. A catalog requires human vigilance to stay current. A trust loop compounds: every wrong answer that gets corrected makes the system more accurate and more resistant to future drift. The test corpus grows denser where failures have occurred, which is exactly where coverage matters most.
Does this not multiply the maintenance burden?
Skeptics are right to push back here. If organizations already struggle to maintain basic data catalogs, how can they possibly curate and govern business rules and operational workflows across federated systems?
The answer lies in how AI changes the economics of documentation. In the pre-AI era, documenting context meant manual labor, including writing YAML files, updating wiki pages, and populating data dictionaries that were obsolete the moment they were published. It failed because human capacity was the bottleneck on both sides of the interface. In the AI era, context is both human-readable and AI-authorable. Models can scan query histories, parse discussion threads, inspect pipeline transformations, and draft proposed context automatically. The domain expert shifts from manual author to reviewer and approver, and the friction of context capture drops by orders of magnitude.
The same shift addresses velocity. Centralized data teams were acceptable speed bumps when human decision-making was the bottleneck, but AI iterates far faster than a ticket queue. This is where the trust loop matters most. Specifically, corrections and confirmations are captured as candidate context and promoted into shared context only through domain owner review. Feedback moves at AI speed; governance gates it at human judgment speed. This is only viable because AI now drafts what humans once had to author.
Data products and skills operate as the containers for context
If context must be owned, governed, federated, and continuously maintained, what is the right architectural container?
We believe that the container for declarative context (technical, semantic, and business) is a data product. A data product is a curated, owned, contracted unit of data plus its meaning. It is essentially the technical context of its sources, the semantic context of its metrics, and the business context of its rules and entities, packaged under explicit domain ownership. In Starburst, data products provide the flexibility to carry this declarative context across federated sources, so it travels with the data whether that data lives in a lakehouse, an enterprise warehouse, or an operational database.
Operational context, the procedural type, lives with the actor executing the task. In AIDA, it is codified as skills. These skills are explicit, human and machine-readable workflows that define how an AI agent uses a data product’s context (as well as external sources connected to AIDA) to complete complex tasks. The division of labor is deliberate. The data product owns what is true; the skill owns how to act on it.
Both containers are designed to participate in the trust loop. When a wrong answer is attributed to a measure definition, the fix targets the data product. When it is attributed to a flawed workflow, the fix targets the skill. In either case, changes are versioned, reviewed, regression-tested, and promoted through the same governed lifecycle.
When AIDA answers a question or executes a task, it operates within the governed boundary of a data product, enforcing its context at query execution across every underlying source. As skills and learned context mature, AI moves up a deliberate ladder: trusted insights today, recommended actions as operational context deepens, and automated operations as trust is earned.
How context reaches agents using the open contract
Context intelligence is only valuable if it is accessible. The delivery mechanism matters because it determines whether governed context serves one agent or every agent.
AIDA consumes context natively. The same governed context can also be exposed through MCP (Model Context Protocol), an open standard for connecting AI agents to external context and tools. The architectural goal is to create agents, whether built on Claude, GPT, an open-source framework, or a customer’s own harness, that consume the same context through the same contract. The agent is not locked to a vendor; the context is not locked to an agent.
This is the architectural argument for why context intelligence belongs in the platform, not in the agent. If every agent builds its own context retrieval, resolution, and ranking, then every agent also makes its own mistakes, learns its own corrections, and maintains its own (divergent) view of the business. A shared context intelligence layer means one governed source of truth, one correction pipeline, and one set of improvements that benefit every downstream consumer.
Conclusion
Context is not a temporary workaround for model limitations. It is the permanent foundation of enterprise AI. The tribal knowledge that makes your best analyst effective was never in the raw tables, and it will never appear inside a model’s weights.
But context alone is not enough. A library of definitions without intelligence is a catalog. A catalog without a trust loop is a snapshot that decays. The system that compounds, the one where AI gets more accurate over time rather than less, requires all three: governed context, an intelligence layer that selects and applies it precisely, and a closed loop that detects drift and corrects it continuously.
The traditional semantic layer governs one of four context types. Data products and skills provide the governed containers for all four. Context intelligence provides the runtime accuracy layer. And the trust loop ensures the whole system improves with every question asked and every correction made.
The organizations that build this full stack, rather than stopping at definitions, will be the ones whose AI outcomes are worth trusting and worth defending.
Want to know more about how to use Starburst to access your business context? Check out this recent webinar on the topic.
