Agentic analytics took over BI conversations in 2026, and like most fast-moving terms it's used to mean several different things — some of them just a chat box with a new label. This is a plain-language explainer for data leaders and practitioners: what agentic analytics actually is, how it differs from text-to-SQL and from "a chatbot on a dashboard," and why the trustworthy version of it depends on a semantic layer.
TL;DR
Agentic analytics is AI-native BI where AI agents do the analytical work — answering questions, building calculations, and taking action — by querying a governed semantic layer instead of raw tables. It's more than text-to-SQL (which only translates English into a query) and more than a chat box on a dashboard (which is bounded by what the dashboard already shows): an agent reasons over certified metrics across multiple steps and produces answers you can trace. The semantic layer is what makes those answers trustworthy — it defines every metric once and enforces access rules before any query runs. Cube is the agentic analytics platform built on a semantic layer (its open-source core, Cube Core), serving both internal BI and embedded analytics from one governed model.
A working definition
Agentic analytics is business intelligence in which AI agents perform the analytical work — not a person assembling a report, and not a model that merely writes one query. An agent takes a goal ("why did margin drop in EMEA last quarter?"), plans a sequence of steps, queries governed metrics, builds the calculations it needs, checks its own results, and returns an answer — often with the ability to take a next action, like saving a calculation or assembling a view.
The word "agentic" is doing real work there. A single text-to-SQL call is a transaction: question in, query out, one answer. An agent operates in a loop — decomposing a vague question, running several queries, noticing a number looks off, refining, and only then responding — which is what lets it handle the messy, multi-part questions humans actually ask. The other load-bearing phrase, "governed semantic layer instead of raw tables," is what separates a parlor trick from a system you'd trust with board numbers, and the part we'll spend most of this piece on.
What agentic analytics is not
It's not text-to-SQL
Text-to-SQL translates a natural-language question into a query against whatever tables exist. It's genuinely useful, and an agent may use it internally — but on its own it gives a model access to your data, not understanding of it: the model still guesses your join paths, what "revenue" means, and which rows a user may see, freshly every time. It's a single capability; agentic analytics is the surrounding system — planning, iteration, governed definitions, enforced permissions — that makes that capability safe and consistent.
It's not a chatbot bolted onto a dashboard
The most common thing shipped under the agentic banner is a chat box added to an existing BI tool: ask a question and it helps you navigate the dashboard, or queries the dashboard's own model. It's bounded by what that dashboard computes, rarely reasons across multiple steps, and usually can't build something new or take action. The chat box is a thin interface on a human-driven tool; agentic analytics is an architecture in which the agent is the primary way work gets done, with a governed model underneath keeping it honest.
This matters for buyers because nearly every previous-generation BI tool now has a chat assistant — Looker has Gemini, Tableau has Einstein, Power BI has Copilot, Metabase has Metabot — AI features retrofitted onto architectures designed for a dashboard-first world. Agentic analytics, done properly, is AI-native: built around the agent rather than the dashboard. The previous era of a category rarely wins the next one, and BI is unlikely to be the exception.
The two-pillar bar: what good agentic analytics should deliver
It's easy to wave at "AI for analytics" and hard to say whether a product clears a real bar. A useful test has two pillars; genuine agentic analytics does both:
- Let people do things they couldn't before. Someone in support, sales, or ops who can't write SQL and doesn't know the data model can ask a hard, specific question in plain language and get a correct, governed answer — without filing a ticket and waiting two days.
- Make skilled people faster. The analysts and data engineers who can write SQL stop hand-writing the same joins and metric logic for the hundredth time. The agent drafts the analysis; the expert reviews, corrects, and extends it — spending their time on judgment, not boilerplate.
A chat box that only autocompletes a dashboard clears neither bar well, and raw text-to-SQL clears the first for simple questions but fails the trust test on hard ones. Clearing both, reliably, is why the semantic layer turns out to be non-optional.
Governance vs. flexibility, and why it's a false choice
Here's the tension every data leader feels about pointing an AI at the warehouse. Lock it down and it's safe but useless — it can only answer the handful of questions you anticipated. Set it free and it's powerful but dangerous — it invents metric definitions, double-counts on a bad join, and is one clever prompt away from showing a user another customer's data.
This looks like a tradeoff. It isn't, if the semantic layer is SQL-first and extensible at query time. Governed definitions stay fixed: what counts as "revenue," "active user," or "churn," the correct join paths, and the access policies are defined once, and the agent can't redefine them on a whim. The agent then builds freely on top — composing ad-hoc calculations, filters, groupings, and ratios using those governed metrics at query time. So the constraint is on the meaning of a metric, not the questions you can ask of it: exactly the freedom you wanted to grant and exactly the freedom you wanted to withhold. Every point in that open-ended space is built from definitions your data team owns and tested.
Permissions resolve the same way, and this is what makes governed agents safe in front of real users. The robust approach enforces access rules before the SQL is generated, not after. The user's context — tenant, role, region — is part of how the query is compiled, so the SQL the layer emits already carries the right restrictions, and an agent acting for a single-tenant user can't construct a query that returns another tenant's rows. The security boundary is the query compiler, which the agent doesn't control — not the prompt (jailbreakable) or a post-hoc filter (bypassable).
Why a semantic layer is required for trustworthy answers
Pull the previous sections together and the conclusion is hard to avoid: agentic analytics you can
trust requires a semantic layer — for a structural reason, not a vendor preference. Point an LLM at
raw tables and it has to re-derive the business on every prompt. A table named orders doesn't
encode whether revenue is gross or net, includes tax, or excludes refunds; the join graph has
fan-outs and three tables that all look like "the customer"; and nothing in a SELECT distinguishes
a correct query from one that leaks another tenant's data. So "what was revenue last quarter?" can
return three different numbers across three sessions, any of which might quietly include rows the user
shouldn't see. That's not a prompt-engineering problem you fix with one more example in the context
window — it's a missing layer.
A semantic layer is that layer. It encodes, once, what the business means — metrics with exact
definitions, dimensions and the entities they belong to, the join paths between them, and the access
policies that govern them. The agent selects from that model instead of authoring SQL: "revenue by
region for the last four quarters" becomes a request for the revenue measure grouped by the
region dimension, not a freshly invented 40-line query that might be subtly wrong. Defined once,
"revenue" means one thing for the agent, the dashboard, the embedded app, and the spreadsheet.
Answers become consistent, governed, and explainable — you can see which named metrics produced a
number instead of auditing a wall of generated SQL.
This is not theoretical. Brex evaluated approaches for grounding AI on their data — including the dbt Semantic Layer and LookML — and chose Cube, then built Brex Spaces, an embedded AI financial analyst, on top of it. Their summary is the cleanest one-line case for this whole category: the semantic layer is what makes the AI useful.
Agentic analytics in context
It helps to place it next to the two approaches it's most often confused with.
| Traditional BI | Text-to-SQL | Agentic analytics | |
|---|---|---|---|
| Who does the work | A person drags fields onto a dashboard; an analyst writes the SQL behind it | A model writes one query per question; the human interprets and iterates | An AI agent plans, queries, builds calculations, checks itself, and can take action |
| Governance | Enforced in the BI tool, for that tool only | Usually downstream or absent; a correct and a leaking query look identical | Defined once in the layer; access rules enforced before the query is generated |
| Consistency | Consistent within the tool's curated content | Inconsistent — the same question can return different numbers | Consistent — metrics are defined once, the agent selects them |
| Explainability | Traceable to a known report | A wall of generated SQL; hard to audit | Maps to named, documented metrics; you can see what was asked |
Traditional BI optimizes for governed, curated reporting and pays in flexibility and the ticket queue; text-to-SQL optimizes for flexibility and pays in trust. Agentic analytics aims to get both at once — and the only way that works is the governed semantic layer in the third column.
Where Cube fits
Cube is the agentic analytics platform built on a semantic layer. Its open-source foundation, Cube Core (Apache 2.0), is the semantic layer: you model metrics, dimensions, joins, and access rules once. The platform exposes that governed model to agents over an MCP server (and over SQL, REST, and GraphQL): the agent lists the available measures and dimensions and requests them by name rather than writing SQL. Row-level, multi-tenant security is applied at compile time, pre-aggregation caching keeps agent queries fast, and the layer is SQL-first and extensible at query time — so the agent builds ad-hoc calculations on certified definitions and never writes raw SQL against tables. Crucially, the same governed model serves both pillars: internal BI for your own teams and embedded analytics for your customers, including an AI analyst inside your own product. That's the lesson from Brex Spaces, and it's why 400+ companies build on Cube across both use cases.
Two clarifications that come up immediately. dbt is a partner, not something agentic analytics replaces: dbt models the data; the platform governs the metrics and serves them to BI, embedded apps, and agents — model in dbt, serve via Cube, which reads dbt models. (Only the dbt Semantic Layer, MetricFlow, is an alternative — and to Cube Core, not the platform.) And it does not replace your warehouse: it sits on top of Snowflake, BigQuery, Redshift, or Databricks, which stay your storage and compute, and adds the semantic model, governance, caching, and the AI and API surfaces above them.
If you're comparing specific products — Cube, Omni, Hex, Sigma, Looker, Metabase, ThoughtSpot — the best agentic analytics platforms guide is the head-to-head. For the foundation, see what a semantic layer is and why AI agents need a semantic layer.
Our verdict
Agentic analytics is the next generation of BI: AI agents do the analytical work over a governed semantic layer, instead of a human assembling dashboards or a model guessing SQL against raw tables. The test that separates it from a relabeled chat box is whether it clears both pillars — letting non-experts ask hard questions and making experts faster — and it can only clear them with a semantic layer underneath, because that's what keeps answers consistent, governed, and explainable. The strongest fit is a platform that's AI-native end to end and built on a semantic layer serving internal BI and embedded analytics from one model — that's Cube. A previous-generation BI tool with a chat assistant added can help today, but it's solving a narrower problem.
Methodology
This explainer describes agentic analytics as the term is used in 2026, weighted toward the properties that matter when an AI answers on behalf of other people: metric consistency, access control enforced before query execution, explainability, the two-pillar usefulness bar, and the interfaces (notably MCP) an agent uses to reach governed data. The field is moving quickly — "taking action" capabilities and MCP support in particular — so treat product-specific claims as version-dependent and confirm them against current documentation. As the publisher, Cube has an obvious interest here; we've tried to define the category neutrally and be explicit about where other approaches fit.