AI agents need a semantic layer because they otherwise guess. Asked for "revenue last quarter", an agent working on raw tables has to pick the table, the joins, the filters and the formula itself, and it can pick differently each time. A semantic layer defines each metric, dimension and relationship once, so every agent and dashboard computes the same answer.

Picture a finance lead who asks the company's new AI assistant for net revenue by region last quarter. The assistant writes SQL, returns a clean table, and the total is a few percent off the board pack. Nobody can say why at first. Later someone works it out: the assistant summed gross order value, ignored refunds and joined customers to regions through the billing address instead of the sales territory. Each choice was reasonable. None of them was the company's definition, because that definition only existed inside one Power BI report.

What is a semantic layer?

A semantic layer is a set of shared business definitions (metrics, dimensions, relationships and plain-language descriptions) that sits between your raw tables and every tool that asks questions of them. It turns "net revenue" from a formula someone remembers into an object with one definition that every report and agent uses.

A few terms, each in one sentence:

• A metric is a calculation the business agrees on, such as net revenue or active customers.

• A dimension is a way to group or filter that metric, such as region, product line or month.

• A relationship is the approved join between two tables, such as orders to customers on customer ID.

• Grain is what one row in a table represents, such as one order or one order line.

Most companies already have a semantic layer, just not in one place. It is split across Power BI or Tableau models, spreadsheet formulas, dbt models and the heads of two analysts.

Why do AI agents get business questions wrong without one?

Without a semantic layer, an agent has to infer business meaning from column names, and column names rarely carry the rules. A table called orders does not say whether cancelled orders count, which currency to use or which date marks a sale.

The usual failure points:

• Ambiguous names. Two columns called amount, in two tables, mean different things.

• Wrong joins. Joining at the wrong grain duplicates rows and inflates totals.

• Missing filters. Test accounts, refunds or internal orders are left in.

• Ratios computed wrongly. Averaging a ratio per region gives a different answer from dividing the totals.

• Drift. The answer changes when the agent picks a different path next time.

Microsoft says much the same about its own Copilot in Power BI. Its guidance on preparing data for AI states that "when data is unstructured or ambiguous, AI systems can struggle to correctly interpret it", and that outputs "might be generic, inaccurate, or even misleading". It also notes that preparation "can't ensure a specific output every time", because AI behaviour is nondeterministic. A semantic layer narrows the room for error. It does not remove the need to test.

What are Snowflake, Databricks and dbt shipping for this?

The major data platforms now treat semantic definitions as database objects that both BI tools and AI agents can read. That is the main change of the last year: definitions are moving out of individual dashboards and into the platform.

• Snowflake semantic views: definitions live as schema-level objects in Snowflake; Cortex Analyst and Cortex Agents read them.

• Databricks Unity Catalog metric views: YAML definitions registered in Unity Catalog; Genie, dashboards and external BI tools read them.

• dbt Semantic Layer (MetricFlow): definitions live in your dbt project; AI tools such as Claude and ChatGPT reach them through the dbt MCP server.

• Power BI semantic model with Prep data for AI (preview): definitions live in the Power BI semantic model; Copilot in Power BI reads them.

Snowflake semantic views

Snowflake semantic views are schema-level objects that store logical tables, relationships, facts, dimensions and metrics in the database. Defining them became generally available at Snowflake Summit in June 2025, and Cortex Analyst reads the definition to generate SQL against the physical tables.

Databricks metric views

Unity Catalog metric views separate measure definitions from the dimensions used to group them. Databricks' own example is a ratio, "sum of revenue divided by distinct customer count", defined once and grouped by any field while the engine computes it correctly. They can be queried from Genie, dashboards and external tools such as Power BI and Tableau; a BI compatibility mode for Power BI was released in beta in March 2026.

dbt Semantic Layer and the Fivetran merger

