What Is a Semantic Layer? Do You Need One For AI In 2026

A semantic layer is a set of business definitions (metrics, dimensions, joins and access rules) written once in code and compiled into SQL for every tool that asks, so "net revenue" means the same thing in a dashboard, a spreadsheet and an AI agent. You don't strictly need one for AI analytics. An AI analyst needs meaning written down where a machine can read it, and a semantic layer is one container for that meaning. It earns its place when several tools must return the same governed number. It does not decide which metric a vague question is asking for; that job belongs to documentation and context.

I run GetDot, an AI data analyst that answers through whatever semantic layer a company already has, so I have a stake in this debate and some evidence.

What is a semantic layer?

A semantic layer sits between your warehouse and the tools people use to ask questions. It holds the business meaning raw tables don't carry: that net_revenue is order amount minus refunds and discounts, that test orders don't count, that an order joins to a customer on customer_id, and that the EMEA sales team only sees EMEA rows. A tool asks for a metric by name, sliced by dimensions and filters. The layer writes the SQL, runs it in the warehouse and returns the rows.

Most semantic layers hold five kinds of thing:

• Metrics (or measures): aggregations with their rules, such as the sum of net amount excluding test orders.
• Dimensions: the attributes you slice by, including time grains such as day, week, month or fiscal quarter.
• Entities and joins: how tables relate, so a request for revenue by customer region joins correctly.
• Access rules: who can see which rows and fields.
• Caching or pre-aggregation, in some products.

The names vary (Microsoft renamed Power BI datasets to semantic models in November 2023; "metrics layer" and "headless BI" are covered in the FAQ), but the idea is the same: define once, compute the same way everywhere.

Semantic layer example: net revenue, defined once

A dashboard shows revenue after refunds. Finance's spreadsheet subtracts refunds and discounts. An AI agent pointed at the raw tables sums amount and includes test orders. That is three numbers for "revenue last quarter". With a semantic layer, the definition lives in one file. Here it is in Malloy, the semantic layer we recommend (why): an orders source, its join to customers, a month dimension and the net revenue measure.

source: customers is duckdb.table('analytics.dim_customers') extend {
  primary_key: customer_id
}

source: orders is duckdb.table('analytics.fct_orders') extend {
  primary_key: order_id
  join_one: customers with customer_id

  dimension: order_month is ordered_at.month

  measure:
    #" Order amount minus refunds and discounts, excluding test orders
    net_revenue is sum(amount - refund_amount - discount_amount) { where: not is_test_order }
}

Every consumer then asks for the measure by name. Net revenue by month and customer region:

run: orders -> {
  group_by: order_month, customers.region
  aggregate: net_revenue
}

An AI agent sends the same query, through the MCP server in Malloy's Publisher or, in Dot's case, compiled in Malloy's restricted mode, so it can't reach raw tables or SQL around the model. Whoever asks, the compiler writes the formula, the test-order rule and the join into the SQL. This is its DuckDB output; the code above compiles and runs as written on Malloy 0.0.436:

SELECT
   DATE_TRUNC('month', base."ordered_at") as "order_month",
   customers_0."region" as "region",
   COALESCE(SUM(CASE WHEN COALESCE(NOT base."is_test_order",TRUE) THEN (base."amount"-base."refund_amount")-base."discount_amount" END),0) as "net_revenue"
FROM analytics.fct_orders as base
 LEFT JOIN analytics.dim_customers AS customers_0
  ON customers_0."customer_id"=base."customer_id"
GROUP BY 1,2
ORDER BY 1 desc NULLS LAST

If finance decides discounts are a marketing cost and shouldn't reduce revenue, you change one line, the pull request gets reviewed, and the dashboard, the spreadsheet and the agent all return the new number on their next query. For the same metric written in LookML, dbt, Cube and DAX, see Malloy vs LookML vs dbt vs Cube.

Semantic layer architecture: where it sits

• Below it is the warehouse: BigQuery, Postgres, Snowflake, Databricks, DuckDB. The layer stores definitions, not data (caches aside), and runs its SQL where the data already lives.
• Above it are the consumers: dashboards in Looker, Power BI, Tableau or Data Studio (formerly Looker Studio); spreadsheets and notebooks; embedded analytics; and AI agents.
• The interface is a metric request (metric, dimensions, filters, time grain) sent over SQL, REST, GraphQL, XMLA or MCP. The layer turns it into SQL, applies access rules and returns rows.
• Beside it, for AI agents, sits a context layer: the glossary, table docs, caveats and trusted examples that tell an agent which metric a question means (below).

