The Best Data Intelligence Layers for AI Agents (2026)

An AI agent is only as good as the layer between it and your warehouse. An LLM pointed at raw tables will write plausible SQL, but guess the wrong join, and hand a VP a revenue number that is off by a product line nobody noticed. The same model, when working underneath a governed data intelligence layer, stops guessing, because the metrics, relationships, and permissions are already defined for it.

That much is now common ground. The harder question is which layer to build on, because they differ sharply. A layer that answers "revenue by region last quarter" cleanly can fall apart the moment someone asks the second question. This post defines what a data intelligence layer actually is, explains why they differ so much once AI is involved, and ranks the ones built to feed an agent.

What a data intelligence layer actually is

A data intelligence layer is the governed set of business definitions an agent queries by name instead of writing raw SQL: metrics like revenue and active customer, the dimensions you slice them by, the relationships between tables, and the permissions that decide who sees what. Most people call this the semantic layer or the metrics layer. "Data intelligence layer" is the same idea framed around its job in the AI era, which is to be the thing an agent reasons over.

The distinction that matters: a data catalog describes your data, and a data intelligence layer computes it. A catalog tells an agent that a revenue column exists in four tables. An intelligence layer tells it which definition of revenue is correct, how to compute it, and which one to refuse to expose to a user who lacks access. Agents need the second kind.

Any analytics agent that's built for reliability and compounding capabilities need an intelligene layer. When this layer is missing, the failure is inevitable: three teams asked for last month's revenue will hand back three numbers, because each analyst wrote their own SQL against their own idea of the schema. An agent does the same thing, faster, and with more confidence. When those AI answers come back wrong, our reflex is to blame the model. Usually the real cause sits one layer down: with no governed layer to stand on, the AI is guessing at definitions the business never agreed on. The layer is the missing piece, and the model is mostly doing its job.

Not all data intelligence layers are equal

"Has a semantic layer" gets treated as a yes-or-no checkbox, when the real question is how much of your actual analytical work the layer can express before it gives up.

It helps to see three levels of maturity.

Level one is direct text-to-SQL. The model reads raw schemas and writes SQL from a prompt. It demos beautifully and degrades in production, because the model has to infer business logic, join paths, and metric definitions from low-context table structures. Even when the SQL runs, the meaning can be wrong.

Level two is a conventional semantic layer with a rigid intermediary format. The agent no longer writes SQL directly. It maps the request into a structured payload, usually a metric, a dimension, a time range – grounded in governed definitions, and the platform compiles that to SQL. For "monthly revenue by region," this works well and safely.

It is a genuine improvement.

Yet, level two has a ceiling, and if you ever work with them, you see stakeholders hit it constantly. The moment someone asks for revenue growth versus last quarter, average deal size by rep, top ten products with percent of total, or retention by acquisition cohort, a rigid metric-plus-dimension format cannot represent the request. The agent then has two options: refuse, or fall back to writing raw SQL. That fallback is the trap. The system is still marketed as "AI over a semantic layer," but in practice it is governed when the question is easy and probabilistic when the question is hard.

Not all semantic layers are equal

Level three is an expressive semantic layer with a composable query language. The intermediary is no longer a fixed template. It is a query language built for analytics, so the agent can break a hard question into governed steps - rank, filter, aggregate, compare across time – without ever dropping to raw SQL. The agent stays inside the governed model for a far larger share of the question space.

The difference shows up in real buying decisions. We have watched teams drop well-regarded vendors for one reason: the semantic layer was generic, and you could not change a definition when your business failed to match the vendor's built-in assumptions. A rigid layer that cannot bend to your business is a layer your agent will keep escaping from.

The practical implication for evaluation is this: the question to ask is no longer whether a vendor has a semantic layer, but how much of your real question space it can express natively, and what happens on the second and third follow-up.

How to evaluate data intelligence layers

Six criteria, weighted toward what actually determines whether an agent stays trustworthy.

