Short answer: The best semantic layer for AI agents compiles each agent request from governed definitions, not from SQL the model writes. Look for six things: an MCP or API surface, per-user agent identity, compile-time governance, deterministic output, refusal when a join path cannot be proved, and a point-in-time audit trail. Most semantic layers now ship an MCP server. Few enforce governance before the query exists. Colrows is built for that case.
BI semantic layer vs semantic layer for AI agents
| Dimension | BI semantic layer | Semantic layer for AI agents |
|---|---|---|
| Who calls it | A person inside one BI tool | Agents, thousands of times an hour, from many tools |
| Who checks the answer | The person reading the dashboard | Often no one, because the agent passes the number to its next step |
| Identity | The user's BI session | Per-user OAuth for each agent call, not a shared service token |
| Governance | Scoped to the dashboard | Compile-time, across every consumer |
| Audit | Dashboard view logs | Point-in-time reproducible audit trail per query |
Why do AI agents need a different semantic layer?
Until 2023, "semantic layer" meant a BI feature: a metric definition that a dashboard could resolve. Three things changed that. First, AI agents began issuing thousands of queries per hour against the same warehouse. Second, the warehouses themselves shipped first-party text-to-SQL surfaces (Snowflake Cortex Analyst, Databricks AI/BI Genie). Third, regulated industries discovered that retrieval-only architectures cannot pass audit. The result: at least four distinct products now compete for the same word, and the right one for your stack depends on which problem you actually have.
Agents change the failure mode. A person who sees a wrong number on a dashboard usually notices it. An agent passes the number to its next step, which may be a forecast, an email or another query. One silent error becomes several. The layer under the agent must therefore stop bad queries before they run, not explain them afterwards. Our 7-step governance checklist covers the controls around the agent itself.
What should you evaluate in a semantic layer for AI agents?
Seven criteria predict whether a semantic layer survives contact with AI workloads. The first five apply to any AI use. The last two matter only when an agent, not a person, sends the query. Score each 0-5.
- Graph autonomy - does the platform auto-build the semantic graph from your data sources, or do you hand-author every entity and relationship? Manual scores 0; autonomous detection plus drift handling scores 5.
- Dialect coverage - how many SQL dialects does the compiler support natively? 1-3 dialects scores 1; 10+ with dialect-perfect output scores 5.
- Compile-time governance - are RBAC, ABAC, and row/column-level predicates enforced at compile time, or applied as a post-query filter? Post-filter scores 1; compile-time injection scores 5.
- AI-agent readiness - can agents call the platform via HTTP, JDBC, or an MCP-style tool surface? Does the platform return proven join paths and an audit trail per query? Manual SDK scores 1; full agent surface with proofs scores 5.
- Audit trail and reproducibility - can you re-run a historical query and prove it used the exact definitions in force at that moment? None scores 0; point-in-time reproducible scores 5.
- Agent identity - does each agent call carry the identity of the person it acts for, or one shared service credential? A shared token scores 1; per-user OAuth with the layer's own policy applied scores 5.
- Refusal behaviour - when the layer cannot prove a join path or the user lacks access, does it refuse, or does it return a plausible answer? A best guess scores 0; a typed refusal the agent can act on scores 5. See how to prevent AI hallucinations on enterprise data.
The full evaluation rubric and worked example live on the pillar guide.
Every vendor ships an MCP server. What still separates them?
By late 2026, every semantic layer in this guide offers a Model Context Protocol server or an equivalent agent interface. "Has MCP" no longer separates vendors. Four other questions do: how the agent authenticates, who writes the SQL, when governance runs, and how far one question can reach.
| Layer | Agent interface | Agent identity | Who writes the SQL | Reach |
|---|---|---|---|---|
| Colrows | MCP tools that take questions, plus HTTP and SQL APIs | Governed by the semantic graph, compile-time | The compiler, from the graph | 16+ engines |
| Snowflake (Cortex Analyst) | Managed MCP server, generally available | OAuth 2.0, Snowflake RBAC per tool | A language model over the semantic view | Snowflake only |
| Databricks (Genie) | Managed MCP endpoints | OAuth on behalf of the user, Unity Catalog | A language model over Unity Catalog | Databricks only |
| Looker | Managed MCP server (preview) and MCP Toolbox | OAuth 2.0, each call maps to a Looker user | Looker, from LookML fields the agent selects | Looker models |
| dbt Semantic Layer | dbt MCP server | Service token | MetricFlow, from metrics the agent selects | dbt-supported warehouses |
| Cube | MCP server, plus SQL, REST and GraphQL | Cube access policies | Cube, from certified definitions | Warehouses Cube connects to |
| AtScale | MCP server, including the Databricks MCP Marketplace | AtScale model security | AtScale, then the platform executes | Platforms AtScale serves |
| ThoughtSpot | Enterprise MCP server | ThoughtSpot permissions | Spotter, its AI agent | Multi-cloud |
Read the "who writes the SQL" column carefully. Where a language model writes SQL on every request, the same question can take a different route. The metrics APIs (Looker, dbt, Cube, AtScale) generate SQL from fields the agent picks, so the risk moves to field selection. Colrows compiles from a typed graph, attaches a join path proof, and refuses when it cannot prove one. We compare the servers on auth and write defaults in MCP servers for analytics and BI. MCP governance explains why the protocol alone is not enough.
What does Cube do well, and where does it stop?
Cube (formerly Cube.js) is the developer-first metrics API. You define metrics and dimensions in YAML or JavaScript; Cube exposes them through REST, GraphQL, and SQL APIs. It is the lightweight pick when your consumers are mostly applications and dashboards and your data team is happy hand-authoring metric definitions.
For agents: Cube's January 2026 release added an MCP server that works with Claude, ChatGPT and other MCP clients. The agent selects from certified definitions and Cube generates the query, which is the right pattern.
Where it stops: there is no autonomous graph, no dialect-perfect compiler across 16+ engines, and no compile-time governance for AI agents. Read the Colrows vs Cube comparison.
What does Looker do well, and where does it stop?
Looker (now Google Looker) is the long-running enterprise BI semantic layer, built on LookML. It encodes business meaning for dashboards and explores with strong governance inside the BI surface. If your AI strategy is "agents call our existing Looker explores", it is the natural choice.
For agents: Google offers Looker tools through the open-source MCP Toolbox for Databases and a fully managed MCP server in preview. The managed server uses OAuth 2.0, so each agent action maps to an individual Looker user. Looker, not the model, writes the SQL.
Where it stops: LookML is hand-authored at scale, the dialect surface is BI-centric, and governance is dashboard-scoped rather than compile-time across every consumer. Read the Colrows vs Looker comparison.
What does the dbt Semantic Layer do well, and where does it stop?
The dbt Semantic Layer (powered by MetricFlow) defines metrics on top of dbt models and serves them through a query API. It is the right pick when dbt is already the source of truth for transformations and you want metric definitions to live next to the models.
For agents: the dbt MCP server exposes Semantic Layer tools that list metrics, dimensions and entities and run metric queries. The project's documentation sets it up with a service token, so the agent does not carry the end user's identity by default. The documentation also warns that dbt commands through the server can modify models and warehouse objects.
Where it stops: it is a metric API, not a runtime; there is no autonomous graph beyond dbt-defined entities, no compile-time governance for AI agents, and no dialect-perfect SQL across non-warehouse sources. Read the Colrows vs dbt Semantic Layer comparison. Existing dbt metric definitions can be ingested into Colrows as a starting point.
What does AtScale do well, and where does it stop?
AtScale is the virtual OLAP-cube semantic layer. It serves multidimensional analytics workloads at speed and is the right pick for organisations standardised on tools that consume OLAP.
For agents: AtScale brought its semantic layer to the Databricks MCP Marketplace in December 2025, and says the same server works with Claude and ChatGPT. AtScale generates the SQL and the data platform executes it.
Where it stops: the cube model is not the typed graph that AI agents need for proven join paths, and the agent surface is not first-class. Read the Colrows vs AtScale comparison.
What does ThoughtSpot do well, and where does it stop?
ThoughtSpot is search-driven analytics with Spotter, its AI agent, for natural-language questions. ThoughtSpot removed its older Sage experience in June 2026. It is a strong pick when the goal is end-user search across well-modelled tables.
For agents: ThoughtSpot launched an enterprise MCP server in 2026 so outside assistants can use its analytics. ThoughtSpot also introduced Spotter Semantics, a semantic layer for agents.
Where it stops: the semantic model is BI-application-scoped, not an infrastructure layer that other agents and applications compile through. Read the Colrows vs ThoughtSpot comparison.
What does Snowflake Cortex Analyst do well, and where does it stop?
Cortex Analyst is Snowflake's text-to-SQL service. Its YAML semantic model is the right pick when your entire analytical surface lives inside Snowflake. Snowflake's own September 2025 launch of the Open Semantic Interchange (OSI) initiative, which shipped v1.0 in January 2026 and entered the Apache Incubator as Apache Ossie in June 2026, concedes that semantics belong above any single warehouse.
For agents: Snowflake's managed MCP server is generally available, with OAuth 2.0 and Snowflake RBAC applied per tool. A server carries at most 50 tools, and responses truncate at 250 KB.
Where it stops: it sees only data inside Snowflake; the YAML semantic model is hand-maintained; and there is no cross-estate graph. Read the deep-dive on warehouse-native semantic layers.
What does Databricks Genie do well, and where does it stop?
Databricks AI/BI Genie is the conversational analytics surface on Unity Catalog. Databricks renamed it Genie One in June 2026, and Genie Spaces became Genie Agents. It is the right pick when your data is governed inside Databricks.
For agents: Databricks' managed MCP endpoints authenticate on behalf of the user, so Unity Catalog applies the human's permissions, and Genie tools stay read-only.
Where it stops: each Genie Agent accepts up to 50 tables, views or metric views, raised from 30 on 10 September 2026. Unity Catalog governance ends at the Databricks boundary. Read the deep-dive.
Where does Colrows fit?
Colrows is the semantic execution layer: a runtime that compiles enterprise intent into governed, deterministic, dialect-perfect SQL across 16+ engines. The graph is autonomously built and continuously maintained. Compile-time RBAC, ABAC, and row/column-level predicates are injected before any SQL leaves the planner. Every query produces a point-in-time reproducible audit trail. Read the 7-step pipeline walkthrough and the full pillar guide.
For agents, the Colrows MCP server exposes questions rather than tables. The agent asks for a metric, and the compiler resolves it and proves the join path. The tool surface cannot express a query the user is not allowed to run.
Which semantic layer should you choose in 2026?
Match the product to the problem. If your consumers are mostly humans inside one BI tool, the BI semantic layer is fine. If you live entirely inside Snowflake or Databricks and your queries are structured-only, the warehouse-native surface is the simplest answer. If your AI strategy depends on agents that issue thousands of queries per hour across multiple sources, with regulated audit and governance, the only structurally-correct answer is a semantic execution layer. Talk to us if your stack falls in the third bucket.
Apache Ossie: what it is, and what it is not
Every buyer will hear about the Open Semantic Interchange (OSI). Here is the short and honest read. OSI is a vendor-neutral YAML specification for writing semantic definitions down in a portable shape. Snowflake, Salesforce, dbt Labs, BlackRock, and RelationalAI launched it in September 2025. The v1.0 spec shipped on 27 January 2026 under Apache 2.0. In June 2026 it entered the Apache Incubator as Apache Ossie. More than 50 organisations back it; converters exist for dbt MetricFlow, GoodData, Salesforce, and Apache Polaris. Full explainer: Apache Ossie and Open Semantic Interchange.
What OSI is: a shared way to describe measures, dimensions, and metadata across tools. What OSI is not: an execution engine. It does not compile a query, choose a join path, emit SQL, or enforce governance. The v1.0 core does not codify access policy as a first-class object either. So OSI reduces lock-in on the definition side, but the execution and governance sides are still where products differ.
Backing OSI is not the same as shipping native support for it. Phase-2 adoption across the 50-plus platforms is the 2026 test; de-facto-standard status is targeted for 2027. If portability of definitions matters to your team, watch each vendor's roadmap for real read-and-write support and treat "backed by" and "shipped in" as different signals. This is a category to monitor rather than a checkbox that ranks vendors today.
Fix the Context, Not the Model. A well-governed semantic layer that understands business context creates more reliable AI-driven analytics than fine-tuning the model itself.
Deployment references
Buyer's-guide criteria are only as useful as the deployments that survive them. Three references, one line each, so you can pattern-match: Cipla saw 8× data adoption and greater-than-90% decision-latency reduction after moving to a governed semantic layer. SSP Group reported a 40% cut in data-management overhead with 3× faster issue resolution across 3,000 travel-retail venues. A confidential Indian ARC ran the BFSI test: greater-than-95% cycle-time cut with 100% RBI SARFAESI + DRT coverage. For a CDO-to-CFO framing of these numbers, see the semantic-layer business case.
Frequently asked questions
What is a semantic layer for AI agents?
A semantic layer for AI agents is the governed layer an agent queries through instead of raw tables. The layer holds the business definitions, resolves each agent request against them, enforces access rules, and returns an answer the agent can trust. For agents, it must also carry the user's identity, refuse unprovable queries, and log every call for audit.
Do AI agents still need a semantic layer if they use MCP?
Yes. MCP standardizes how an agent connects to a tool. MCP does not decide what the agent may ask, which definition of revenue applies, or which join path is correct. A semantic layer behind the MCP server supplies those answers. Without one, the agent writes SQL against raw tables and guesses.
Which semantic layers have an MCP server in 2026?
Colrows, Snowflake, Databricks, Looker, dbt, Cube, AtScale and ThoughtSpot all offer an MCP server or managed MCP endpoints in 2026. Status differs: Snowflake's managed server is generally available, while Looker's managed server was in preview. Compare them on agent identity and governance timing, not on whether a server exists.
How should an AI agent authenticate to a semantic layer?
Each agent call should carry the identity of the person it acts for, through per-user OAuth, so the layer applies that person's permissions. A shared service token gives every user the token's access. Snowflake, Databricks and Looker document per-user OAuth for their managed MCP servers.
Is a metrics API enough for AI agents?
A metrics API is a strong start, because the layer writes the SQL from defined metrics. The risk moves to which fields the agent selects. For regulated or cross-warehouse use, also require compile-time governance, a join path proof, refusal when a path cannot be proved, and a point-in-time reproducible audit trail.
A note on the claims
Vendor capabilities come from each vendor's own documentation, release notes and announcements:
- Cube's January 2026 changelog
- Google Cloud's Looker MCP Toolbox and managed MCP server announcements
- The dbt MCP server documentation
- AtScale's Databricks MCP Marketplace announcement (December 2025)
- ThoughtSpot's 2026 release notes and MCP server announcement
- Snowflake's managed MCP server documentation
- The Databricks AI/BI and Genie One release notes for 2026
Preview status changes quickly in this category. Colrows sells a competing product, and we wrote this guide with that disclosed.
Correction, 1 Nov 2026: An earlier version described ThoughtSpot's AI as Sage. ThoughtSpot removed Sage in June 2026, and Spotter replaced it. The earlier version also said Genie was structured-data only and limited to 30 tables per Genie Space. Genie One added chat with documents in June 2026, and each Genie Agent now accepts up to 50 tables.