Where metric definitions live for AI agents

When an analyst writes a query, the definition of an active customer or of net revenue comes from somewhere the analyst knows, such as a dbt model, a Power BI measure or a line in a specification. An agent that generates a query from a question has no way to know which definition the business intended unless it has been given one. If two layers hold different versions of the same metric, the same question can return different figures from two agents, or from one agent with access to both, and a reader who looks only at the number cannot tell which definition produced it.

Snowflake, Databricks and Microsoft now keep metric definitions as governed objects that their agents read directly. For a data leader, the practical questions are which of those objects is the system of record, and how anyone checks that an agent's answers agree with it. We recommend naming one system of record for each metric and testing every agent against a question set kept outside any single platform.

What each platform provides

Snowflake semantic views, generally available since August 2025, are schema-level objects that hold logical tables, relationships, facts, dimensions and metrics. Cortex Agents currently read the semantic view definition and then generate SQL against the physical tables, so a generated query restates the metric logic itself and does not run through the semantic view. On 28 August 2026 Snowflake recommended that customers move from the standalone Cortex Analyst API to Cortex Agents, and its note confirms that the REST API remains available and that semantic views carry over unchanged. Definitions can be kept under Git version control through Semantic Studio or managed declaratively with DEFINE SEMANTIC VIEW in DCM Projects, both generally available since 30 September 2026. A Snowflake Labs dbt package, dbt_semantic_view, also lets a dbt project define and deploy semantic views, although the definitions are written in Snowflake's semantic view syntax and are not translated from MetricFlow.

Databricks metric views are YAML definitions in Unity Catalog that separate measures from the fields used to group and filter them. Every measure is queried through the MEASURE function, which takes its aggregation from the definition. Genie Agents (formerly Genie Spaces) and AI/BI dashboards both use metric views. Sharing metric views with Databricks users in other metastores or accounts through OpenSharing became generally available on 24 September 2026, and window measures such as running totals followed on 6 October 2026.

In the Microsoft stack, the Power BI semantic model holds the definitions. Microsoft's Prep data for AI feature, still in preview, adds an AI data schema, AI instructions and verified answers to the model, and both Copilot and Fabric data agents use them. Instructions written on a Fabric data agent are ignored when the agent queries a semantic model, so guidance about the model has to be stored on the model. Prep data for AI also requires Q&A to be enabled on the model, and Microsoft's own pages give two different retirement dates for Q&A, February 2027 on one and December 2026 on another. The page that gives December 2026 also says a replacement setting will support the instance value indexing that currently depends on Q&A, so we recommend testing models that use these features again when that setting arrives.

dbt's MetricFlow, licensed under Apache 2.0 from version 0.209.0, defines metrics in YAML inside the dbt project. The hosted dbt Semantic Layer requires an account on the Starter or Enterprise tier.

Choose one system of record

An organization that uses more than one of these products is likely to find the same metric defined in several places. The agents' configuration can add further copies, because Snowflake verified queries, the example SQL and SQL expressions in a Genie Agent, and the AI instructions on a Power BI model can each restate a metric's logic. Each copy tends to be maintained by a different team on a different release cycle, and the copies drift apart.

We recommend naming one layer as the system of record for each metric and making every change there first. Where a documented conversion exists, run it again after each change and compare the generated copy's results with the original. Where none exists, maintain the copy by hand, review it in the same change as the definition and test it against the system of record.

The right layer is usually the one where the metric owner already reviews and approves the definition. Where finance signs off on DAX measures in Power BI, Snowflake can create a semantic view from an uploaded .pbit or .pbix file and convert the supported DAX measures into metrics, a feature that has been generally available since 18 August 2026. Snowflake's documentation lists DAX features that the conversion does not fully support, among them report-level measures, time intelligence functions such as SAMEPERIODLASTYEAR, SELECTEDVALUE, RANKX, calculated tables and calculation groups, so the metric owner should compare the generated metrics' results with the Power BI figures before the view is used. Databricks also documents a Genie Code route that creates a metric view from a Tableau file or a Power BI .pbit or .tmdl file, but its page does not say how measures are translated, so the output needs the same comparison of results.

