Traditional BI and agentic analytics are not two feature sets. They're two architectures, and the thing that separates them is where the analytical work happens.
In traditional BI, a person does it: an analyst models the data, decides what a chart should show, and builds the view. The tool renders and distributes it. In agentic analytics, an AI agent does it: it plans the analysis, queries governed metrics, builds calculations on top of them, checks its own work, and returns an answer you can trace back to named definitions.
Everything else follows from that.
The comparison
| Traditional BI | Agentic analytics | |
|---|---|---|
| Who does the analytical work | An analyst models the data and builds the view; business users read it | An agent plans, queries, builds calculations, and checks itself |
| How a new question gets answered | Someone builds a new view — often a ticket and a wait | Composed at query time from definitions that already exist |
| Where governance lives | Inside the BI tool, for that tool only | In a semantic layer beneath every surface |
| When access rules are applied | Filtered in the tool, often after the query | Before SQL is generated, so a forbidden row can't be returned |
| Consistency of a metric | Consistent within the tool's curated content; drifts across tools and workbooks | One definition, resolved identically everywhere it's consumed |
| Explainability | Traceable to a known report someone built | Maps to named, documented metrics; you can see what was asked |
| What breaks at scale | Dashboard sprawl and forked definitions of the same number | Nothing, if the model is governed — everything, if it isn't |
| Primary interface | A dashboard | A question |
What traditional BI actually got right
It's worth being precise about this, because the failure mode of a comparison like this one is to caricature the incumbent.
Traditional BI solved a real problem: making a governed number available to people who can't write SQL, in a form they can read at a glance. Dashboards are genuinely good at that. A well-built dashboard is a shared artifact a team can point at in a meeting, check on a rhythm, and trust because someone maintains it. The modeling layer in a mature BI deployment encodes years of institutional knowledge about what the business actually measures.
None of that stops being valuable. The constraint is narrower than "dashboards are dated": in traditional BI, the cost of an unanticipated question is a person's time. Every question nobody built a view for goes into a queue. Most never get asked, because people learn not to bother.
What changes
Three things, in order of how much they matter.
1. The cost of a new question collapses. This is the whole point. When metric definitions, join paths, and access rules live in a model an agent can read, a question that would have been a ticket becomes a query composed on the spot. The person in support or ops who couldn't write SQL and didn't know the schema asks in plain language and gets a governed answer.
2. Governance moves down a layer. In traditional BI, the rules live in the BI tool, which means every additional tool or surface re-implements them. In agentic analytics the rules live beneath all of them, and — critically — are applied before the SQL is generated. The agent doesn't get filtered results; it gets a query it was never able to construct incorrectly in the first place.
3. The governance-versus-flexibility tradeoff stops being a tradeoff. The old choice was to lock the model down until nobody used it, or open it up and end up with fifteen definitions of churn. A SQL-first semantic layer that's extensible at query time keeps governed definitions fixed while the agent composes ad-hoc calculations on top of them. The constraint is on what a metric means, not on what you're allowed to ask.
Where traditional BI is still the right answer
Three cases, and they're not edge cases.
- Stable, regulated reporting. When the output is a fixed, auditable artifact filed on a schedule, the value is in it being identical every time. An agent's flexibility is not an asset here.
- An audience that wants a view, not a conversation. Plenty of people want the number on a screen where it was yesterday. Turning that into a chat interaction is a downgrade.
- No governed model yet. This is the important one. An agent pointed at raw warehouse tables re-derives joins and metric logic on every prompt, so the same question asked twice returns different numbers — confidently. That is strictly worse than a dashboard someone checked. If you don't have a semantic layer, building one is the prerequisite, not the upgrade.
The retrofit problem
Nearly every previous-generation BI tool now ships an AI assistant — Looker has Gemini, Tableau has Einstein, Power BI has Copilot, Metabase has Metabot. These are real features and they help.
The limit is structural. An assistant added to a dashboard-first tool is generally bounded by what that tool's model already computes. It can help you navigate the dashboard, summarize it, or draft a query against the existing model. What it typically can't do is answer a question nobody built a view for — because the knowledge required to compose that answer was never written down anywhere the assistant can read. It lived in the analyst.
That's the difference between AI-native and AI-added. Not marketing: architecture.
The test. Ask for a metric sliced by a dimension no existing dashboard combines. A chat box bounded by the dashboard's model will fail, deflect, or answer a slightly different question. An agent over a semantic layer will compose it, because the model contains the entities and the join paths. Then ask two follow-ups: can it build and save a new calculation, and can you trace the answer back to a named metric definition?
Where Cube fits
Cube is the agentic analytics platform built on a semantic layer. Cube Core — the Apache 2.0 semantic layer at its foundation, and the original Cube project — defines metrics, dimensions, join paths, and access rules once, in SQL-first models kept in version control, on top of the warehouse you already run.
Everything above reads those same definitions: Analytics Chat for natural-language questions, workbooks and dashboards for the reporting that genuinely should be fixed, embedded surfaces for customer-facing analytics, and an MCP server so agents in Claude or ChatGPT answer from certified metrics rather than improvised SQL. Access rules are evaluated before SQL is emitted, which is what makes pointing an agent at production data reasonable rather than reckless.
Brex chose Cube over the dbt Semantic Layer and LookML for this reason: the semantic layer encodes what "spend" means at Brex, which is what makes the agent's answers useful rather than merely fluent.
Note the shape of that: Cube still has dashboards. The point was never that dashboards are bad — it's that a dashboard shouldn't be the only way to get a governed number.
Methodology
The comparison above describes the two architectures generally and holds regardless of vendor; the closing section is explicitly about our own product, since we build Cube. Competitor AI features are described as of August 2026 and are shipping products, not roadmap — they change quickly, so treat specific capability claims as version-dependent. For the fuller definition of the category, see what is agentic analytics; for a scored comparison of platforms, see the best agentic analytics platforms.
Frequently asked questions
- What is the difference between agentic analytics and traditional BI?
- Traditional BI is human-driven: an analyst models the data, builds a dashboard, and business users read it. Agentic analytics is AI-driven: an agent plans an analysis, queries governed metrics from a semantic layer, builds calculations on top of them, and returns an answer with its reasoning traceable to named definitions. The deeper difference is architectural — traditional BI puts governance inside the BI tool, while agentic analytics puts it in a layer underneath every surface, enforced before the query is generated.
- Is agentic analytics replacing traditional BI?
- It's replacing the workflow, not the need. Governed reporting doesn't go away — someone still has to define what revenue means, and regulated reporting still needs fixed, auditable outputs. What changes is that answering a new question stops requiring a person to build a new view. The realistic end state for most teams is agentic analytics over a governed model, with curated dashboards still in place for the reporting that genuinely should be fixed.
- Can't traditional BI tools just add AI?
- They can add AI features, and nearly all have — Looker has Gemini, Tableau has Einstein, Power BI has Copilot, Metabase has Metabot. The limit is that those assistants sit on architectures designed for a dashboard-first world, so they're typically bounded by what the existing dashboard or model already computes. That's useful, but it's a faster way to drive the old workflow rather than a new one. The distinction worth testing is whether the AI can answer a question nobody built a view for.
- Where does traditional BI still win?
- Three situations. When the reporting set is stable and regulated and the value is in a fixed, auditable artifact rather than open-ended exploration. When the audience wants a curated view they can read at a glance, not a conversation. And when there's no governed semantic model yet — an agent pointed at raw tables re-derives joins and metric logic on every prompt and will confidently return inconsistent numbers, which is worse than a dashboard someone checked.
- Why does agentic analytics need a semantic layer when traditional BI didn't?
- Traditional BI didn't need one because a human was the semantic layer — the analyst knew which table to join and what counted as an active customer, and encoded that in the dashboard. Remove the human from the loop and that knowledge has to live somewhere the agent can read. Without it the model guesses, and the same question phrased differently returns different numbers. A semantic layer defines metrics, dimensions, joins, and access rules once so the agent selects from certified definitions instead of reconstructing them.
- How do you tell a real agentic platform from a chat box on a dashboard?
- Ask it a question nobody built a view for — a metric sliced by a dimension no existing dashboard combines. A chat box bounded by the dashboard's model will fail, deflect, or quietly answer a different question. An agent over a semantic layer composes it, because it knows the entities and join paths. Two follow-ups: can it build and save a new calculation, and can you trace its answer back to named metric definitions?
- Does agentic analytics mean we stop building dashboards?
- No, and platforms that claim otherwise are overselling. Dashboards remain the right format for a number people check on a rhythm. What shrinks is the long tail — the one-off dashboard built to answer one question that gets looked at twice and then rots. In practice teams end up with fewer, better-maintained dashboards plus an agent for everything that used to become a ticket.
- Is agentic analytics more expensive than traditional BI?
- The pricing models differ enough that a per-seat comparison misleads. Traditional BI costs scale with authors and viewers; agentic platforms tend to price on the platform and usage. The cost that usually dominates neither line item is the data team's time — the tickets, the one-off dashboards, the reconciliation when two reports disagree. That's the number worth modeling, and it's the one a governed model is meant to reduce.
- What does migrating from traditional BI to agentic analytics involve?
- The work is moving metric logic, not rebuilding charts. Inventory the calculated fields, filters, and access rules inside your most-used dashboards — that logic is what has to become a governed model. In Cube you define those metrics once in a SQL-first model in YAML or JavaScript, on top of the warehouse you already run and reading the dbt models you may already maintain. Rebuilding the visuals is usually fast; agreeing on the definitions is the part worth budgeting for.