If you’re standardizing metric definitions across BI dashboards, this list opens with the right tools. The evaluation gets wider when AI agents enter the picture (Cortex Analyst, Genie, MCP-connected copilots). You need governance signals an agent can read, lineage an agent can cite, and access policies an agent can respect. That expands the category to include the context layer that wraps tools like dbt Semantic Layer, Cube, Snowflake Semantic Views, and Databricks Metric Views for AI agent governance.
Four architectural categories of the modern semantic layer stack explained. Image by Atlan.
Quick facts: semantic layer category map
Permalink to “Quick facts: semantic layer category map”| Category | Examples | Best when… | Atlan integration status |
|---|---|---|---|
| Pure semantic layer | dbt Semantic Layer, Cube, AtScale | You need code-first or headless metric definitions consumable across BI, analytics, and AI agents | dbt SL: GA (launch partner). Cube + AtScale: adjacent. |
| Warehouse-native semantic views | Snowflake Semantic Views, Databricks Metric Views | Your stack is committed to one warehouse and you want metric definitions to live close to compute | Snowflake + Databricks: GA via Context Engineering Studio |
| BI-native semantic model | Looker / LookML, GoodData, MicroStrategy ONE | Your primary consumer is a single BI tool with mature semantic modeling | Looker: GA. GoodData + MicroStrategy: adjacent. |
| Context layer (wraps the above) | Atlan | You need governed metric meaning exposed to AI agents across multiple semantic layers and BI tools | n/a (Atlan is the context layer, not a standalone semantic layer) |
Semantic layer vs context layer vs metadata layer: what’s the difference?
Permalink to “Semantic layer vs context layer vs metadata layer: what’s the difference?”A semantic layer defines what metrics mean. A context layer governs how AI agents use those definitions. A metadata layer catalogs what data exists.
A semantic layer defines metrics. It tells your BI tool what “monthly active users” means in SQL or YAML and serves that definition to dashboards and embedded analytics. What it doesn’t do: govern who can use that definition, trace where it came from, or expose it to AI agents with an audit trail.
A context layer governs how AI agents and analysts use those metric definitions in production. It binds them to lineage, ownership, business glossary terms, and access policies, then exposes that governed context to MCP-connected agents and other AI-native interfaces. It complements the semantic layer underneath. It doesn’t replace metric computation. See context layer vs semantic layer for the full distinction, and agent context layer architecture for a production walkthrough.
A metadata layer is the catalog underneath both. It indexes what data exists, where it lives, and who owns it. Active metadata is what makes that catalog queryable by AI agents and analysts. It does not define what metrics compute or govern how agents consume them.
The three layers are complementary, not substitutes. Most “all-in-one” pitches collapse them into one product name. The confusion costs money during evaluation.
What are the best semantic layer tools for AI agents specifically?
Permalink to “What are the best semantic layer tools for AI agents specifically?”Semantic layer tools that serve AI agents well combine three properties: API access an agent can call (SQL, GraphQL, REST, or MCP), governance signals an agent can read (lineage, ownership, certification), and metric definitions an agent can ground its answers in. Specific tool readiness varies along these axes. The table below scores each tool.
AI-agent readiness table
| Tool | API access | Governance signals | Metric citation support |
|---|---|---|---|
| dbt Semantic Layer | SQL, JDBC, GraphQL | Medium (via Atlan) | High |
| Cube | SQL, REST, GraphQL, MDX | Medium | High |
| AtScale | SQL, MDX, REST, Python | Medium-High | Medium-High |
| Atlan (context layer) | MCP, REST | High (native governance context) | High (governed, with lineage and policy context) |
| Snowflake Semantic Views | SQL, Cortex Analyst | Medium (via Snowflake governance controls + Atlan) | High |
| Databricks Metric Views | SQL, Genie | Medium (via Unity + Atlan) | High |
| Looker / LookML | SQL, Looker API, Modeler | Low-Medium | Medium |
| GoodData | REST, GoodData Cloud | Low-Medium | Medium |
| MicroStrategy ONE | SQL, MicroStrategy API | Low | Low-Medium |
dbt Semantic Layer, Cube, and the warehouse-native options deliver the API surface. A context layer adds what an AI agent needs beyond the definition itself: who certified the metric, where its inputs came from, and whether the asking user is allowed to see them. Snowflake Intelligence + Atlan deliver 3x query accuracy across a 522-query enterprise benchmark, at 95%+ reliability when grounding text-to-SQL in enriched semantic and context metadata instead of schema alone. See the Atlan MCP Server for the MCP delivery pattern.
How should you choose a semantic layer for your stack?
Permalink to “How should you choose a semantic layer for your stack?”Choose by use case, not feature checklist. For BI metric consistency, pick a code-first semantic layer (dbt Semantic Layer, Cube) or your warehouse’s native option (Snowflake Semantic Views, Databricks Metric Views). For AI-agent governance across multiple semantic layers, add a context layer on top to unify governance, lineage, and access context across them.
Are you a dbt shop standardizing metrics across BI?
Permalink to “Are you a dbt shop standardizing metrics across BI?”dbt Semantic Layer (MetricFlow) is the recommended pick. If dbt Cloud lock-in is a constraint, Cube is the backup: same code-first workflow, no dbt Cloud dependency. Evaluate Cube early if your org runs global or multi-cloud deployments.
Are you committed to one warehouse and want native semantics?
Permalink to “Are you committed to one warehouse and want native semantics?”Snowflake-committed shops should evaluate Snowflake Semantic Views first. Databricks shops should evaluate Databricks Metric Views first. Warehouse-native definitions do not move cleanly to other warehouses, so this choice only makes sense when warehouse commitment is firm.
Do you need a headless semantic layer for embedded analytics or AI apps?
Permalink to “Do you need a headless semantic layer for embedded analytics or AI apps?”Cube is the recommended pick. Its multi-API surface lets embedded analytics, AI copilots, and BI tools query the same metric definitions simultaneously. AtScale is the backup for enterprises with existing OLAP and Excel/Power BI investments that need MDX support.
Are you a large enterprise with a mixed BI estate (Power BI, Excel, Tableau)?
Permalink to “Are you a large enterprise with a mixed BI estate (Power BI, Excel, Tableau)?”AtScale is the default. MDX support and aggregate-aware query acceleration make it the standard choice for Fortune 500s with legacy OLAP commitments. MicroStrategy ONE is a viable backup for organizations with an existing MicroStrategy investment.
Are you building AI agents that need to query metrics across multiple semantic layers?
Permalink to “Are you building AI agents that need to query metrics across multiple semantic layers?”Atlan, as the context layer on top of whichever semantic engine you choose. The semantic layer handles metric definitions. The context layer wraps them in governance and exposes them through MCP so agents inherit ownership, glossary terms, and access controls along with the number. Without that added context, AI answers may still be accurate on paper but harder to govern, audit, and trust in production. See how to build an AI-ready semantic layer.
Match your buyer profile to the right semantic layer tool in 2026. Image by Atlan.
The three walls of semantic-layer-only buying
Permalink to “The three walls of semantic-layer-only buying”Semantic layers without governance fail in production for three repeatable reasons. Name the walls before the procurement cycle and the buying frame changes.
- Wall 1: Ungoverned answers. A semantic layer returns a number; it does not certify it. Agents grounded only in metric definitions can produce the right value with no record of who owns it, where it came from, or who’s allowed to see it. Auditors and exec consumers cannot trust the answer.
- Wall 2: Lineage gap at inference. Definitions live in the semantic layer; lineage lives in the catalog. At agent inference time, the two are not joined. The agent cites the metric but cannot cite the upstream source.
- Wall 3: Cross-tool drift. Two semantic layers (e.g., dbt SL plus Snowflake Semantic Views) drift in definitions when each team owns its own DSL. Without a context layer wrapping both, the same metric returns different numbers in different tools.
Semantic layers without governance is the documented failure mode behind each wall.
Which 9 semantic layer tools made the 2026 shortlist?
Permalink to “Which 9 semantic layer tools made the 2026 shortlist?”Nine tools earned a spot based on category honesty, AI-agent readiness, and OSI participation: dbt Semantic Layer, Cube, AtScale, Atlan (as the context layer), Snowflake Semantic Views, Databricks Metric Views, Looker and LookML, GoodData, and MicroStrategy ONE.
All 9 tools at a glance:
| # | Tool | Category | Best for | AI-agent readiness | OSI participation | Atlan integration |
|---|---|---|---|---|---|---|
| 1 | dbt Semantic Layer (MetricFlow) | Semantic layer (code-first) | dbt shops standardizing metrics across BI + AI | High: MCP-friendly definitions | Yes (OSI anchor) | GA (native ingestion; launch partner) |
| 2 | Cube | Semantic layer (headless) | Embedded analytics, multi-tool consumption, AI apps | High: API-first | Yes | Adjacent (no GA integration; OSI emerging) |
| 3 | AtScale | Semantic layer (universal enterprise) | Large enterprises with MDX/Excel/Power BI legacy + modern BI | Medium-High | Yes | Adjacent |
| 4 | Atlan | Context layer (wraps semantic layers) | AI-agent governance across semantic layers and BI tools | High: MCP Server delivers governed context | Yes | n/a (Atlan itself) |
| 5 | Snowflake Semantic Views | Warehouse-native | Snowflake-committed shops, Cortex Analyst users | High: Cortex-native | Yes | Partial GA (CES generates DDL, deploys to Cortex Analyst; broad native ingestion rolling out) |
| 6 | Databricks Metric Views | Warehouse-native | Databricks-committed shops, Genie users | High: Genie-native | Partial | GA (CES deploys to Genie + creates Metric Views) |
| 7 | Looker / LookML | BI-native (originator) | Google Cloud + Gemini shops, mature LookML investment | Medium | Partial | GA (Atlan catalogs Looker models, explores, views, dashboards) |
| 8 | GoodData | Embedded BI + semantic layer | SaaS companies embedding analytics for end customers | Medium | Partial | Adjacent |
| 9 | MicroStrategy ONE | BI-native (legacy semantic + HyperIntelligence) | Fortune 500 with MicroStrategy heritage | Low-Medium | No | Adjacent |
1. dbt Semantic Layer: the code-first, vendor-neutral standard
Permalink to “1. dbt Semantic Layer: the code-first, vendor-neutral standard”If your analytics engineers already own transformations in dbt, the Semantic Layer extends that same workflow into metric definitions. MetricFlow runs underneath. Definitions live in version-controlled YAML next to the models they reference. dbt Labs anchored Open Semantic Interchange (OSI) in 2024, which makes those definitions portable across BI tools and AI agents rather than locked to one vendor’s syntax. For dbt shops, this is the safest default.
Who it’s for: dbt-committed teams extending their transformation workflow to metrics. Most useful when analytics engineers own metric definitions.
Key capabilities:
- MetricFlow DSL for defining measures, dimensions, entities, and time-grain logic in YAML
- Native consumption via JDBC, GraphQL API, and integrations with Hex, Mode, Lightdash, Tableau, Power BI (the broadest pre-built BI integration ecosystem on this list)
- OSI launch anchor: definitions are portable across BI tools and AI agents
- MCP-compatible definition export for AI-agent consumption
Limitations:
- dbt Cloud is required for the Semantic Layer service in many configurations, which creates friction for global or multi-cloud deployments
- Definitions live in code, not a UI. Adoption is harder when analysts (not engineers) own metric definitions
When Open Semantic Interchange reaches broader adoption, MetricFlow definitions will move across warehouses and AI systems without rewriting.
How Atlan extends dbt Semantic Layer: Atlan natively ingests dbt semantic models and enriches them with ownership, lineage, and quality signals. AI agents querying via the Atlan MCP Server get the dbt definition plus the surrounding governance context. See the Atlan dbt Semantic Layer integration.
Pricing: Part of dbt Cloud. Usage-based with a free individual tier.
2. Cube: the headless universal semantic layer
Permalink to “2. Cube: the headless universal semantic layer”Cube takes the headless route. One metric definition, four APIs (SQL, REST, GraphQL, MDX), and an open-source core that engineering teams can self-host or run on Cube Cloud. The result is a semantic backbone that a BI tool, a product dashboard, an AI copilot, and a third-party integration can all query at the same time without rewriting the metric in each place. That’s why Cube shows up frequently in product analytics, customer-facing embedded dashboards, and AI applications.
Who it’s for: Engineering-led data teams building embedded analytics, customer-facing dashboards, or AI applications that need a single headless semantic API.
Key capabilities:
- Multi-API surface: SQL, REST, GraphQL, MDX from one metric definition
- Open-source core (Cube Core) plus managed cloud option (Cube Cloud)
- Pre-aggregation engine that caches and materializes query results for sub-second embedded analytics response times
- AI-native query patterns and OSI participation
- Strong embedded analytics SDK story for SaaS products
Limitations:
- Engineering-heavy setup compared to BI-native semantic models
- Smaller ecosystem of pre-built BI tool integrations than Looker or dbt SL
- Self-hosted complexity when not on Cube Cloud
The open-source core (cube-js/cube on GitHub) is auditable and community-extensible. Full API reference in the Cube documentation.
Adjacent layer note: Cube is the universal semantic layer; Atlan is the context layer that wraps semantic engines and binds definitions to lineage, ownership, and glossary terms, then surfaces them for AI-agent governance. OSI is the emerging interoperability standard between them.
Pricing: Cube Core is open-source. Cube Cloud starts at a free tier. Enterprise pricing on request.
3. AtScale: the enterprise universal semantic layer
Permalink to “3. AtScale: the enterprise universal semantic layer”Most Fortune 500 data estates didn’t start with a modern warehouse. They started with Excel models querying OLAP cubes via MDX, often a decade before the term “semantic layer” took hold. AtScale’s job is to keep that interface alive while bolting on SQL, DAX, REST, and Python so the same metric serves Power BI, Tableau, ThoughtSpot, and modern custom apps from one definition. The automatic aggregate generation is what makes it scale to billion-row fact tables without manual tuning.
Who it’s for: Large enterprises with significant Power BI, Excel, and MDX investment that want a single semantic layer across the BI estate.
Key capabilities:
- MDX, SQL, DAX, REST, Python API surfaces from one definition layer
- Automatic aggregate generation: builds and manages materialized aggregates without manual tuning
- AtScale AI-Link exposes semantic-layer definitions directly to agent queries via standard APIs
- OSI participation for vendor-neutral definition portability
- Mature enterprise security and governance controls
Limitations:
- Enterprise pricing. Not suited for smaller teams or early-stage data orgs
- Heaviest natural fit for organizations with an OLAP-cube heritage. More configuration overhead than headless options
How Atlan extends AtScale: Atlan layers operational metadata, including lineage, glossary terms, ownership chains, and access controls, around AtScale definitions through context-layer and OSI-aligned patterns.
Pricing: Enterprise pricing. Contact AtScale.
4. Atlan: the context layer that wraps semantic layers for AI
Permalink to “4. Atlan: the context layer that wraps semantic layers for AI”Atlan is not on this list as a semantic layer. It’s the layer on top. Atlan reads and enriches semantic-layer definitions and adjacent metadata, binds them to lineage, glossary, ownership, and access controls, and serves that governed context to AI agents through the Atlan MCP Server. A semantic layer answers what a metric means. The context layer answers whether the agent is allowed to use it, who owns it, and where the number came from.
Who it’s for: Data and AI leaders building AI-agent workflows across one or more semantic layers, who need governance and MCP delivery layered on top of the stack they already have.
Key capabilities:
- Context Engineering Studio bootstraps, tests, and deploys governed context for AI systems like Cortex Analyst and Genie, complementing the semantic layers and warehouse-native models already in place
- Atlan MCP Server delivers governed context (definitions, lineage, policies, and audit-relevant metadata) to AI agents at inference time
- Enterprise Data Graph links metrics, glossary terms, lineage, and ownership across the stack so AI systems consume them as connected context, not isolated metadata
- Context Lakehouse and Context Repos provide versioned, portable, policy-aware context readable by MCP-connected agents and other AI systems
- Native dbt Semantic Layer ingestion and first-class cataloging of Looker semantic models, explores, views, and dashboards
Limitations:
- Not the right tool if you only need BI metric definitions on their own. In that case a pure semantic layer is usually the better first fit
- Maximum value usually comes from an existing semantic layer or governed metadata foundation. Context Engineering Studio can also bootstrap from dashboards, SQL, and metadata already in the stack
The clearest framing comes from Atlan’s own product language. A semantic layer answers what a metric means. Context Engineering Studio adds team context, exceptions, certification, and deployment-ready governance around that definition. That’s the extra context AI systems need to ground answers, cite definitions reliably, and support enterprise reviewability.
Workday reports a 5x improvement in AI response accuracy against pre-context-layer baselines after deploying Atlan’s MCP-delivered context. Snowflake Intelligence and Atlan delivered 3x query accuracy in a 522-query enterprise benchmark, which illustrates the gap between schema-only grounding and richer semantic-plus-context grounding.
Pricing: Custom enterprise pricing. Contact Atlan sales for pricing scoped to your stack.
5. Snowflake Semantic Views: warehouse-native metric definitions
Permalink to “5. Snowflake Semantic Views: warehouse-native metric definitions”The pitch is straightforward: if your stack already runs on Snowflake, why stand up a separate semantic service? Snowflake Semantic Views define metrics inside the warehouse, queryable by Cortex Analyst and Snowflake-native BI tools, with role-based access control inherited from the rest of the platform. The tradeoff is portability. Definitions don’t travel cleanly the day the organization decides to add Databricks.
Who it’s for: Snowflake-committed enterprises building Cortex Analyst or warehouse-native AI agents.
Key capabilities:
- SQL-based metric definitions native to Snowflake: no external service to maintain
- Direct consumption by Cortex Analyst for text-to-SQL use cases
- OSI participation (Snowflake is an OSI launch partner)
- Native role-based access control inherited from Snowflake. No separate permissions layer needed
Limitations:
- Tied to Snowflake. Portability outside the warehouse is limited
- Newer than dbt SL or Looker. Feature set is still filling in
- Translation gaps between dbt semantic models and Snowflake Cortex semantic models are a known integration friction point for teams running both stacks
How Atlan extends Snowflake Semantic Views: Atlan’s Context Engineering Studio complements Snowflake-native semantic models by helping bootstrap, test, and deploy governed context for Cortex Analyst and related AI workflows.
Pricing: Included with Snowflake. Compute costs apply at query time.
6. Databricks Metric Views: lakehouse-native metric definitions
Permalink to “6. Databricks Metric Views: lakehouse-native metric definitions”For Databricks shops, Metric Views is the equivalent move: define SQL-based metrics inside the Lakehouse, consume them through Genie, and inherit Unity Catalog governance across the rest of the platform. The AI-agent story is tight when Genie is the agent. It gets more complicated when it isn’t.
Who it’s for: Databricks-committed organizations building Genie or other Databricks-native AI features.
Key capabilities:
- SQL metric definitions native to Databricks, consistent with existing Lakehouse workflows
- Metric View YAML and DDL schemas for code-first metric definition
- Genie consumption for AI agents querying metrics in natural language
- Unity Catalog integration for governance alignment across Databricks assets
Limitations:
- Tied to Databricks. Portability outside the Lakehouse is limited
- Newer than dbt SL or Looker. Feature set is still filling in relative to established options
- Non-Genie agents need an additional integration layer to consume Metric Views
How Atlan extends Databricks Metric Views: Context Engineering Studio deploys to Genie and helps generate Metric Views from existing metadata. Atlan then binds those definitions to lineage, ownership, and approval context so agents consume more than the metric definition alone through the Atlan MCP Server.
Pricing: Included with Databricks. Compute costs apply at query time.
7. Looker and LookML: the BI-native original
Permalink to “7. Looker and LookML: the BI-native original”Looker (now part of Google Cloud) defined the BI-native semantic layer category. LookML was the first code-first modeling language to make it into production at scale, and most modern semantic layers (including dbt SL and Cube) borrowed from its pattern. For Google Cloud and Gemini shops with mature LookML investments, it’s still the default. BI-tool lock-in is the tradeoff every team weighs against the depth of the modeling layer.
Who it’s for: Google Cloud-committed enterprises with mature LookML investments, especially when Looker is the primary BI surface.
Key capabilities:
- LookML code-first semantic modeling: the originator of the pattern now adopted by dbt SL and Cube
- Tight Gemini integration for AI-augmented analytics within the Google Cloud ecosystem
- Native BigQuery optimization for Looker users on GCP
- Looker Modeler lets teams share LookML definitions outside the core BI tool
Limitations:
- BI-tool lock-in. LookML is most powerful inside the Looker surface. Portability outside Looker is limited
- Power BI Semantic Models occupy the same BI-native bracket for Microsoft-aligned organizations
Power BI Semantic Models (honorable mention). Formerly Power BI datasets, these define measures in DAX inside the Power BI service and are the default semantic option for Microsoft-aligned organizations running Fabric or Azure Synapse. Strong fit when Power BI is the primary BI surface. Portability outside Microsoft is limited and OSI participation has not been announced. Treat it as BI-native, same bracket as Looker/LookML, not as a universal semantic layer.
How Atlan extends Looker and LookML: Atlan catalogs Looker semantic models, explores, views, and dashboards as first-class assets in the Enterprise Data Graph, with lineage, certification status, and access policies attached. AI agents querying through the Atlan MCP Server consume that LookML context together with the surrounding governance metadata needed for production use.
Pricing: Google Cloud pricing model. Looker Studio has a free consumer tier.
8. GoodData: embedded analytics with a semantic layer
Permalink to “8. GoodData: embedded analytics with a semantic layer”GoodData is built for a specific job: embedding analytics inside someone else’s product. Its Logical Data Model treats multi-tenancy as the default, not an afterthought, so one metric definition can serve thousands of customer tenants with isolated per-tenant data access. For SaaS companies shipping dashboards to end customers, that’s the whole game. For internal enterprise analytics, the fit is narrower.
Who it’s for: SaaS companies embedding analytics for end customers. Multi-tenant scenarios where one metric definition serves many tenants.
Key capabilities:
- Logical Data Model (LDM) for semantic modeling: versioned, reusable, multi-tenant by design
- White-label dashboard delivery with multi-tenant isolation
- Headless mode for API-only consumption in custom application builds
- Partial OSI participation
Limitations:
- Niche fit. Not a general-purpose semantic layer for internal analytics
- AI-agent story is less developed than dbt SL, Cube, or warehouse-native options
- Smaller ecosystem than dbt SL or Cube for third-party integrations
GoodData is the embedded-analytics layer for SaaS products. Atlan is the context layer for the internal stack. The two solve different problems.
Pricing: Tiered by usage. Free trial available.
9. MicroStrategy ONE: enterprise BI semantic heritage
Permalink to “9. MicroStrategy ONE: enterprise BI semantic heritage”MicroStrategy’s semantic model predates the term “semantic layer” by a decade. Banks, insurers, and Fortune 500 retailers built years of business logic on top of it. MicroStrategy ONE is the modern wrapper around that investment, with HyperIntelligence overlays for embedded analytics and an Auto AI agent for natural-language query. Greenfield teams should keep looking. Teams already running MicroStrategy can stay there while picking up AI augmentation on top.
Who it’s for: Fortune 500 organizations with mature MicroStrategy investments in financial services, insurance, and large retail. Not for greenfield builds.
Key capabilities:
- Schema-based semantic modeling with decades of production maturity
- HyperIntelligence for embedding analytics context into enterprise applications
- AI/BI agent (Auto) for natural language query on top of the semantic model
- Native security inheritance and broad connector coverage for legacy enterprise systems
Limitations:
- Heavyweight platform. Longest implementation cycle of any tool on this list
- AI-agent readiness is improving but lags Snowflake, Databricks, and dbt SL native options
- No OSI participation yet, which is a portability risk as the standard matures
How Atlan extends MicroStrategy ONE: Atlan as context layer exposes MicroStrategy semantic objects to MCP-connected agents with an audit trail.
Pricing: Enterprise licensing. Contact MicroStrategy.
Which tools market themselves as semantic layers but aren’t?
Permalink to “Which tools market themselves as semantic layers but aren’t?”Some tools market themselves as semantic layers when they actually live in adjacent categories: OLAP query accelerators, agent-orchestration layers, and BI tools with built-in semantic modeling. Each has merit in its real category. The buying decision changes the moment you name the category accurately, and a category-adjacent tool used in place of a true semantic layer creates downstream integration debt.
Holistics is the clearest example. Its semantic modeling (Analytics Modeling Language and AQL) is strong inside the Holistics BI surface, but it does not serve metric definitions to agents or external BI tools with the depth of dbt Semantic Layer or Cube. Read alongside the ontology vs semantic layer comparison.
A reliable test: ask which semantic layer the tool consumes or replaces. If the answer is “we are the semantic layer” but the core function is OLAP acceleration, agent orchestration, or BI dashboarding, the tool is category-adjacent. Naming the category accurately costs nothing and saves months of buyer regret.
Is dbt a semantic layer or a metrics framework?
Permalink to “Is dbt a semantic layer or a metrics framework?”dbt itself is a transformation framework. The dbt Semantic Layer (powered by MetricFlow) is a separate layer built on dbt models that defines, computes, and serves metrics. Many teams say “we use dbt” when they mean transformations only.
Three distinct layers in the dbt stack:
- dbt Core is the open-source transformation framework: SQL and Jinja, version-controlled, runs anywhere
- dbt Cloud is the managed dbt platform: IDE, scheduling, CI/CD, and collaboration on top of dbt Core
- dbt Semantic Layer is the metric definition layer: MetricFlow YAML definitions, served via API to BI tools and AI agents
If your dbt project does not have MetricFlow definitions, you have dbt but not the Semantic Layer. Adopting it extends the workflow from transformation to metric definition. See the Atlan dbt Semantic Layer integration.
Core, Cloud, and Semantic Layer: what each layer actually does. Image by Atlan.
Do you need a semantic layer if you already have a data catalog?
Permalink to “Do you need a semantic layer if you already have a data catalog?”A data catalog and a semantic layer solve different problems. The catalog indexes what data exists and who owns it. The semantic layer defines what metrics mean and how to compute them. Enterprises building AI agents need both, plus a context layer to govern how the agent uses metric definitions.
A data catalog answers “what data do we have?” A semantic layer answers “what does ‘monthly active users’ mean?” A context layer answers “how does an AI agent use that definition safely?” Most enterprises run all three. What is a context layer walks through the stack with production examples.
Customer evidence: how DigiKey and CME Group govern semantic layers for AI
Permalink to “Customer evidence: how DigiKey and CME Group govern semantic layers for AI”Three enterprise customers anchor the pattern. DigiKey activated marketplace metadata into AI governance and MCP-delivered context. CME Group put 18 million assets and 1,300 glossary terms into production in year one of its context-layer build with Atlan. Gartner named Atlan a Leader in the 2026 Magic Quadrant for Data & Analytics Governance, citing AI-native governance through context-based partnerships and agentic stewardship.
DigiKey
Permalink to “DigiKey”Atlan activated marketplace metadata for DigiKey, one of the largest electronic-component distributors in the world, by surfacing product, supplier, and pricing context into AI governance and serving it to AI agents via an MCP server.
CME Group
Permalink to “CME Group”Scale proof: 18 million assets cataloged with 1,300 glossary terms in year one of the context-layer build. The glossary terms are the semantic investment. The catalog is the governance layer.
Context Agents Accelerator
Permalink to “Context Agents Accelerator”In a 2-week program with 50+ enterprise customers in April 2026, Atlan’s Context Agents generated 690,000+ description updates with 87% rated on par or better than human. Work that took 9-12 months in governance-first programs now ships in 30 days.
How should you evaluate a semantic layer for the AI era?
Permalink to “How should you evaluate a semantic layer for the AI era?”Use the Context-Era Semantic Layer Test, four axes: category honesty, AI-agent readiness (MCP, governance signals, citation support), OSI participation, and context-layer integration.
Four moves separate teams that ship AI agents from teams rebuilding metric definitions every quarter:
1. Pick a pure semantic layer first. Whether that’s dbt Semantic Layer, Cube, AtScale, Snowflake Semantic Views, or Databricks Metric Views depends on your stack. Do not let a context layer or catalog tell you it replaces this step.
2. Layer a context layer on top. The context layer binds metric definitions to lineage, ownership, business glossary, and access policies, then exposes that governed context via MCP. Without it, AI-agent answers may still be correct on the metric itself but remain harder to govern, audit, and trust at production scale. Semantic layers without governance is a documented failure mode.
3. Insist on OSI participation. A semantic layer that locks definitions to one vendor’s syntax becomes a migration problem as the standard matures. OSI is the portability signal worth requiring from vendors in 2026.
4. Validate AI-agent readiness with a real agent query. Ask: “Can a Cortex Analyst or Genie agent answer Q1 ARR correctly AND cite which definition it used?” If the answer is no, the stack is not AI-ready.
Pair your semantic layer with a context layer
Permalink to “Pair your semantic layer with a context layer”The AI-agent-readiness question is what sits on top of your semantic layer. A semantic layer defines metrics. A context layer governs how those definitions get used, cited, and trusted by AI agents. Atlan’s Context Engineering Studio, MCP Server, and context-layer architecture are designed to wrap the semantic layers already in your stack so teams can govern the definitions they already have and expose them through MCP.
See how the context layer pairs with your semantic layer in production.
Book a DemoFrequently asked questions
Permalink to “Frequently asked questions”Which semantic layer tool is fastest to deploy?
Permalink to “Which semantic layer tool is fastest to deploy?”Snowflake Semantic Views and Databricks Metric Views deploy fastest when your stack is already on the warehouse, because definitions live where the compute runs and there’s no separate service to stand up. For dbt-committed teams, dbt Semantic Layer ships metrics through the same YAML and CI/CD path as transformations. Heavyweight enterprise platforms like AtScale and MicroStrategy ONE run quarters, not weeks.
What is the difference between a semantic layer and a metadata layer?
Permalink to “What is the difference between a semantic layer and a metadata layer?”A semantic layer defines what metrics mean and how to compute them. A metadata layer indexes what data exists, where it lives, and who owns it. Modern enterprises use both: the metadata layer (often a data catalog) underneath, the semantic layer on top for analytical consumption.
Can I switch from Snowflake Semantic Views to Databricks Metric Views?
Permalink to “Can I switch from Snowflake Semantic Views to Databricks Metric Views?”Warehouse-native semantic definitions do not move cleanly between warehouses. Snowflake Semantic Views and Databricks Metric Views each use their own SQL dialect, governance model, and consumption surface (Cortex Analyst versus Genie). Teams running both warehouses typically maintain parallel definitions or use a context layer that wraps both and exposes a unified governed view to AI agents via MCP.
Do semantic layer tools work without dbt?
Permalink to “Do semantic layer tools work without dbt?”Yes. Cube, AtScale, Snowflake Semantic Views, Databricks Metric Views, Looker/LookML, GoodData, and MicroStrategy ONE all define metrics independently of dbt. dbt Semantic Layer is the option that ties metric definitions to dbt models. The rest define metrics in their own DSL, SQL, or UI. Pick by where your team owns business logic, not by dbt commitment.
Is Snowflake a semantic layer?
Permalink to “Is Snowflake a semantic layer?”Snowflake is a cloud data warehouse, not a semantic layer. Snowflake Semantic Views is a newer Snowflake feature that lets teams define metrics inside the warehouse, queryable by Cortex Analyst and BI tools. It functions as a warehouse-native semantic layer for Snowflake-committed shops.
How long does a semantic layer implementation take in 2026?
Permalink to “How long does a semantic layer implementation take in 2026?”Implementation time depends on scope. Code-first semantic layers (dbt Semantic Layer, Cube) deliver first metrics within weeks once the underlying models exist. Warehouse-native options (Snowflake Semantic Views, Databricks Metric Views) ship faster when the team already runs on that warehouse. Enterprise platforms (AtScale, MicroStrategy ONE) run quarters. Pairing a context layer compresses governance work from 9-12 months to 30 days for the 50+ customers in Atlan’s 2026 Context Agents Accelerator.
What does Atlan’s MCP Server cost?
Permalink to “What does Atlan’s MCP Server cost?”There is no additional charge for the Atlan MCP Server today. Atlan pricing is custom enterprise based on your stack, asset footprint, and usage profile. Contact Atlan sales for a scoped quote.
What is the Open Semantic Interchange (OSI)?
Permalink to “What is the Open Semantic Interchange (OSI)?”OSI is an emerging standard for defining metrics and semantic objects in a vendor-neutral format. Launched with backing from dbt Labs and Snowflake in 2024, OSI lets semantic-layer definitions move across BI tools, warehouses, and AI agents without rewriting. Adoption is early but accelerating.
Sources
Permalink to “Sources”- Snowflake Intelligence + Atlan: 3x query accuracy. Snowflake Intelligence + Atlan partner talk-to-data (522-query enterprise benchmark; 95%+ reliability when grounding text-to-SQL in glossaries + semantic layers + quality metadata vs schema-only)
- dbt Semantic Layer launch + MetricFlow. dbt Semantic Layer quickstart documentation
- Open Semantic Interchange (OSI) standard. opensemanticinterchange.org
- Snowflake Cortex Analyst documentation. Snowflake Cortex Analyst overview
- Cube data model and API reference. Cube documentation
- Databricks Metric Views + Genie integration. Databricks Metric Views documentation
- AtScale semantic layer platform. AtScale semantic layer documentation
