# Agentic AI in Action — Part 23 — Snowflake Semantic Views: Where AI Agents Earn Enterprise Trust > Source: > Published: 2026-06-30 03:45:18+00:00 Your head of sales asks an agent for Q3 revenue and gets $14.2 million. Your CFO asks the same agent the same question an hour later and gets $12.8 million. Nobody made an error. Both numbers are correct, according to the system that produced them. That sentence is the whole problem. Two correct numbers for one question is not a precision issue, it is a trust issue. And as agents take over more of the asking, this stops being a quarterly footnote and starts being the reason a perfectly good AI initiative quietly loses executive confidence. Snowflake Semantic Views exist for exactly this moment. Instead of revenue being defined separately in a dashboard, a notebook, and an agent’s prompt, it gets defined once, inside the database, and every one of those consumers reads from that same definition. One number, agreed upon once, shown to everyone, whether the question comes from the CFO, the head of sales, or anyone else asking. Metric drift is not new. Sales has always had a slightly different definition of an active customer than finance. A dashboard built two years ago calculates revenue one way, a notebook a data scientist wrote last month calculates it another way, and a spreadsheet somewhere calculates it a third way. For years this was survivable, because a human was in the loop. An analyst would notice the gap, ask around, reconcile it, move on. Agents remove that checkpoint. An agent does not pause to wonder why its number looks different from the one in last week’s board deck. It queries whatever table or view it has access to, applies whatever logic that object encodes, and answers with full confidence. Multiply that by a few dozen agents running continuously across a business, each one happily computing its own version of the truth, and drift stops being an occasional embarrassment. It becomes the default state. The root cause is almost always the same. A metric gets defined once, somewhere reasonable, and then gets recreated by hand everywhere it is needed next. A BI model here. A dbt model there. A hardcoded calculation buried inside a prompt. Every recreation is a fresh opportunity for the definition to drift or diverge a little, and nothing forces those copies to stay in sync. *(Note: Worth being precise about the term “drift” here*, *since it’s easy to confuse with data drift or model drift in the typical machine learning sense. What follows is not always a metric quietly changing over time. More often it is two definitions that never matched in the first place, built independently by two teams who each made a reasonable call about something like refunds. Nothing drifted away from a shared baseline, because there was never a shared baseline to begin with. The industry calls both situations drift, so this blog does too, but it is really a divergence problem as much as a decay problem).* We will smulate a metric divergence scenario and address it by creating a single version of truth by leveraging Semantic views. A semantic view is a schema level object in Snowflake that holds the business meaning of your data alongside the data itself, rather than leaving that meaning to live in a dashboard config, a dbt model, or someone’s memory. Instead of a raw table full of columns like gross_amount and refund_amount, a semantic view defines tables, dimensions, facts, and metrics together, so revenue is not just a column, it is a named, documented, single definition that anyone, or anything, can query consistently. Business logic and metrics get defined once, in SQL, but expressed in business terms rather than raw column math, sitting on top of governed Snowflake tables. From there, that same definition gets used everywhere, BI tools, notebooks, dbt models, applications, and AI agents alike, all reading from the same object instead of each maintaining their own copy. The business impact of that is straightforward too, consistent KPIs, faster time to insight, and decisions people can actually trust, because the analyst, the dashboard, and the agent are no longer capable of disagreeing with each other. The example at the bottom of the diagram above is really the whole point of this article in four steps. A business analyst defines a metric once. That definition becomes a semantic view. Everyone, BI tools and agents included, reads from that same definition. One number, one truth. CREATE SEMANTIC VIEW is the SQL command that builds one, and once it exists, both plain SQL and Cortex Analyst’s natural language queries read from the same object. That is the entire mechanism behind everything in the rest of this article. Before we begin, let us create a dedicated database and schema. We will now import the accompanying notebook. It is worth seeing this fail before talking about how to fix it. The companion notebook to this article walks through four steps inside a Snowflake Notebook. Here is each step, what the code does, and what it shows. This sets up a small ORDERS table, ten rows, two regions, a mix of products, and a refund flag on a few of the rows. The only column that matters for the rest of this is REFUND_AMOUNT, because that is where the drift gets seeded. Real metric drift almost never comes from bad data. It comes from a perfectly reasonable column that two teams choose to treat differently, and this step sets up that exact fork in miniature. This creates two views over the same ten rows. REVENUE_VIEW_BI models an old dashboard that defines revenue as the gross order amount, full stop, because refunds were rare when it was built. REVENUE_VIEW_FINANCE models finance’s own query, which always nets out refunds, because that is what actually lands in the general ledger. Query both and the regional totals disagree, even though both queries are correct SQL against correct data. Neither team did anything wrong, they just never agreed on a single definition. Now picture an agent answering “what was AMER revenue last month” by querying whichever of these two views it happens to have access to. It will not pause to flag the discrepancy. It will just answer, confidently, with one half of the truth. Upon executing this cell, the below output is returned. We see that AMER and EMEA totals disagree across the two outputs. That gap is metric drift, reproduced with ten rows of data. Instead of a third view with a third opinion, this defines revenue exactly once, net of refunds, as a Snowflake Semantic View. CREATE SEMANTIC VIEW is a schema level object, that holds tables, facts, dimensions, and metrics together as one governed definition rather than scattering that logic across views, notebooks, and dashboards. This is one of the more quietly powerful additions to the platform, because it moves business meaning into the database itself rather than leaving it to live in a dashboard config or a person’s memory. There is now exactly one place where what counts as revenue gets decided, and everything after this is just different ways of asking that same object the same question. Querying it is standard SQL, through the SEMANTIC_VIEW() table function introduced alongside semantic views: This pulls total revenue by region straight out of the semantic view using ordinary SQL, no special client or library required. The result matches finance’s number exactly, because finance’s definition is now the only definition that exists. Any new BI panel or new agent built from this point forward points at the semantic view, and the discrepancy from Step 2 structurally cannot recur there. The same semantic view can also be attached to a Snowflake CoWork agent as its Cortex Analyst tool, so business users get this in a chat window instead of opening Cortex Analyst directly. Step 2 left us with two views, two definitions of revenue, and two different answers to the same question. Step 3 closed that gap, but it is worth being precise about how. The semantic view did not average the two numbers or pick a winner between BI and finance. It removed the choice entirely by giving revenue exactly one definition, net of refunds, inside the database itself. AMER and EMEA revenue now have one number each, and that number holds regardless of whether the question arrives as a SQL query, a BI dashboard refresh, or eventually a natural language prompt. The two old views still exist and still disagree with each other if you query them directly, but nothing new gets built on top of them anymore. The drift stops spreading even before anyone gets around to cleaning up the old views. The query from the previous cell proves the semantic view returns the governed number through plain SQL. The next step, asking the same question in natural language, happens in Snowsight , because Cortex Analyst is a conversational interface, not a SQL call. The cell below generates a direct Cortex Analyst (Snowsight) link to the semantic view created in Step 3. The link is built from a few pieces, your organization name, account name, and database, pulled live from the session so it resolves correctly no matter whose account is running it, stitched onto the fixed path that opens the Cortex Analyst editor for SALES_SEMANTIC_VIEW specifically. Paste the output of this cell to a browser, and Snowsight drops you straight into the Cortex Analyst interface with that exact semantic view already selected, with no manual navigation required. Now, ask “what was total revenue by region” in plain English, and Cortex Analyst generates SQL against that same governed object, and returns the precise result as expected. This is the part that actually closes the loop on the opening scenario. The head of sales and the CFO were not asking SQL questions, they were asking an agent a question in plain English, and this step is where the natural language path produces the same number as the SQL path in Step 3, both tracing back to the one definition created there, instead of either of the two conflicting views from Step 2. In essence, Semantic views close the trust gap between your data and your AI agents. A semantic view fixes drift inside Snowflake, for anything that actually queries it. The gap is everything that does not, a Tableau workbook built before the semantic view existed, a dbt model with its own version of the same logic, a calculation that nobody ever repointed. [Horizon Context](https://www.snowflake.com/en/product/features/horizon-context/), announced at Summit 2026, is built to close that gap in three stages. It collects metadata from external systems like Postgres, Tableau, Power BI, and dbt, separately enriches that metadata with lineage and documentation, and activates that enriched context through search so AI agents such as CoCo can discover and prioritize the appropriate governed semantic view rather than relying solely on inferred business meaning. The piece that connects to those external systems, Metadata Connectors, is the part still in private preview as of this writing. Other pieces carry different status tags, so it is worth checking Snowflake’s release notes for the specific capability you care about rather than treating Horizon Context as one single release. Most conversations about AI accuracy start in the wrong place. Someone asks whether the agent is hallucinating, whether the model needs fine tuning, whether a better prompt would help. Those questions matter, but they are not always where the answer lives. Just as often, the real question is less interesting and more important. Is there one definition of this metric, or are there multiple? An agent that confidently hands you one of two correct numbers is not making a mistake. It is just answering from whichever definition it happened to land on. That is not a model problem, it is a single source of truth problem wearing an AI costume. Fix the source of truth, and the agent stops getting it wrong, because it no longer has two different truths to choose from. *That’s exactly where semantic views come in. **Give the truth one home, and every agent that visits, finds the same one.* The companion Jupyter notebook for this blog can be accessed [here.](https://github.com/Krishsriniv/agent-trust-with-snowflake-semantic-views) *I share hands-on, implementation-focused perspectives on Generative & Agentic AI, LLMs, Snowflake and Cortex AI, translating advanced capabilities into practical, real-world analytics use cases. Do follow me on **LinkedIn** and **Medium** for more such insights.* [Agentic AI in Action — Part 23 — Snowflake Semantic Views: Where AI Agents Earn Enterprise Trust](https://pub.towardsai.net/agentic-ai-in-action-part-23-snowflake-semantic-views-where-ai-agents-earn-enterprise-trust-17aa8e509d76) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.