- RAG retrieves passages. Agents acting on a business also need its meaning: governed definitions of metrics and entities, how they relate, where the data came from, how fresh it is and who may see it. That is the context layer, and in 2026 it became a product category and a strategic battleground for data, application and AI platforms.
- Data agents are the forcing function. Text-to-SQL over a raw warehouse fails on semantics rather than syntax: the model writes valid SQL against the wrong definition of revenue. Grounding agents in certified metrics, verified queries and enforced permissions is what makes their numbers trustworthy.
- Own your semantics even if you rent the platform. Keep definitions in portable, versioned form (the Open Semantic Interchange, now incubating at Apache as Ossie, is the emerging standard), run context as a product with owners and certification, and make every agent answer traceable to the definitions it used.
Why retrieval is not enough
Retrieval-augmented generation answered a particular kind of question well: what does the travel policy say, which contract clause covers termination, what did the last incident report conclude. Agents ask a different kind. "What was net revenue retention for enterprise customers in EMEA last quarter, and which accounts drove the decline?" To answer that correctly, a system needs to know which customers count as enterprise, how net revenue retention is calculated and what it excludes, which fiscal calendar applies, which tables hold the authoritative figures, how fresh they are, how accounts roll up to parent companies, and whether the person asking is allowed to see account-level detail.
Almost none of that is written down in documents in a form a model can use. A retrieval pipeline might surface the finance memo that defines the metric, but the agent then has to re-derive the logic from prose, slightly differently each time, against tables it has to guess at. The answers that result are fluent, formatted and quietly inconsistent.
The context layer is the missing piece: a governed, machine-readable model of what the business means, served to agents at runtime. It is the semantic counterpart to the retrieval layer, and in 2026 it stopped being an architect's abstraction. At its June 2026 summit Databricks launched an ontology it describes as a self-improving knowledge graph, built from an enterprise's tables, queries, dashboards, pipelines and connected applications, as the context layer behind its AI coworker and data agents. CRM, data-cloud and hyperscale vendors announced their own versions within months. The rush has a simple explanation: whoever holds an enterprise's context is well placed to hold its agents.
What a context layer contains
Vendors package it differently, but a useful context layer holds seven kinds of knowledge, most of which enterprises already have in fragments:
| Component | What it captures | Example |
|---|---|---|
| Semantic model | Metrics, dimensions, calculation logic, calendars | Net revenue is gross bookings minus credits, excluding intercompany |
| Ontology or knowledge graph | Entities and how they relate | Customer to account to contract to invoice; subsidiaries roll up to parents |
| Business glossary | Terms, synonyms and owners | "Logo" and "customer" mean the same thing in sales and different things in finance |
| Verified queries | Certified question-to-query pairs | The approved SQL for "active customers", edge cases included |
| Lineage and quality | Sources, transformations, freshness, test status | Refreshed three hours ago; two quality checks currently failing |
| Access policy | Who may see which rows, columns and metrics | Regional managers see only their region; compensation fields masked |
| Usage signals | Which definitions and queries people actually use | The official churn metric nobody uses, and the one everybody does |
Semantic models already exist in BI tools and metrics layers, glossaries in data catalogs, lineage in pipeline tooling and access policy in the warehouse. What is new is assembling them into one service that agents can query at runtime and that answers with permission-aware, provenance-carrying responses:
SOURCES warehouse | lakehouse | SaaS apps | documents
|
v
CONTEXT LAYER
+-------------------------------------------------------+
| semantic model | ontology / graph | glossary |
| verified queries | lineage, quality | access policy|
+-------------------------------------------------------+
|
served via API and MCP, permission-aware
|
v
CONSUMERS data agents | assistants | BI | applications
|
v
ANSWERS each one cites the definitions, sources and
as-of time it was computed from
The ontology row overlaps with the knowledge graphs in the GraphRAG deep-dive, and the two are converging. GraphRAG builds graphs from unstructured text to improve retrieval; an enterprise ontology models structured business meaning. Mature context layers link both, so an agent can move from "this contract clause" to "this customer's revenue under it" without guessing at the join.
Data agents and the text-to-SQL trap
Conversational analytics is the use case that exposes the gap fastest. Text-to-SQL demos look superb on a tidy sample schema. Real warehouses have thousands of tables, cryptic column names, four candidates for "revenue", soft-deleted rows, fiscal periods that disagree with calendar ones and filters that every analyst knows and no schema records. Benchmarks built from real enterprise schemas have repeatedly shown raw text-to-SQL breaking down at this scale, and the failures are the dangerous kind: syntactically valid queries that return confident, formatted, wrong numbers.
The pattern that works inverts the problem. Instead of asking the model to derive business logic from raw tables, the agent asks the semantic model for a certified metric whenever one exists, and falls back to generated SQL only with help: the relevant schema subset, verified example queries as few-shot guidance, and the governing definitions in context. It shows its work, returning the definition used, the query run and the freshness of the data. When no certified definition exists, it says so or asks a clarifying question rather than inventing one.
Guardrails for data agents are mostly database guardrails. Use read-only credentials. Enforce row- and column-level security in the database, never in the prompt. Cap query cost, run time and result size. Keep sensitive columns out of reach unless the requesting user is entitled to them. Evaluate against a golden set of real business questions with certified answers, scoring numeric correctness rather than fluency, in the spirit of the RAG evaluation deep-dive.
Context as a product
The risk with context layers is the history of data catalogs: built once with enthusiasm, never maintained, quietly abandoned when nobody trusted them. The corrective is to run context as a product. Each domain has an owner, so finance owns revenue definitions and HR owns headcount definitions. Definitions carry a certification status. Freshness has a service level. Changes go through versioned review. And agents are treated as the product's most demanding customers.
Agents also supply something catalogs never had: a feedback loop. Every question an agent cannot answer, every clarification it has to ask, every correction a user makes and every query it falls back to writing from scratch is a signal of a missing or wrong definition. Platforms that mine query logs and usage to propose new definitions automatically are useful for discovery, but an auto-learned definition is a hypothesis until a human owner certifies it. The foundations here are the same ones the data readiness deep-dive describes, now with a runtime consumer that notices immediately when they are missing.
Platform-native or standalone
The build decision has three shapes. Platform-native context layers from data platforms and business-application vendors are tightly integrated with that vendor's data and agents and offer the fastest time to value. Their risk is that your business definitions become proprietary metadata inside one system, invisible to agents running elsewhere. Standalone layers built on catalogs and semantic-layer tools span platforms and preserve portability at the cost of more integration work. The hybrid that most large enterprises will land on authors definitions once, as versioned artifacts the enterprise controls, and synchronizes them into each platform's native layer.
Standards are starting to make the hybrid practical. The Open Semantic Interchange, launched in September 2025 by Snowflake with Salesforce, dbt Labs, BlackRock and RelationalAI among others, published a 1.0 specification in January 2026 and in June 2026 was donated to the Apache Software Foundation, where it is incubating as Apache Ossie with more than sixty participating organizations. It is early, and support varies by tool, but it points the right way: definitions as portable files rather than vendor state.
However it is built, the layer should be served through interfaces any agent can use: APIs for applications and MCP servers for agents, with responses filtered by the caller's entitlements. The integration patterns deep-dive covers the plumbing.
Governing context
Context is a control surface as well as a convenience, and five governance rules keep it one. Agents inherit the requesting user's entitlements, and the layer filters both definitions and data by policy, following the principal model in the identity and tenancy deep-dive. Every answer is traceable to the definitions, query, sources and as-of time behind it, which serves audit and user trust alike, as the grounding and citations deep-dive argues for text. Quality and freshness signals propagate into answers, so an agent says when its source failed a check. Definition changes are managed like schema migrations, because changing how churn is calculated changes every agent's answer at once. And usage is monitored for drift, the slow divergence between the definitions in the layer and the spreadsheets the business actually runs on.
The architect view
The context layer is where data architecture and AI architecture finally meet, and it gives enterprise architecture's oldest artifacts, the business glossary, the information model, the capability map, a runtime consumer for the first time. That makes it one of the highest-leverage investments an AI program can make, and one of the easiest to get wrong by handing it wholesale to whichever platform shipped one first.
Four commitments make it concrete. Start with the twenty to fifty metrics and core entities agents are actually asked about, and certify each one with a named owner. Author definitions as versioned, portable artifacts and synchronize them into the platforms you use. Route data agents through the semantic layer, and require every answer to cite the definitions it relied on. And treat agent questions, clarifications and corrections as the backlog for the context product.
Models will keep getting better at writing SQL. They will not get better at knowing what your CFO means by revenue unless you tell them, in a form they can read and you can govern.