A semantic layer maps raw tables to the business terms, metrics, and dimensions people ask about. It is not dead: one independent layer for every tool never became the default, and AI put those definitions in the path every agent query takes. If you lead a data platform or design AI agents across Snowflake, Databricks, and Power BI, you are deciding whether that layer still deserves investment, and a wrong call means agents return different revenue numbers for the same question.
Atlan reads the semantic models teams already run, such as Power BI semantic models and Databricks metric views, lets domain owners approve and test definitions in versioned context repositories, and deploys them to engines such as Snowflake Cortex Analyst and Databricks Genie while agents read the same certified context over MCP.
| Question | Short answer |
|---|---|
| Is the semantic layer dead? | No. One independent layer for every tool never became the default; semantic objects inside platforms kept growing |
| What grew instead? | Platform-native objects: Snowflake semantic-view querying went GA in August 2025, Unity Catalog Business Semantics in April 2026 |
| Do LLMs make it unnecessary? | No. A 2026 study found written-down business meaning raised accuracy by 17 to 23 percentage points |
| Where does it fall short? | Outside its model: in dbt Labs’ 2026 benchmark, the Semantic Layer returned errors on questions it could not model |
| What is still open? | One approved definition kept consistent across every engine that computes it |
Why do people say the semantic layer is dead?
The “dead” argument rests on two claims: the standalone category failed, and LLMs made it unnecessary. A third camp argues the opposite extreme.
The case that the standalone category failed
The headless BI wave promised one independent semantic layer that every tool would read. Atlan’s essay on why semantic layers failed names three reasons. BI vendors treated their semantic models as a moat and had little reason to give them up. Enterprises had to rebuild years of dashboard logic for similar answers, a hard sell once data budgets tightened in 2023. And the layer sat outside the execution path, away from the tools where analysts worked and queries ran.
LLMs appeared to make it unnecessary
Around the same time, LLM agents got much better at writing SQL from a schema, as the benchmark numbers below show. That produced the second claim: if a model can query raw tables directly, hand-modeling metrics is wasted effort.
A related argument reaches the same conclusion for a different reason. A centralized semantic model is too narrow and static to be the main home for organizational meaning. Consistent metric definitions still matter, but they often leave out question-specific context, exceptions, history, operational knowledge, and the differences between business roles. Central teams also struggle to keep them current.
The alternative is a living knowledge source that operators update, with semantic models compiled from it or validated against it. That is closer to capturing tacit knowledge for agents than to removing semantics. The meaning and the semantic model both remain; the model becomes a downstream artifact instead of the primary source.
The counterclaim: text-to-SQL cannot be trusted
The semantic-layer side makes the opposite case. In its 2026 benchmark, dbt Labs argues that its Semantic Layer “never returns invalid data,” while text-to-SQL can return a wrong number with confidence, so formal modeling wins.
Both sides overstate their case. Weighing either one starts with separating the systems now grouped under the name “semantic layer.”
How do today’s semantic layer forms differ?
A semantic layer maps physical data to business terms, metrics, and dimensions. Today, semantic layers for analytics take four forms, and a fifth pattern sits around them:
| Form | Examples | Where meaning lives | Status, November 2026 | Verdict |
|---|---|---|---|---|
| BI-embedded model | LookML, Power BI semantic models | Inside the BI environment | Mature; now reachable by agents (Looker’s release notes list its managed MCP server as GA in October 2026) | Alive and feeding agents |
| Standalone universal layer | Headless semantic layers queried by every tool | An independent modeling service | Did not become the default runtime | Not the default; Atlan’s essay argues it failed |
| Platform-native object | Snowflake semantic views, Unity Catalog metric views | Inside each data platform | Snowflake semantic-view querying GA in August 2025; Unity Catalog Business Semantics GA in April 2026 | Growing quickly |
| Open interchange specification | Apache Ossie (formerly Open Semantic Interchange) | Portable definitions | Announced as an Apache Incubator project in July 2026 | Early and incubating |
| Context layer around semantic models | Approved definitions deployed to several engines | Above the execution platforms | Emerging enterprise pattern | Where definitions are approved and tested |
Choosing a BI-embedded or dedicated layer, or a platform-native or standalone model, decides where a definition executes. Once you run several models, the systems of semantics question becomes which definition applies, who owns it, and how it was validated.
What happened to the semantic layer from 1991 to 2026?
The semantic layer began inside BI, tried to stand alone, then moved into the platforms where queries and agents run:
| Date | Move | What changed |
|---|---|---|
| 1991 to 1996 | Business Objects filed for its “universe” technique in 1991 and received U.S. Patent 5,555,403 in 1996 | Business terms hid relational complexity inside BI |
| Oct 2016 | Looker 4.0 introduced a new LookML syntax | Definitions lived as code inside one BI tool |
| Oct 2022 | dbt Labs launched the public preview of the dbt Semantic Layer | Metric definitions moved into an independent service |
| 2023 | Tighter data budgets made rebuilding dashboard logic a hard sell, per Atlan’s essay | The independent layer did not become the default runtime |
| Aug 2025 | According to Snowflake’s 9.25 release notes, querying semantic views became generally available | Semantics entered warehouse execution |
| Sep 23, 2025 | Snowflake announced Open Semantic Interchange with Salesforce, dbt Labs, Atlan, and others | A shared specification addressed fragmented semantics |
| Oct 14, 2025 | dbt Labs open-sourced MetricFlow under Apache 2.0 | The semantic execution engine became openly licensed |
| Apr 2, 2026 | Databricks announced general availability of Unity Catalog Business Semantics, with materialization still in Preview | Metric views became a platform primitive |
| Jul 10, 2026 | Open Semantic Interchange entered the Apache Incubator as Apache Ossie, with its specification and YAML format unchanged | Interchange gained a neutral home |
| Sep 30, 2026 | Snowflake’s Semantic Studio became generally available, with Git-backed version control for semantic view definitions | Platform objects gained their own lifecycle |
What the timeline shows
The shift runs from models inside BI, through an attempted universal layer, to semantic views as materialized context inside execution platforms. Microsoft’s Fabric IQ shows the next step: Power BI semantic models supply curated measures, hierarchies, and dimensions, while an ontology (in preview) carries source-owned DAX measures forward as metrics and adds entity types, relationships, and rules for agents. That is why an ontology and a semantic model are related but not equivalent.
Demand points the same way. Futurum (2026) forecasts the semantic layer segment’s year-over-year growth rate doubling from 16.0% in 2026 to 30.0% by 2031. A forecast is not observed adoption, but it makes “dead” a poor description of the market.
Did LLMs make the semantic layer unnecessary? What the benchmarks say
No. LLMs eased the SQL bottleneck, but a schema does not tell an agent your company’s approved definition of “active customer” or “net revenue.” The controlled studies separate the two.
SQL skills improved faster than meaning
According to the Spider 2.0 paper (Lei et al., ICLR 2025), its strongest agent at launch solved 21.3% of the benchmark’s enterprise-style tasks, against 91.2% on Spider 1.0 and 73.0% on BIRD. As of November 11, 2026, the Spider 2.0 leaderboard showed top scores of 96.70 on Spider 2.0-Snow and 76.23 on Spider 2.0-Lite, each with 547 tasks.
Both Spider 2.0 settings give agents “well-prepared database metadata and documentation,” and top agents use it, which supports written-down meaning. A public leaderboard measures a fixed task set; your own test is whether an agent picks your finance team’s approved revenue definition when three documented versions exist. For enterprise text-to-SQL, choosing the right definition, join, and policy is the harder problem, and the same holds when you weigh Cortex Analyst against custom text-to-SQL.
Explicit business meaning improves accuracy
Two controlled comparisons hold the question set fixed and change only whether business meaning is supplied.
The independent one is a preprint. According to Rumiantsau and Fokeev (2026), giving Claude Opus 4.7, Claude Sonnet 4.6, and GPT-5.4 a 4 KB hand-authored markdown document describing the dataset’s measures, conventions, and disambiguation rules raised accuracy from 45.5-50.5% to 67.7-68.7%, a gain of 17 to 23 percentage points. The benchmark used 100 natural-language questions over the Cleaned Contoso Retail Dataset in ClickHouse; one question was excluded for resource limits, so the analyses use 99. Within each condition the three models were statistically indistinguishable, so having the meaning written down mattered more than which model read it.
The other is a vendor testing its own product. In dbt Labs’ April 2026 benchmark of 11 questions run 20 times each, modeled questions scored 98.2% (Claude Sonnet 4.6) and 100.0% (GPT-5.3 Codex) through the Semantic Layer, against 90.0% and 84.1% with text-to-SQL.
Atlan’s own study agrees. In Atlan’s 2026 research on enhanced metadata, 522 evaluations of 174 queries on one 13-table dataset lifted the share of queries answered correctly from 16.1% to 22.2% when enhanced context was added. In that 2026 study, the gain was 6.1 points, or 38% relative (p < 0.0001), with a 2.15x improvement on medium-complexity queries.
The results support combining text-to-SQL with a semantic layer rather than betting on one universal container for meaning.
A strict semantic layer stops at its edges
The same dbt Labs benchmark shows the boundary. In its 2026 run, on questions whose schema needed “too many entity hops for MetricFlow,” the Semantic Layer scored 0.0% while text-to-SQL scored 70.0% and 100.0%. Its failure “looks like an error message,” while, in the post’s words, text-to-SQL “will cheerfully give you a wrong number.” After dbt Labs added three new models, the layer could answer every question in the benchmark.
That sequence is the useful lesson: unanswered questions become modeling work. Reliable AI agent accuracy needs certified meaning inside the model and a labeled, logged path outside it, so that preventing agent hallucination does not turn every unmodeled question into a dead end.
Neither absolute claim holds: explicit meaning improved results in both controlled studies, and the semantic layer supplied it only within its modeled scope.
The new failure: semantic sprawl at agent scale
At agent scale, the failure is fragmented meaning.
Different agents query raw tables, use different glossaries, inherit different metric definitions, or rely on separate semantic views. Each answer looks valid in its own context, even when two agents answer the same question differently.
Rob Vicker, Data Analytics Architecture Director at EMC Insurance, named the problem in dbt Labs’ MetricFlow announcement: “BI and AI tools often interpret metrics in their own ways.”
Semantic-view sprawl is one version of it. A team creates a separate view for each agent use case, and revenue ends up defined in five places. A change reaches one view and misses the others, and feedback improves only the view tied to one agent. When several views could answer a question, the agent has no way to tell which one is approved.
One response is to expose an approved semantic layer through MCP, so agents use maintained logic instead of rebuilding metrics from raw tables. Apache Ossie makes definitions portable. MCP standardizes how agents reach context; Ossie standardizes how definitions are written down. Which definition is approved, who owns it, and how it was tested remain enterprise decisions.
Each platform documents its own lifecycle. Snowflake’s Semantic Studio offers Git-backed version control for semantic view definitions, and Databricks describes metric views as governed directly in Unity Catalog. An estate that runs both still has to keep the two copies of a definition in step. When meaning stays inside one platform, or each agent space carries its own instructions, as the context requirements for a Databricks Genie space show, platform-native context layers can still drift apart across the enterprise.
The verdict: what is dead, what is alive
The evidence shows the universal promise falling short while the function kept growing.
One independent semantic layer, sitting outside the tools, did not become the runtime every BI tool and agent queried; Atlan’s essay calls that a failure. Meanwhile metrics, dimensions, relationships, and rules are compiled where queries run and exposed to agents, as the 2025 and 2026 releases above show.
Still open: keeping one approved definition consistent when it exists in several engines at once, with an owner, tests, and a release history that span all of them.
The catalog went through a similar shift; the agentic data catalog argument holds that it persists as an agent-facing foundation. For semantics, the question is where definitions, owners, tests, and history live before they reach engines and an agent context layer.
Where does business meaning live now?
Business meaning needs one approval workflow and several deployment targets. Definitions are reconciled with owners, tested, approved, versioned, and connected to lineage in one place, then compiled into the semantic objects that calculate them close to the data.
One place does not mean one definition. Finance and sales can each own a scoped revenue definition, as long as each agent knows which one applies to its question. The engine computes the number: an agent reads the approved definition and its owner, then queries the deployed semantic object instead of writing its own SQL for a modeled metric. Text-to-SQL covers what nobody has modeled, its answers are labeled, and repeated misses become context graph candidates for the next release.
A worked example: net revenue
Take net revenue. Finance owns the definition: gross bookings minus refunds, in the reporting currency, by fiscal quarter. The approved version carries its owner, the questions it was tested against, and lineage to the tables it reads. It ships as a Snowflake semantic view and as a Unity Catalog metric view. Each engine expresses the calculation differently, so the tests run against every deployed target as well as the definition. When finance changes the refund rule, the change is tested once and redeployed to both, and a direct edit in either platform should surface as drift against the approved version.
The lifecycle for each business definition has five steps:
- Mine: draft from SQL intelligence, BI logic, and data lineage for AI.
- Reconcile: resolve conflicts with a named owner.
- Test: run real questions and edge cases as an evaluation set, a core practice of context engineering.
- Approve: certify, version, and store the definition in a context repository.
- Deploy and observe: publish to each target and watch for drift and failed questions.
This is where context engineering meets the semantic layer, and where the context layer, data catalog, and semantic layer divide the work. An enterprise context layer owns the lifecycle across the reference architecture; semantic objects calculate close to the data.
How does Atlan approach the semantic layer question?
Atlan reads supported semantic models as inputs and deploys approved context to supported engines, while definitions, owners, tests, and history stay in context repositories. Teams get one lifecycle without abandoning the BI and data-platform models they already run.
| Reader need | Atlan capability | What it does |
|---|---|---|
| Reuse existing semantic logic | Semantic asset connectors and lineage | Catalogs Databricks metric views and Power BI semantic models, so teams start from the logic already in use |
| Find conflicting definitions | Context Agents | Draft descriptions, glossary terms, metrics, and ontology from lineage, SQL, and BI logic; domain experts stay on the loop and certify before context ships |
| Test meaning before agents use it | Context Engineering Studio | Bootstraps context repos, runs evaluations built from existing dashboards, reports, and production queries, deploys, then observes traces and drift |
| Keep each definition in one approved home | Context Repos | Versioned, bounded, portable units of context, with full history, branching, staged rollouts, and rollbacks |
| Publish meaning to engines and agents | Context Engineering Studio, Context Lakehouse, and the Atlan MCP server | Deploys context repos to Snowflake Cortex Analyst and Databricks Genie and serves certified context to agents over MCP |
Teams review a correction once and redeploy it to the targets that use it, instead of recreating every definition or cutting the model off from query execution.
The same pattern applies to a Genie ontology or a Snowflake context layer. The Lightdash, dbt, and Atlan comparison shows where each tool’s work sits.
Real stories from real customers: one meaning, many engines
Atlan customers manage and deliver shared meaning in different ways.
Fox uses Atlan as one place to define its data, what it means, and where it comes from, independent of the technology that stores and processes it. Elastic uses Atlan AI to draft definitions across its data estate and propagate them upstream and downstream. CME Group cataloged more than 18 million assets and 1,300+ glossary terms in its first year, giving teams a shared set of definitions to reuse.
Workday: How a Semantic Layer Taught AI the Language of Business
Source: Atlan on YouTube
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
Joe DosSantos, VP, Enterprise Data and Analytics, Workday
"Context is the differentiator. Atlan gave our teams the shared vocabulary and lineage to move from reactive data management to proactive AI enablement."
Kiran Panja, Managing Director, Cloud and Data Engineering, CME Group
Should you still build a semantic layer in 2026?
Yes. Build the executable model where queries run, and in a multi-platform estate keep definitions, owners, tests, and history outside any one engine.
The right architecture depends on your environment:
| Situation | What to do |
|---|---|
| One platform and one BI tool | Keep the existing semantic model. Add clear ownership, tests, and change history before adding another abstraction |
| More than one platform, with agents on each | Approve definitions above the engines, then deploy the matching semantic object to each platform |
| A long tail of unmodeled questions | Use semantic execution for modeled questions and labeled text-to-SQL for the rest. Turn repeated misses into candidates for the model |
| Existing BI models you do not want to rebuild | Keep the logic already in use, reconcile conflicting definitions, and migrate one business domain at a time |
A semantic layer for AI agents supplies approved logic for modeled questions. The broader task is to implement a context layer and manage KPI definitions and business terms through one reviewable lifecycle.
To see one definition bootstrapped, tested against real questions, and deployed to more than one engine, explore Context Engineering Studio.
FAQs about whether the semantic layer is dead
Short answers to the questions data leaders ask most about where the semantic layer goes next.
1. Is the semantic layer dead?
No. One universal layer that every tool queried never became the default, but semantics moved into BI tools and data platforms. Snowflake made semantic-view querying generally available in August 2025, Databricks made Unity Catalog Business Semantics generally available in April 2026, and Microsoft pairs Power BI semantic models with a Fabric IQ ontology in preview. The need for consistent metrics, dimensions, and relationships keeps growing; the idea that one tool’s model owns enterprise meaning is what has faded.
2. Do AI agents still need a semantic layer if LLMs can write SQL?
Yes. Agents need explicit business meaning, and a semantic layer is one way to supply it. Writing valid SQL does not tell an agent which revenue definition finance approved or which exclusions apply. In a 2026 preprint by Rumiantsau and Fokeev, a 4 KB document of measures and rules improved three frontier models by 17 to 23 percentage points, which shows SQL skill and business meaning are separate requirements.
3. What is the downside of relying only on a semantic layer?
A semantic layer answers only what its model covers. In dbt Labs’ 2026 benchmark, questions that needed too many entity hops scored 0.0% through the Semantic Layer, while text-to-SQL scored 70.0% and 100.0%. The layer failed safely by returning an error message, and after three new models were added it answered every question. Teams still need a labeled route for valid questions nobody has modeled yet.
4. What is Apache Ossie, formerly OSI?
Apache Ossie is the new name for Open Semantic Interchange (OSI), an open specification for expressing business metrics, dimensions, and their relationships, plus broader business concepts and rules. The project announced its acceptance into the Apache Incubator on July 10, 2026, with its specification and YAML format unchanged. Ossie lets systems exchange definitions; deciding which definition is approved, who owns it, and how it is tested stays with the enterprise.
5. Should I build in Snowflake semantic views, Databricks metric views, or dbt?
Build where your agents and analytical workloads run. If the organization uses several engines, keep the source definition, owner, tests, and version history outside any one platform, then deploy the matching semantic object to each. Calculation stays close to the data, and every platform gets the same approved definition and release history.
6. What replaces the semantic layer?
Nothing replaces it. A context layer wraps the semantic layer with ownership, certification, lineage, tests, policy context, version history, and delivery to agents. Semantic views and metric views remain the executable form of business meaning inside their platforms. The context layer manages how that meaning is approved, updated, and distributed across platforms and agents.
7. Can AI build the semantic layer for me?
AI can draft much of it. It can propose metrics, joins, descriptions, and relationships from SQL history, BI logic, lineage, and existing terms. According to Atlan, in April 2026 Context Agents had generated 690K+ descriptions across 50+ enterprise customers, with 87% rated on par with or better than human writing. Domain owners still resolve conflicting definitions, test the answers, and certify which agents may use them.
8. Is a semantic model the same as a semantic layer?
Not quite. A semantic model is one file or object, such as a Power BI semantic model or a Snowflake semantic view, that says which tables hold which entities, how they join, and how each metric is calculated. The semantic layer is the role those models play between raw data and the people and agents asking questions; an enterprise usually runs several semantic models at once.
9. Is a semantic layer the same as a metrics layer?
No. A metrics layer standardizes how KPIs such as revenue and churn are calculated, one formula per metric. A semantic layer covers more ground: the same metrics plus the entities, dimensions, relationships, and access rules that give them context. AI agents usually need the wider layer.
10. How is a semantic layer different from a data catalog?
A semantic layer returns a metric’s logic, so every tool and agent calculates revenue the same way. A data catalog tracks data assets: their lineage, owners, quality, and who may query them. Agents need both, and a context layer connects the two so an approved definition arrives with its owner, lineage, and access rules.
Sources
- US5555403A - Relational database access system using semantically dynamic objects
- 4.x Release Notes
- dbt Labs Launches the dbt Semantic Layer, Enabling Greater Consistency Across Analytics Tools
- 9.25 Release notes: Aug 25, 2025-Aug 28, 2025
- Snowflake, Salesforce, dbt Labs, and More, Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative
- dbt Labs Affirms Commitment to Open Semantic Interchange by Open Sourcing MetricFlow
- Apache Ossie (Incubating): The New Name for Open Semantic Interchange
- What is Fabric IQ?
- Sep 30, 2026: Semantic Studio (General availability)
- Looker release notes
- Semantic Layer Set to Become the Next Piece of Critical Infrastructure
- Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows
- Spider 2.0
- Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update
- Semantic Layers for Reliable LLM-Powered Data Analytics: A Paired Benchmark of Accuracy and Hallucination Across Three Frontier Models