1. Expressiveness. Can the layer express multi-step analytics – period comparisons, nested aggregation, cohorts, top-N with composition – natively, or does the agent fall back to SQL? This is the load-bearing criterion.
2. Agent interface. Does it expose an MCP server or API that your own agent can read? Many buyers no longer want the vendor's chatbot at all. What they ask for instead is an endpoint their own agents can read over MCP – one that exposes the grain, the table relationships, and the metric logic – so the value lands in the governed connection rather than in a conversational UI.
3. Governance the agent inherits. Do metric definitions and row-level permissions apply to agent queries automatically, or is governance bolted on?
4. Ownership and portability. Are definitions version-controlled, as-code, and portable, or are you locked into a proprietary tool? The teams that care most ask it directly: can we version-control these definitions and own them, or are we trapped in one vendor?
5. Warehouse and dbt coexistence. Data-mature teams already have a semantic home. They want to inherit it, rather than rebuild it.
6. Warehouse coverage. How many engines it supports, and whether it ties you to one.

The best data intelligence layers for analytics agents

Holistics

Holistics offers a code-based data intelligence layer built for the AI era. It uses AML (Analytics Modeling Language) to define models and relationships, and AQL (Analytics Query Language), a composable query language where period comparisons, nested aggregations, cross-grain ratios, and cohort logic are first-class operations. Natural language compiles to AQL, and AQL compiles deterministically to SQL, which keeps the agent reasoning inside governed abstractions instead of improvising. It exposes an MCP server and CLI, so Claude, Cursor, Codex, or an internal agent can explore models, run queries, and build analysis through the same definitions humans use.

This is the rare layer that sits at level three. Because definitions are code, they are versionable, reviewable, and machine-readable, and the same governance covers people and agents.

Honest limit: you invest in modeling up front, and Holistics is a smaller vendor than the cloud incumbents. If you want zero setup, look elsewhere.

Best fit: teams that want expressive governance-as-code, shared by humans and their own agents, without locking into a single warehouse.

dbt Semantic Layer (MetricFlow)

If your business logic already lives in dbt, this is the natural extension. MetricFlow centralizes metric definitions, and the dbt MCP server exposes them to any MCP-compatible agent through a Semantic Layer toolset (with tools like list_metrics). dbt's own 2026 benchmark reported near-100% accuracy on covered queries and roughly an 83% success rate across natural-language questions.

Honest limit: the expressiveness ceiling is real. Complex multi-step patterns still strain the metric grammar, and the query interface has constraints that push some logic back toward SQL. Strong inheritance story, capped depth.

Best fit: dbt-native teams that want their existing definitions to become agent-readable without a second modeling tool.

Cube

Cube is a headless, API-first semantic layer positioned squarely at agentic analytics. It exposes its model over MCP alongside SQL, REST, and GraphQL, so BI tools, embedded apps, and agents all read the same certified definitions. Its open-source core makes it popular for embedding.

Honest limit: SQL-native and lighter on the most complex metric composition than a purpose-built analytical language. Excellent plumbing; you supply more of the modeling rigor.

Best fit: engineering teams that want a warehouse-neutral, API-first layer feeding both apps and agents.

Looker (LookML)

Looker's LookML is a mature, version-controlled modeling layer, and Google has invested heavily in agents: a Looker-managed MCP server lets external agents connect without middleware. The proof point is real – PayPal scaled conversational analytics to over 3,000 users through Claude Desktop and the Looker MCP server.

Honest limit: LookML is powerful but verbose and file-heavy, and the experience pulls toward the Google and BigQuery orbit – some of its documentation features only work when BigQuery is your warehouse, which strands teams on other engines. More than one team has told us it simply feels heavy, one more code set to keep alive.

Best fit: organizations already invested in LookML and the Google Cloud stack.

AtScale

AtScale is a universal semantic layer with OLAP heritage and strong enterprise BI fan-out. Its MCP server ships in the Databricks MCP Marketplace, and it positions itself as the neutral governed layer many tools read from.

Honest limit: enterprise-weighted, and more oriented to classic BI consumption than to a code-first, developer-owned workflow.

Best fit: large enterprises that need one governed layer serving many BI tools and, increasingly, agents.

Snowflake Cortex (semantic views)

If you are fully committed to Snowflake, Cortex Analyst answers natural-language questions against semantic models, and Snowflake's managed MCP server exposes semantic views to external agents like Claude. Semantic views reached general availability in March 2026. Native, tight, well-integrated.

Honest limit: warehouse-locked by design, and the managed MCP server supports semantic views specifically, so your governed surface lives inside Snowflake.

