Building a Context Layer for AI Agents | Snowflake

Building a Context Layer for AI Agents | Snowflake

Skip to content

Blog / Product and Technology / Building an Internal Context Layer for AI Agents at Snowflake

AUG 17, 2026 / 7 min read Product and Technology Copy post link Open in Claude Open in ChatGPT

Building an Internal Context Layer for AI Agents at Snowflake

Aniruth Narayanan

Modern enterprises collect and manage millions of data sources and signals across their business. At Snowflake, we use Snowflake internally to monitor our business systems and product telemetry at scale — across every query, warehouse and click. But without a shared understanding, petabytes of raw data become a source of conflicting answers, not a foundation for action.

To leverage our data at scale for both humans and AI agents, we curate an internal semantic layer. This post covers how we built our context layer using semantics and the best practices we learned in the process.

Figure 1: Snowflake’s internal environment uses a semantic layer to empower every entity to query consistent and accurate data.

The bottleneck was never the data — it was context

The immense amount of internal telemetry makes it incredibly powerful, but that same scale makes failure modes frustrating. Take a seemingly simple question such as “What is an active customer?” That question could yield different answers across different tables and varying metric definitions:

Active is WHERE days_since_last_login 0 and account_type != ‘TRIAL’ from the table customers

Active is COUNT(DISTINCT account_id) without a region identifier from the table customers_with_accounts

Typically, based on our internal use cases and what we have seen from our customers, the burden of clarifying data’s meaning falls on data science teams: Humans design queries and confirm these queries with a trusted data scientist, who calls out flaws and gotchas.

The alignment problem becomes exponentially worse with AI. New metrics and data sources are built at lightning speed, creating information gaps for even skilled analysts. If a Cortex Agent reports one number while a legacy dashboard shows another, no one knows which source to trust.

One definition for every AI and BI interface

Every interface needs consistent meaning, or context, for its data, which can be achieved by using a semantic layer. A semantic view is a top-level object that sits between the downstream consumers and raw data tables, translating governed business language into physical database schemas.

Instead of exposing raw tables to dashboards or AI agents directly, the semantic view standardizes the data flow from physical tables to facts, dimensions and metrics. This gives people and tools consistent context about what the data means before they query it.

Figure 2: Semantic views consist of logical names, metrics and AI metadata on top of physical tables to power downstream consumption.

AI agents gain two benefits when using semantic views to query data at scale:

Faster execution: Agents querying raw data spend time finding, understanding and sampling multiple data sources. At scale, these processes can dominate runtime. Instead, agents can use semantic views to go directly to SQL execution.

Lower cost: Agents are significantly more token-efficient when using table relationships and join data in semantic views. With materialization, semantic SQL natively leverages preaggregated data, reducing repeated computation.

With a semantic-oriented data architecture, returns compound quickly across the stack:

Increased accuracy: Provide precise business context to models. In AtScale’s benchmark testing , adding semantic context increased text-to-SQL accuracy from 20% to more than 90% across 40 business questions on TPC-DS.

One source of truth: Replace isolated, tool-specific semantics with a single semantic layer.

Free governance: Leverage Snowflake’s access controls on semantic views and metric objects natively.

True self-service: Support ad hoc, natural-language questions for any user on their own.

"With semantic views we get a golden layer, a single trusted API for our data. With semantic view materializations, this one semantic API now works for every downstream consumer of our data, including use cases where query performance is critical. Now queries from dashboards, AI and ad hoc workflows can run through the same trusted data API."

Zachary Blackwood

Staff Data Scientist at Snowflake

Snowflake’s internal product data science team uses an agent that leverages the internal semantic layer to field product questions from across the company. In July 2025 alone, more than 400 distinct internal users ran over 5,400 queries through the product data science agent and the semantic layer. And in the same time frame, more than 5,600 internal employees across all Snowflake teams and agents ran over 320,000 queries using the broad semantic layer in sales, HR, support and other areas.

Figure 3: With a unified semantic layer, all tools and interfaces get one consistent, governed meaning of data.

Best practices for the semantic layer

Version, test and evaluate semantic views

The semantic layer needs to be treated with the same rigor as production software. With Snowflake’s native data build tool (dbt) integration, we’re able to fully version control, peer review and apply continuous integration and continuous delivery (CI/CD) to our metrics. Though at Snowflake we primarily build semantic views using code, we use the UI to test and suggest improvements that integrate with our code. And because the UI and underlying code are perfectly synced, users can move between constructing a view in the Snowflake UI and committing fields to repositories easily.

To evaluate semantic views, we needed access to the questions that people actually ask. A high-signal source for evals is popular dashboard tiles, which are constructed and used precisely to answer questions. We also log common questions to refine our eval sets.

Prioritize performance with data engineering

If your semantic layer sits on top of slow queries and poorly constructed tables, your AI agents will be slow. Early on, we tried pointing a semantic view at multiple raw, billion-count event tables. Every time a user asked a question, the view crawled and joined these tables, resulting in massive latency.

Initially, we built and maintained our own preaggregated slices with Dynamic Tables. Each dashboard had the rollup and grain that it needed. However, as we expanded our...