Why “Talk to Your Data” Is Table Stakes — and Why the Winners Will Build Context, Not Just Models
For those of us who have worked in data for decades, the recent explosion of interest in "context layers" is both vindicating and fascinating. These are not new concepts; they are foundational principles of computer science. The reason semantic layers are resurfacing is that most enterprises are discovering the same uncomfortable reality: The models sound smart, but they still produce confident wrong answers.
That failure mode is less of a model reasoning problem as models have become significantly smarter and will continue to improve; the bottleneck is going to be the right context.
In a controlled demo, an agent can look brilliant. In an enterprise, it’s forced to operate in a landscape where business concepts are fragmented, rules are implicit, history is missing and “truth” is often contested across systems.
The real work of an analyst is multistep, cross-domain and political. Business leaders ask for “whys” and “whats” and not just SQL queries:
“Find what changed, explain why, and recommend what to do.”
“Compare two definitions, reconcile conflict, and produce a board-ready narrative.”
“Investigate an anomaly and link it to the operational events that caused it.”
This is where enterprise reality shows up:
Siloed meaning: “Customer” means different things in different systems.
Missing why: Warehouses capture state, not the decisions and debates that made state true.
Implicit rules: Fiscal calendars, eligibility criteria, approval policies and banned metrics are often scattered and tribal.
Conflicted truth: Finance and CRM can both be “trusted” and still disagree.
So the main question has changed from “Can a model generate SQL?” to “Can an agent operate inside your enterprise’s meaning, policies and history — and prove it did?”
Definitions: The minimum vocabulary for trustworthy agents
First, let’s establish some core concepts:
Analytic semantic model: An interface for analytics that defines metrics, dimensions and entities, mapped to physical data so users do not need to know schemas or SQL.
Relationship and identity layer (often called “ontology” in the enterprise): A machine-readable representation of concepts, relationships, and rules across domains — plus identity resolution, synonym handling and constraints — so that cross-domain integration is safe and explicit. (This can be OWL/RDF, a curated join graph or concept bindings to governed data products.)
Business procedures: Versioned operational playbooks that specify how work should be done, including routing, approvals, exceptions and policy enforcement.
Evidence and provenance: The trace behind an answer, including sources used, transformations applied, lineage of data sources and why competing sources were accepted or rejected.
Policy and entitlements: Machine-enforceable rules that determine what a user (or an agent acting on their behalf) is allowed to retrieve, compute and disclose.
Semantics and agent context: Old ideas, new urgency
Semantic models and ontologies are not new. Enterprises have pursued consistent meaning for decades through BI semantic layers, master data management (MDM), catalogs and knowledge graphs. Ontologies also matured in domains such as life sciences and healthcare, where complex biomedical concepts and standardized clinical terminologies create a naturally graph-shaped world. It’s also clear that interest in semantic layers and ontologies is spiking (see Figure 1).
The timing makes sense, because they complement LLM-powered agents in a few specific ways. For instance:
LLMs can interpret intent and reason over ambiguity, but they are usually missing enterprise context. Semantic models and ontologies encode that context in a reusable form.
LLM outputs are probabilistic; semantic artifacts are grounded and verifiable.
Semantic artifacts have historically been expensive to build and prone to drift; natural-language interfaces and agent tooling make it more feasible to generate, curate and keep them current.
At the same time, “ontology” is not the goal. The goal is a high-quality data agent. Natural language becoming a practical front door shifts what the system must provide. It’s no longer enough to translate a question into SQL. The agent needs a context layer spanning semantics, identity, constraints, policy and provenance.
This is the inflection:
Models made “text → data” plausible.
Agent context makes agentic analytics trustworthy.
A semantic analytic model is best at delivering trusted analytics within a domain by standardizing metrics and definitions. Cross-domain work becomes reliable when the agent also has an explicit relationship space, identity resolution, joinability and constraints, whether implemented as a formal ontology, a curated join graph or bindings from concepts to analytics objects.
The practical focus should be to borrow from ontologies and semantic layers where they help, but optimize for what agents actually need to operate well in enterprise reality.
A practical architecture for trustworthy data agents
Moving toward multistep reliable agentic analytics requires reasoning that is grounded in governed semantics, explicit relationships and auditable decisioning. For an enterprise-grade agent, you need a combination of these layers to work together.
Analytic layer
The analytics layer provides metrics, dimensions and entities mapped to physical data. Metric definitions (filters, joins and formulas) live in one place and are reused across agent experiences. Semantic views act as a curated and governed interface to the analytic layer that also ensures safe analytics.
Natural language questions such as “revenue” or “NRR” need to map to a specific metric definition, including the right filters (for example, “Closed Won only”), default time windows and allowed grains.
Relationship and identity layer (ontology): Concepts and bindings
This layer defines canonical entities (such as Customer, Account or Incident) and the typed relationships between them, plus bindings into the data world (IDs, semantic objects, tables). It also includes synonym/alias handling and identity mappings across systems.Cross-domain questions often require linking the same real-world entity across systems with different identifiers (for example, CRM account ID vs. support org ID). This layer provides that mapping and the relationship structure needed to connect domains.
In an internal experiment, we created a query set that requires multiple semantic views to answer. We measured performance by final answer accuracy, total latency and number of tool calls. We found that simply augmenting the agent with a plain-text “data ontology” (join keys, table grains and cardinality/fanout hints) improved final answer accuracy by +20%, reduced average tool calls by about 39% and improved end-to-end latency by about 20%, compared to a best-practices baseline.
Here is the query set:
Operational playbooks (directives): Procedure and routing
This is a managed set of instructions describing how the agent should handle certain intents: routing to authoritative sources, required disambiguation steps and required checks (for instance, “pricing must use certified tables” or “win rate is disallowed”).
Some questions require consistent procedural handling. Playbooks provide a standard approach across users and channels (agent, BI assistant, embedded app):
Provenance and explainability: What was used and how
This layer provides an inspectable record of how an answer was produced: semantic objects selected, filters applied, joins executed and timestamps/freshness established. For conflicts, it can include which source was chosen and the rule used.
Users often ask follow-ups such as “How was that computed?” or “Why is it different from another report?” Provenance gives a consistent basis for answering those:
Event and decision memory: State and rationale
This layer stores event trails and decision artifacts linked to business entities: approvals, incident timelines, change events and related tickets/threads. The memory can be incorporated in the form of analytics (such as the right way to join), business concepts (such as a change in a metric calculation), reconciliation (when to trust what information when there are conflicts) and so on. This provides evidence for “why” questions. Many workflows require explanations grounded in operational history, not just current state.
Why this isn’t prompt engineering
It’s tempting to believe clever prompts can replace agentology. In practice, prompt-only systems collapse at scale: They’re opaque, hard to audit and drift over time.
An agentology approach gives you durable, governable artifacts:
Change control, with reviewable, versioned rollouts
Auditability, with explainable routing decisions, joins and definitions
Interoperability, with one semantic foundation powering BI tools and agents
Governance, where rules become enforceable constraints, not best-effort instructions
Reusability, allowing for concepts to be modeled once and reused in different contexts without duplication.
Agent context creation and maintenance: How AI changes the economics
With the rise of powerful agents such as Cortex Code, the task of building and creating agent context has become more feasible. Most business semantic layers were hard for simple reasons: They’re expensive to build, go stale quickly and do not evolve at the speed of the business. However, with AI agents the workflow can be much simpler, where the agents can read documents, knowledge graphs, ontologies, chats and other systems of records to create context and keep it fresh.
A very simple AI agent workflow can look like the following:
Start with an agent and a curated semantic layer (leveraging existing dashboards and query history).
Add layers of agent context from existing sources: metadata of existing tables, historical queries and usage patterns, docs, playbooks, existing ontologies and code pipelines. This should already create a very strong agent.
Learn from real usage patterns.
Propose improvements, including synonyms, mappings and missing relationships.
Keep humans in the approval loop.
Continuously reduce cost while increasing coverage.
Predictions and closing thoughts
Here are some of the ways we expect to see this space evolve in the future:
Winning architectures will treat “agent context,” and not the model, as the core product as the model gets commoditized.
The most successful agents will focus on the business problem to solve rather than indexing on a single artifact like an ontology.
Semantic models will continue to anchor governed metrics and trusted domain analytics. As agents become primary consumers of this context, the pressure to keep these layers current, aligned and machine-readable will increase, turning them from static documentation artifacts into living, actively managed assets.
There will be an increased investment in generation and continuous evolution of agent context layers powered by AI agents like Cortex Code.
As adoption scales, we expect standards to emerge that promote cross-platform interoperability and make these context layers easier for LLMs to interpret and operationalize consistently across tools and ecosystems. Efforts like the Open Semantic Interchange (OSI) are aimed at enabling this type of interoperability.
Overall, we believe there will be a renewed interest in metadata and catalog initiatives. These layers will increasingly be co-maintained by humans and agents.
Continue the conversation
If you are a data executive building agents that require complex context and cross-domain orchestration, we invite you to explore our latest developments:
- Semantic views: Learn how to build the foundation for cross-domain orchestration.
- Snowflake Intelligence: See how we incorporate business guardrails into a unified intelligence layer.
We are looking for strategic design partners to collaborate on the next generation of expressive semantic layers and Snowflake Intelligence. If you're interested in building and iterating on Cortex Agents with us, please complete this brief form to see if your use case is a fit for the program.