Best fit: Snowflake-committed teams that value native integration over portability.

Databricks (Unity Catalog metric views)

Metrics in Unity Catalog are governed, reusable objects you define once and query from SQL, BI, APIs, and agents. Genie increasingly relies on those metric views rather than inventing local ones, and materialization speeds agent queries.

Honest limit: the same lakehouse lock-in tradeoff. Teams running it treat Databricks as the source of truth, define metric views in Unity Catalog, and sync changes out from there. Strong if the lakehouse is your primary platform.

Best fit: Databricks-native teams standardizing metrics in Unity Catalog.

Honorable mention: Malloy

Malloy is an open-source language that is both a semantic model and a query language, with composition and nested data as first-class syntax. Its Publisher server puts a Malloy semantic layer in front of a warehouse so apps, BI, and agents compose queries against the model instead of writing SQL. Every query leaves a reusable model behind, which is a genuinely elegant approach to expressiveness.

Honest limit: it is a language and an open-source server, rather than a full governed enterprise platform with the surrounding access control, cataloging, and support. Powerful core, smaller ecosystem.

Best fit: technical teams that want expressive, open-source modeling and are comfortable assembling the rest.

Comparison at a glance

Layer	Expressiveness	Agent interface	Governance inherited	Ownership / portability	Best for
Holistics	High (AQL, composable)	MCP + CLI + API	Yes, code-defined	High, as-code, warehouse-neutral	Governance-as-code for humans + own agents
dbt Semantic Layer	Medium	MCP + API	Yes	High, as-code	dbt-native teams
Cube	Medium	MCP + SQL/REST/GraphQL	Yes	High, warehouse-neutral	API-first apps + agents
Looker (LookML)	Medium–High	Managed MCP	Yes	Medium, Google-leaning	LookML / GCP shops
AtScale	Medium–High	MCP (Databricks marketplace)	Yes	Medium, enterprise	Multi-tool enterprise BI
Snowflake Cortex	Medium	Managed MCP (semantic views)	Yes, in-warehouse	Low, Snowflake-locked	Snowflake-committed teams
Databricks (UC metrics)	Medium	MCP / agent access	Yes, in-catalog	Low, lakehouse-locked	Databricks-native teams
Malloy	High (composable)	Publisher server	Model-level	High, open source	Technical teams assembling their own

The honest counter-case

Plenty of data leaders push back on the semantic layer, and the sharpest objection deserves a fair hearing.

The strongest one is maintenance cost at high metric churn. Analysts who understand the tradeoff make it well: you can spend six months defining a full data model, then need another month of work just to cover the metrics from one busy week, and end up maintaining the layer instead of doing analysis. Their alternative is to feed an LLM the table and column descriptions plus examples of past joins, and let it repeat the pattern – lower upfront cost, more flexibility. For teams whose metrics change weekly, that pressure is real, which is exactly why expressiveness and low modeling overhead matter so much. A layer that is expensive to extend gets abandoned.

The second objection is lock-in to a proprietary language. A modeling language that only one platform understands is a heavy thing to commit to, and skeptics are right to name that cost. Even believers want an escape hatch: the ability to pull data out and process it in Python when needed. A good data intelligence layer answers these concerns with version control, readable definitions, and open interfaces. A weak one dodges them.

How to choose

The decision usually comes down to three situations.

• You are fully committed to one warehouse and comfortable with lock-in. The native layer is the right call – Snowflake Cortex semantic views or Databricks Unity Catalog metrics. The integration is tight and the setup is minimal.
• Your business logic already lives in dbt. The dbt Semantic Layer is the natural starting point, with an expressive layer like Holistics or Cube added where you need a richer agent interface and multi-step depth that MetricFlow alone strains to express.
• You want expressive governance-as-code, shared by humans and your own agents, without warehouse lock-in. Holistics is built for exactly this, with Malloy as the open-source option if you are willing to assemble the surrounding platform yourself.

One caution worth keeping in view: Gartner's February 2026 Market Guide for Agentic Analytics projected that by 2028, 60% of agentic analytics projects relying solely on MCP will fail for lack of a consistent semantic layer. MCP is only the connection; the layer behind it determines whether the answers are right.

The layer belongs in place before the agent, and it should be judged by the second and third question, more than the first. That order decides whether the rest of the work holds.