Snowflake: Semantic Governance, Key to Reliable AI Agents

Snowflake: Semantic Governance, Key to Reliable AI Agents

This year, many data teams have integrated AI agents into their roadmaps. The excitement is palpable: an agent capable of transforming a two-day analysis into a two-minute conversation can revolutionize collaboration between analysts and business teams.

However, agents are only reliable if the underlying data foundation is solid. If they are directed towards raw tables or outdated metadata, they may appear convincing while being incorrect. This article presents a practical framework for generating and deploying governed semantic views on Snowflake.

Why Agent Quality Deteriorates

Three failure patterns frequently emerge when agents transition from demonstration to production:

• Governance is sacrificed for speed. Teams under pressure to deliver overlook data integrity and access control issues until an agent is already answering questions for the business.

• Duplication proliferates. Without a shared process, different teams build overlapping agents that answer the same question in subtly different—and inconsistent—ways.

• Responses are non-deterministic. The same question asked twice returns two different figures. This is worse than being systematically wrong, as no one knows when to be wary of the answer.

All these issues stem from a root cause: there is no standardized and enforced process governing the creation, revision, versioning, and promotion of a semantic definition. Tools that help draft semantic views more quickly do not solve this problem on their own—speed and governance are two different axes, and an organization can have a lot of one and little of the other.

What a Semantic Layer Actually Does

Ask five teams, "What is the total number of active members in Q1 2026?" without a shared semantic layer, and you will get five different figures. Each team applies its own filters, joins its own tables, and defines "active" differently—and an LLM that asks the same question without reference hallucinates a sixth answer that seems just as confident as the other five.

A semantic layer solves this problem by placing itself between the raw warehouse and each consumer—dashboards, spreadsheets, and now AI agents—and answering three questions the same way, every time: which tables contain this data, what filters apply, and what is the logic and granularity of aggregation. Snowflake's documentation presents this as a response to the gap between how business users describe data and how it is actually stored in database schemas—for example, defining "net revenue" once, consistently, as SUM(gross_revenue * (1 - discount)), rather than allowing the calculation to be reinvented in every report.

Where This Fits in Snowflake

In Snowflake, the semantic layer is implemented in the form of a semantic view, an object at the schema level stored directly in the database that defines business metrics and models entities and their relationships, which Cortex Analyst—Snowflake's text-to-SQL tool—can then query in natural language. Cortex Agent is the AI orchestrator that holds one or more semantic views, alongside search services and custom tools, and decides which resource answers a given question—the same architecture supporting Snowflake CoWork (formerly Snowflake Intelligence).

Here is what this specification looks like filled out with a real example. Below is a semantic view on a SaaS billing dataset—two logical tables (billing and customers), joined on the customer ID, with three certified revenue metrics defined once:

• name: SAAS_BILLING
• description: Combines customer records with subscription billing details to support certified metrics MRR, net MRR, and lost revenue.
• base_table: { database: FINANCE, schema: ANALYTICS, table: FCT_SAAS_BILLING }
  • name: BILLING_DATE
    • expr: BILLING_DATE
  • name: PLAN_TYPE
    • data_type: VARCHAR(20)
  • name: MRR_AMOUNT
    • expr: MRR_AMOUNT
    • data_type: NUMBER(10,2)
  • name: TOTAL_MRR
    • expr: SUM(billing.MRR_AMOUNT)
    • expr: SUM(billing.MRR_AMOUNT) - SUM(billing.DISCOUNT_AMOUNT)
  • name: CHURNED_REVENUE
    • expr: SUM(IFF(billing.IS_ACTIVE = FALSE, billing.MRR_AMOUNT, 0))
    • primary_key: { columns: [BILLING_ID] }
• name: CUSTOMERS
  • base_table: { database: FINANCE, schema: ANALYTICS, table: DIM_CUSTOMERS }
  • name: COMPANY_NAME
    • expr: COMPANY_NAME
    • data_type: VARCHAR(100)
  • name: INDUSTRY
    • data_type: VARCHAR(50)
    • primary_key: { columns: [CUSTOMER_ID] }
  • name: CUSTOMER_BILLING
    • left_table: BILLING
    • right_table: CUSTOMERS
    • relationship_columns:
      • { left_column: CUSTOMER_ID, right_column: CUSTOMER_ID }

What is not in question is that this object works. What is in question is: how is a semantic view like this created in the first place?

The Two Pillars of Governance Behind Each Certified Metric

Before the pipeline itself, it is helpful to be precise about the two governed inputs it depends on.

• The Data Catalog: An authoritative source for business descriptions, data types, sensitivity labels (PII/PHI), example values, and certification status for each column and table. In this implementation, it is Snowflake Horizon—labels are defined at the column or table level. The catalog contains data type, description, synonyms, example values, etc., and a dynamic masking policy can restrict who sees a flagged column. A label certification_status = 'Certified' is the green light for the metadata of that column to be used in a semantic view.

• The Metric Inventory: A single governed repository for each metric formula, with a description, business owner, source table, domain, sensitivity classification, and most importantly, a certification status. The operational rule: each metric is defined once and reused everywhere, and "once" is conditioned on actual approval from a domain owner or data steward. This is what will resolve the issue of the same metric being answered in six different ways within teams.

The Framework: A Governance Harness for Generating Semantic Views

The central idea is simple to state: treat the generation of semantic views as a governed software launch, rather than a one-off modeling exercise. In practice, this means five components, each applying a rule that an informal process typically leaves optional. Before reviewing each of them, it is helpful to see the entire end-to-end pipeline, and then how this pipeline fits into the broader architecture of Snowflake.

Governance Framework Flow Diagram

Stepping back a level: this pipeline is only half the picture at the time of construction. Figure 2 shows how it integrates with the systems that actually consume its output—Cortex Analyst, Cortex Agents, Snowflake Cowork, and the BI tools discussed later in this article.

System Architecture

The complete code for breaking down the components below is here.

Component 1 – Context Extraction

An orchestration script connects to Horizon and the metric inventory and extracts, for a given domain, only certified metric formulas and labeled schemas. This step is deterministic—it retrieves already approved facts, it infers nothing:

[cursor](/outil/cursor).execute(f"""
SELECT metric_name, description, expression, base_table
FROM GOVERNANCE_DB.SEMANTICS.METRIC_INVENTORY
WHERE certification_status = 'Certified'
AND base_table IN ({table_list})
{"metric_name": r[0], "description": r[1], "expression": r[2], "table": r[3]}
for r in cursor.fetchall()

The process extracts the schema and context of labels directly from the label references in Horizon.

catalog_query = f"""
WITH physical_schema AS (
SELECT table_schema, table_name, column_name, data_type, comment AS column_description
FROM {database}.INFORMATION_SCHEMA.COLUMNS
WHERE table_schema IN ({schema_list}) AND table_name IN ({table_list})
horizon_tags AS ( {real_time_tags_cte} )
SELECT p.table_name, p.column_name, p.data_type, p.column_description, t.tag_value AS privacy_tag
FROM physical_schema p
LEFT JOIN horizon_tags t
ON p.table_name = t.table_name AND p.column_name = t.column_name

This is the first structural difference from usage inference approaches that should be clearly stated: this pipeline only proposes definitions that relate to a pre-approved source, rather than a definition highlighted because it was the most common model in someone's query history. Popularity is a useful discovery signal; it is not the same assertion as governance approval.

Component 2 – Constrained Generation

A chosen LLM (Claude, GPT, Qwen, GLM, etc.) converts the extracted context into a strictly formatted dbt model using the dbt_semantic.