The dbt Semantic Layer, powered by MetricFlow, defines metrics in the dbt project, so a change "is refreshed everywhere it's invoked". dbt's documentation says AI tools such as Claude and ChatGPT can connect to it through the dbt MCP server, "so their answers use your governed metrics instead of guessing at raw tables". Fivetran and dbt Labs completed their merger on 1 June 2026, and a DocuSign data architecture lead quoted in the announcement puts it plainly: "AI and agents are only as strong as the data behind them."

Where should the semantic layer live: in the BI tool or the warehouse?

Put core metrics where most of their consumers can reach them. If agents, notebooks and more than one BI tool need the same numbers, define them in the warehouse or in dbt. If everything runs through one BI tool, its semantic model can be enough for now.

Signs the BI model is enough

• One BI tool, one team and one main agent experience, such as Copilot in Power BI.

• Metrics change rarely, and the owners are the report authors.

Signs it should move down a level

• The same metric is rebuilt in two or more tools, and the numbers differ.

• Agents query the warehouse directly, outside the BI tool.

• Finance, sales and operations each keep their own version of a shared metric.

Moving the layer down does not mean deleting BI models. The BI tool keeps formatting, report logic and visuals; the warehouse or dbt holds the definitions.

How do you build a semantic layer that agents can use?

Start with the ten to twenty metrics people actually ask about, define each one in plain language and in code, and test the agent against questions with known answers before anyone relies on it.

Steps

1. Collect the real questions. Pull them from leadership packs, recurring requests to the data team and the questions people already type into chat tools.

2. Pick the metrics behind them. Choose a short list and name an owner for each.

3. Write the definition in words first. For example: "Net revenue is gross order value minus refunds and discounts, in euros, by order date, excluding test accounts."

4. Fix the grain and the joins. Document what one row means in each table, and which joins are approved.

5. Encode it in one place. Use semantic views, metric views, dbt metrics or the BI semantic model, not all four.

6. Add synonyms and descriptions. Agents read them. "Sales", "revenue" and "turnover" should point to the right metric, or to a clear question back.

7. Connect the agent to the layer, not to raw tables. Give it read access to the governed objects only.

Test before you trust it

Build an evaluation set: thirty or so questions with answers your analysts have checked. Run it after every change to a definition or to the agent. Power BI's verified answers do something similar inside one model, tying trigger phrases to a visual whose result someone has approved. Track which questions fail and why; most failures point to a missing definition or synonym, not a model problem.

How we approach it at Vizio AI

We start from the questions, not the tools. With the client's analysts, we collect the questions leadership and operations ask most often, trace each answer back to the tables and formulas behind it, and write down where the current reports disagree.

From that list we agree the core metrics, their owners and their definitions in plain language, and only then choose where to encode them, usually in the platform the client already runs. We connect the agent to those governed objects with read-only access, build the evaluation set with the analysts, and keep it running after handover so a changed definition shows up as a failed test, not a wrong board number.

This is part of our DX Studio work. If the agent reaches the warehouse through MCP, Connecting an AI Agent to Your CRM? Secure the MCP Server First covers access control. For the model behind the agent, see Claude, GPT or Gemini? Choosing a Model for Business Workflows, and for how we set up the reporting side, Power BI Implementation in 30 Days.

Sources

• Snowflake, Overview of semantic views: https://docs.snowflake.com/en/user-guide/views-semantic/overview

• Snowflake, Summit announcements, June 2–5, 2025: https://docs.snowflake.com/release-notes/2025/june-summit

• Databricks, Unity Catalog metric views: https://docs.databricks.com/aws/en/metric-views/

• Databricks, Platform release notes, March 2026: https://docs.databricks.com/aws/release-notes/product/2026/march

• dbt, dbt Semantic Layer: https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl

• Fivetran, Fivetran and dbt Labs complete merger (1 June 2026): https://www.fivetran.com/press/fivetran-dbt-labs-complete-merger-to-create-the-data-infrastructure-for-trusted-ai-agents

• Microsoft Learn, Prepare your data for AI to improve Copilot results (preview): https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-prepare-data-ai