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. (For a broader comparison, see our guide to semantic layers for AI.)

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 needs an intelligence 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 right 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 actual 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 question space it can express natively, and what happens on the second and third follow-up.

How to evaluate data intelligence layers

There are six criteria worth weighing, and they lean toward what actually decides 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?
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' Semantic Layers

Holistics offers a code-based data intelligence layer/semantic layer built for the analytics agents. It uses AML (Analytics Modeling Language) to define models and relationships, and AQL (Analytics Query Language), a composable, metric-first query language that lets AI handle more complex analysis — period comparisons, nested aggregations, cross-grain ratios, and cohort logic — as 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.

Under the hood, Holistics is built like a real programming language, not a semantic layer duct-taped together from YAML files and templated SQL strings. Models, metrics, and relationships are defined in AML with functions, types, and inheritance, so your business logic stays reusable, composable, and maintainable the way real code is: you define a metric once, and every dashboard, embed, API, and AI agent answers from that one definition, compiled down to your warehouse's native SQL. (See how the programmable semantic layer works.)

AQL is what makes those answers trustworthy rather than merely plausible. Because the AI writes a few readable lines of AQL instead of pages of SQL, you can read the logic back and confirm it before it ever runs, and because it works in a high-level language, the model never wrestles with database-specific SQL gymnastics, so it is far more accurate than one writing raw SQL directly. Composability and 90+ built-in analytical functions mean the long-tail questions that break text-to-SQL, like period-over-period, cohort retention, and percent-of-total, each collapse into a single expression. You can explore the full language on the AQL page.

Pause

01Natural languageuser input

"In each region, what's the average revenue of the top 5 countries by users?"

AI · generates

02AQL6 lines · human-readable

metric count_users = count(users.id)
dimensions { region: country.region }
measures {
  avg_revenue:
    top(5, countries.id, by: count_users) | avg(revenue)
}

Compiler · guarantees

03SQL55 lines · auto-generated

WITH "aql__t3" AS (
  SELECT "ecommerce_countries"."continent_name"
    AS "ecommerce_countries→continent_name",
    "ecommerce_countries"."name" AS "name",
    COUNT("ecommerce_users"."id") AS
    "count_ecommerce_users→id"
  FROM "ecommerce"."users" "ecommerce_users"
  JOIN "ecommerce"."countries" …

no SQL gymnastics

Holistics AI writes concise AQL; the compiler expands it deterministically into your warehouse's SQL.

This is the rare intelligence 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.

Reported limitations: 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.

Reported limitations: teams with complex use cases might run to the expressiveness as complex multi-step patterns still strain the metric grammar, and the query interface has constraints that push some logic back toward SQL, so how deep an analysis you can build on top of your definitions is capped.

The other friction dbt shops raise with us is architectural: they don't want to rebuild the semantic layer inside a BI tool, and they worry about maintaining metric definitions in two places. In practice the "define once" promise leaks at the edges as some downstream tools import dbt models and dimensions but not dbt-defined metrics, and metadata like descriptions doesn't always carry through.

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

Cube Dev

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.

Reported limitations: because Cube is SQL-native, it handles the most complex metric composition less fully than a language built specifically for analytics, so you supply more of the modeling rigor yourself. Teams we talk to also treat it as a build-it-yourself component --a standalone semantic layer they wire to the warehouse and then connect their agents into —- which means another layer to integrate and operate rather than a unified experience. Its openness and API-first design are the biggest draw, the tradeoff is that you assemble and maintain the surrounding stack.

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.

Reported limitations: LookML is powerful but verbose and file-heavy. The experience pulls toward the Google and BigQuery ecosystem so some documentation features only work when BigQuery is your warehouse, which strands teams on other engines.

Cost is another objection we hear most, and it hits hardest on embedding, where per-seat pricing makes serving a few thousand external users prohibitively expensive. Teams also describe the product as having stalled since the Google acquisition -- slow to evolve, thinner on support —- and as developer-first: strong for the data engineer, harder for the business user, with routine asks like period-over-period comparison often requiring hand-built custom measures.

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.

Reported limitations: AtScale is built for the enterprise, and it leans toward classic BI consumption more than the code-first, developer-owned workflow that many teams now want.

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. Because everything lives inside Snowflake, the integration is native and tight, with almost no glue code to maintain.

Reported limitations: it is warehouse-locked by design, and the managed MCP server supports semantic views specifically, so your entire governed surface lives inside Snowflake. In the field where the bigger hesitation is trust, teams piloting Cortex tell us adoption stalls because business users find it hard to validate the queries it generates. And as Snowflake absorbs more of the stack, some teams deliberately keep their semantics in dbt and treat Snowflake as an MCP endpoint only, bringing their own AI rather than committing further.

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.

Reported limitations: you take on 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. It works well as long as the lakehouse is your primary platform — the further the rest of your stack sits from Databricks, the less it does for you.

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.

Reported limitations: it is a language and an open-source server, not a full governed enterprise platform with the surrounding access control, cataloging, and support. The core is powerful, but the ecosystem around it is smaller than what the commercial platforms give you.

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

Comparison at a glance

Do you need a data intelligence layer?

It depends.

Plenty of data leaders we talked to push back on the semantic layer for a few reasons:

The most common one is maintenance cost at high metric churn. 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, which has lower upfront cost, more flexibility. For teams whose metrics change weekly, expressiveness and low modeling overhead matter so much more, so 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. A good data intelligence layer answers these concerns with version control, readable definitions, and open interfaces.

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 choice, either Snowflake Cortex semantic views or Databricks Unity Catalog metrics. The integration is quick 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.

Read more

• 11 AI Analytics Platforms in 2026
• 10 BI Tools with Semantic Layers: A Comparison Matrix