Types of semantic layer

There are four families, grouped by where the definitions live (as of October 2026). Our guide to the best semantic layer tools compares each product's interfaces, MCP support and pricing.

Which semantic layer we recommend

If you can choose, we recommend Malloy, especially for AI analytics: an agent asks for a measure by name instead of rewriting its formula, aggregates stay correct across joins, and the compiler rejects a bad query before the warehouse runs it. The model and the query language are one open-source (MIT) project, and GetDot reads it natively. The exception is a model people already trust: if your numbers come from LookML or a Power BI model, point the agent at it rather than rebuild it. The full case, and where Malloy falls short, is in our Malloy guide; see also Power BI semantic models and the dbt Semantic Layer.

Do you need a semantic layer for AI analytics?

Most of what's written on this question comes from companies that sell a semantic layer, and I sell an AI analyst, so weigh both accordingly.

The case for a semantic layer

• Accuracy on covered questions. dbt Labs' April 2026 benchmark update ran 11 questions on an insurance dataset, each 20 times. On the modeled data, Claude Sonnet 4.6 went from 90.0% with text-to-SQL to 98.2% through the Semantic Layer, and GPT-5.3-Codex from 84.1% to 100%. Outside what has been modeled, the layer says so instead of guessing. dbt Labs sells the Semantic Layer and 11 questions is a small set, but the direction is clear.
• A paired test. A paired benchmark posted to arXiv in April 2026 (Rumiantsau and Fokeev) held model, prompt and harness constant on about 100 retail questions and changed only whether the model got the semantic layer. Accuracy rose 17.2 to 23.2 points for each of three frontier models, all statistically significant. The "layer" in that study was a written document of definitions and data quirks.
• Knowledge graphs, too. A 2023 study by Sequeda and Allemang at data.world found GPT-4 answered 16.7% of enterprise questions correctly over a raw SQL schema and 54% over a knowledge-graph representation of the same database; a 2024 follow-up with ontology-based query checks and repair reached 72.55%. The authors' company sells knowledge-graph tooling.
• Teams running agents at scale use one. Anthropic's June 2026 write-up of its internal analytics agents describes a semantic layer that agents are told to use first, and reports about 95% of business analytics queries automated at about 95% accuracy. It also reports that letting the model draft metric definitions made results worse, and recommends that humans own them.
• Analysts expect it to matter. In a May 2026 press release, Gartner predicted that by 2027, organizations that prioritize semantics in AI-ready data could raise agentic AI accuracy by up to 80% and cut costs by up to 60%. That is a forecast, not a measurement.
• Governance. Access rules defined once, a definition with an owner and a review history, and a refusal instead of a confident wrong number. For board and finance metrics, that matters more than a few points of accuracy.

The case that a layer solves only half the problem

• DABstep: from 10% to 90% without a semantic layer. Adyen and Hugging Face's DABstep benchmark asks multi-step questions over real payment data full of undocumented conventions. On a 30-task slice, a configured Dot went from 10% to 90% across 14 configuration versions with the same model, scored with DABstep's own scorer and reproduced on the public leaderboard. The first stretch, to about 30%, came from writing down conventions the schema doesn't show, and none of the work was building a semantic layer. Read it as evidence that written-down meaning matters, not as a general accuracy figure.
• The semantic layer solves the wrong half. Answering a data question is two jobs: orientation (which of the eleven things called revenue did the person mean?) and computation (apply that definition with the right filters, grain and joins). A semantic layer makes computation deterministic and says almost nothing about orientation; when a question lands outside the layer, the agent guesses anyway.
• AI didn't make the semantic layer necessary; it made it cheap. Most teams never built a layer because every metric had to be defined twice and kept in sync by nobody. Models that read your dbt project and query history can now draft the layer and flag drift. The bigger question is ownership: keep definitions in code you own, not inside any vendor's product, ours included.

Reading the evidence together

The two sides measure different things. The pro-layer benchmarks mostly test questions the layer covers; our DABstep work and the "wrong half" argument test whether the agent knows what a question means in the first place. So the useful question is which failure you have. If your agent picks the wrong metric, more semantic layer won't fix it; better context will. If it picks the right metric and computes it three different ways, that is exactly what a semantic layer is for.