Portability between platforms has improved during 2026. The Open Semantic Interchange was announced by Snowflake on 23 September 2025 with a launch coalition of 17 organizations, Snowflake among them. On 27 January 2026 Snowflake announced that the first version of the specification had been published, and the project entered the Apache Incubator on 22 June 2026 under the name Apache Ossie (Incubating). Snowflake has a preview function that exports a semantic view as an Ossie document and a preview stored procedure that creates a semantic view from one, the Ossie site lists Databricks converters for metric views, and dbt version 1.12 accepts Ossie documents.

Where a Snowflake feature has no Ossie equivalent, Snowflake's export keeps it in a vendor extension. In July 2026 Snowflake listed advanced metric logic and windowing functions among the areas it hoped to propose for the specification, so that logic cannot yet be assumed to move between tools through Ossie. We recommend treating Ossie as one way to generate copies from the system of record for the definitions it can express, and testing it on a few metrics first, because the latest released version of the specification is 0.1.1 and Snowflake's Ossie support is in preview. We found no documented Ossie import or export for Power BI, so Power BI copies still have to be maintained by hand.

How each platform tests answers

Snowflake's verified queries pair a question with SQL that answers it, and since 5 April 2026 they can be stored inside the semantic view. Cortex Analyst evaluations use those verified queries as ground truth. During a run, the queries under test are removed from a temporary copy of the semantic view, so a question under test cannot be answered by retrieving its own verified query. Snowflake runs the generated SQL, compares its results with those of the verified query and has an LLM judge score correctness. Because Cortex Analyst generates the SQL again on every run, Snowflake warns that repeated runs can give different scores even when the judge's metric version is pinned. Cortex Agent evaluations, generally available since 13 March 2026, score the agent's final answer and each stage of its reasoning.

Databricks Genie benchmarks hold up to 500 questions per agent. In the default Chat mode, Genie's result set is compared with the result of SQL supplied by the author, and numeric values match when they agree to four significant digits. Agent mode uses an LLM judge. Benchmarks run with the agent's example SQL in place, and Databricks recommends using the same examples in the benchmark set, so a Genie score includes the effect of those curated examples.

Microsoft offers a preview Python SDK that evaluates a Fabric data agent against expected answers written in plain language. The SDK applies an evaluation prompt to judge whether each answer matches its expected answer. For Copilot in Power BI, the documentation describes checking changes by hand in the Copilot pane of Power BI Desktop, and we found no documented way to score Copilot's answers automatically.

Because the platforms differ in which curated examples stay in place during a run and in how a match is scored, a score from one platform cannot be compared with a score from another.

Keep a question set of your own

We recommend keeping a question set outside any single platform. It should hold the business questions that matter, two to four phrasings of each, and expected results computed by querying the system-of-record object directly, so that the reference changes when the definition changes. Phrase each question over a closed period with absolute dates, and compute its expected result in the same run as the agent's answer. Run the set on a schedule and compare result values directly. Because Snowflake, Databricks and Microsoft all document that their agents can return different output for the same input, run each question several times and agree in advance how many of those runs must match. This is the approach we described for migration reconciliation, applied to an agent in place of a second platform.

Run each question and its reference query under the same roles as the business users who will ask it, including Snowflake secondary roles. Row access and masking policies change the rows a query returns, as we described in Snowflake AI features and the rights they run with.

Run the set again whenever a definition changes, and review each platform behavior change for the consumers it affects. Snowflake's behavior change bundle 2026_07, enabled by default in the 10.37 release (8 to 16 October 2026), makes a SEMANTIC_VIEW query that specifies both FACTS and DIMENSIONS fail at compile time in accounts where the bundle is enabled, because such queries had returned non-deterministic results. Cortex Agents generate their SQL against the physical tables, so this change mainly affects the dashboards, applications and tools that query the semantic view directly, and Snowflake's page for the change gives a QUERY_HISTORY query that lists affected queries from the last 30 days. Each metric owner should record which agents, dashboards and applications use the metric, so that a failed question or query can be traced to the consumers it affects.