When you need one, and when documentation is enough

A sequence that works whether or not you end up with a layer:

1. Write the map: which metrics exist, what each one means, which table is the source of truth, who owns it and what people confuse it with. This is prose, and it is cheap.
2. Collect trusted questions: a few dozen real questions with answers your team has checked, your test suite for any AI.
3. Codify the metrics that matter, starting with the board deck and the ones that show up in three tools with three different values.
4. Keep definitions in code you own, in Git, reviewed like any other change.
5. Re-test after every change to the layer, the docs or the model behind your AI.

Semantic layers and MCP

The major semantic layers (dbt, Looker, Power BI, AtScale and others) now offer MCP servers that let Claude, ChatGPT, Cursor or Copilot query them directly; our semantic layer tools comparison covers each server. That beats pointing an assistant at raw tables: it gets governed metrics instead of guessing joins. What MCP doesn't add is everything around the layer: knowing that "revenue" at your company means net revenue unless finance asks for bookings, answers for questions outside the layer, permissions better than the token you hand out, and any check that the answers are right.

How GetDot uses the semantic layer you already have

Dot doesn't ask you to adopt a new layer. It connects to Malloy, Looker, Power BI, Azure Analysis Services, dbt, Cube and Steep and answers through their definitions, so its numbers match the tools your team already trusts (how it queries each one is in our tools comparison and changelog). On a Looker connection, the query Dot writes looks like this (simplified). Looker compiles each explore(...) into SQL from your LookML, so the measure is computed exactly as it is in Looker:

with net_by_channel as (
  explore(
    name="ecommerce.orders",
    fields=["orders.channel", "orders.net_revenue"],
    filters={"orders.created_date": "last 12 months"}
  )
)
select * from net_by_channel
order by "orders.net_revenue" desc

For Power BI, how Dot uses your Power BI semantic models covers the DAX side. Dot is also available as an MCP server, so you can ask it from Claude, ChatGPT, Cursor or Copilot with your own Dot permissions.

When a question falls outside the layer

This is where the "wrong half" shows up in practice. On a dbt Semantic Layer connection, if the metric or dimension a question needs isn't in the layer, Dot says which fields are missing rather than improvise a definition. A Looker query has to go through at least one explore, so Dot can't quietly bypass your LookML. If you also connect the warehouse, as Choco did with Looker and Databricks, questions the layer doesn't cover can still be answered from tables, in place and under the warehouse's own permissions, with the SQL shown for review.

If you don't have a semantic layer

You don't need to build one before you start. Dot's Context Agent pulls definitions from Malloy, dbt, Looker, Tableau, Power BI, Sigma, Metabase and Cube, from docs in tools like Notion, Confluence and Google Drive, and from your warehouse's own comments and query history. It drafts what is missing and sends every change for review as a diff. When you want deterministic metrics, start in Malloy, the layer we recommend: the Context Agent can write the Malloy model over BigQuery, Snowflake, DuckDB or Dot's managed warehouse, checked against your existing dashboards. To know whether any of it worked, Train tests Dot against questions with answers you trust and reports accuracy before and after.

Semantic layer vs context layer vs ontology

Semantic layer vs context layer. The semantic layer computes; the context layer orients. "Context layer" is a new, mostly vendor-driven term: Cube describes the semantic layer as the core of a context layer, and others call the context layer a superset aimed at AI agents. Its content is what an analyst would tell a new hire: revenue means net revenue unless finance asks for bookings, ignore orders from before the 2024 migration, and Maria owns churn.

Ontology vs semantic layer. An ontology models the world (customers, contracts, products and the relationships between them) so a system can reason about connections; a semantic layer models measurement. The Sequeda study above is evidence for the ontology side. For most analytics questions, the entity relationships already live in dbt models and LookML joins, so a formal ontology is an addition, not a prerequisite.

Open Semantic Interchange (OSI)

Open Semantic Interchange, launched by Snowflake, Salesforce, BlackRock, dbt Labs and RelationalAI in September 2025 and now Apache Ossie (Incubating), is a vendor-neutral YAML format for moving metrics, dimensions and relationships between tools. As of October 2026 its first version (0.1.1) is live and 0.2 is in draft; our OSI guide covers who supports it and what it doesn't solve. Until your tools ship support, the practical way to keep definitions portable is to keep them in code you own.

FAQ