The way people get answers out of company data is changing faster than the data stacks underneath them. For twenty years the answer to "why did that number move?" was a dashboard someone built in advance. In 2026, increasingly, the answer is an agent that goes and finds out.
Among the AI trends 2026 has surfaced, that is the one worth paying attention to. Not "companies are using more AI" (they are) but something more specific: self-service business intelligence is becoming agentic, and the constraint on whether it works has moved from the model to the data foundation underneath it.
The adoption numbers are already there. According to Google Cloud's ROI of AI Report, 52% of executives report their organizations are deploying AI agents in production, and 88% of agentic AI early adopters are already seeing positive ROI. What those numbers hide is how much of the work is data architecture rather than prompting. To build a trustworthy modern data strategy for the age of AI, you have to change how machines get meaning out of your warehouse, not just how they get access to it.
The four generations of self-service analytics
It helps to see where agentic analytics sits in a longer arc. Self-service BI has been reinvented roughly every decade, and each generation moved the work around rather than eliminating it.
| Generation | Interface | Who does the thinking |
|---|---|---|
| 1. Dashboards | Pre-built reports | Humans anticipate the question and build the answer in advance |
| 2. Self-service BI | Filters, dimensions, drag-and-drop | Business users slice pre-modelled data themselves |
| 3. Natural-language analytics | A chat box over the warehouse | An LLM turns a sentence into SQL; the user hopes it is right |
| 4. Agentic analytics | An agent with tools and governed context | The agent investigates, validates, and follows up on its own |
The fourth generation is not a nicer chat box. The difference is that an agent doesn't just answer the question you asked, it runs the next three queries a good analyst would have run, checks its own result, and tells you what it found.
The infrastructure for that is already being built at scale. According to customer usage data compiled by Databricks, multi-agent workflows have grown by 327% year over year, and supervisor agents coordinating networks of specialized subagents now account for 37% of all agent usage.
The next generation of self-service BI isn't another dashboard
The promise of self-service BI was always straightforward: let business users answer their own questions without waiting on the data team.
The interface kept getting easier. The underlying limitation never moved. Someone still had to anticipate the question, model the data, build the dashboard, define the metrics, and teach the user where to look. "Self-service" in practice meant "self-service, within the boundaries of what a data engineer already imagined you'd ask."
Agents change that equation. Instead of navigating dashboards, a sales leader can ask:
Why did expansion ARR drop in DACH this quarter? Which accounts caused it? What changed in their product usage in the months before the contraction?
No dashboard answers that question, because it isn't one question, it's an investigation. An agent can run that investigation dynamically: pull the metric, decompose it by account, join in product usage, look at the period before the drop, and come back with a narrative.
But only if it understands what "expansion ARR," "DACH," "account," and "product usage" mean inside your business. That is the whole problem.
Why raw text-to-SQL breaks agentic analytics
When teams build their first internal analytics agent, the instinct is to connect it straight to the warehouse: hand the model database credentials, write a prompt, and let it generate SQL.
This is where most projects stall. Direct text-to-SQL has three systemic weaknesses:
-
Schema complexity. A typical enterprise warehouse has hundreds of tables, column names like
usr_act_v2, and three fields that all look like they might be revenue. A model guessing at what those mean will guess wrong often enough to matter. - No metric governance. If three agents query raw tables for "Monthly Recurring Revenue," you get three SQL statements and three different numbers, with no way to tell which one leadership should act on.
- No safety boundary. Raw SQL access exposes every table the credential can reach, including the ones nobody intended an agent to see.
Databricks' customer data points the same direction: a lack of structural control is the single biggest bottleneck to shipping AI. Teams that implement governance and security tooling ship 12x more production deployments, and standardized evaluation tooling yields 6x more.
The failure mode isn't that the agent can't write SQL. Modern models write excellent SQL. The failure mode is that it doesn't know what your business means.
Anthropic reached the same conclusion in production
The strongest evidence for this isn't a vendor benchmark, it's Anthropic publishing its own internal architecture.
In How Anthropic enables self-service data analytics with Claude (June 3, 2026), Anthropic's data team reports that 95% of business analytics queries are now automated through Claude, at roughly 95% aggregate accuracy, and close to 99% in some domains. The headline result is impressive. The explanation is the useful part.
Anthropic is explicit that this is not a model story. Analytics accuracy, in their framing, is a context and verification problem, not a code-generation problem. The same Claude that reaches 95% with the right scaffolding never got above 21% on their internal evals without it.
Their agents don't start by improvising SQL. The stack they describe has four layers:
- Data foundations: the warehouse itself: models, transformations, tests, and the metadata that describes them.
- Sources of truth: a human-curated semantic layer of metric and dimension definitions, plus lineage graphs and business-context knowledge. Notably, they found that auto-generating metric definitions from raw tables and query logs didn't work: it reproduced the ambiguity instead of removing it.
- Skills: procedural knowledge in markdown telling the agent which sources to consult, in what order, and what a finished answer looks like. That skill set is synced to multiple surfaces and served as resources over MCP.
- Validation: offline evals, ablation testing, and online monitoring with adversarial review.
Two details matter most for anyone building this. First, the semantic layer is the required first path: when a question maps to a defined metric, the agent calls that definition and gets the same number every other surface in the company produces. Raw table access is the fallback, not the default. Second, the same governed context is exposed across agent surfaces, so the answer doesn't change depending on whether someone asks in Slack, in an IDE, or in a chat window.
And they are honest about the limits. This architecture reduces failures; it doesn't eliminate them. Anthropic keeps adversarial review running precisely because silent failures still happen, and reports that without active maintenance accuracy drifts from 95% back toward 65%.
Better models help. Better context architecture is what makes self-service analytics trustworthy.
A governed semantic layer gives agents shared meaning
A semantic layer is the translation between how data is stored and how the business talks. It maps raw tables to defined business concepts: instead of querying billing_ledgers_final, the agent queries an entity called Revenue and asks for MRR broken down by acquisition_channel.
Combining that with agent access gives agents something raw warehouse credentials cannot: a shared definition of customers, revenue, churn, pipeline, and every other concept they need in order to reason correctly.
The measurable effect is large. A general-purpose model writing SQL against an unmapped schema fails roughly half the time, Snowflake's internal benchmarks put GPT-4o at about 51% text-to-SQL accuracy on raw schemas. Grounding the same model in a governed semantic model lifts accuracy past 90%.
That is the same conclusion Anthropic reached, arrived at from a different direction: the governed definition is what turns a plausible answer into a correct one.
MCP is becoming the interface between agents and business data
Dashboards were the interface between people and business data. MCP is becoming the interface between agents and business data.
The Model Context Protocol (MCP), released as an open standard by Anthropic, is the emerging connection layer of the AI ecosystem, the USB-C port for agent tooling. Rather than writing bespoke integration code for every model and every tool, you run a reusable MCP server. The agent connects, discovers what's available (metrics, schemas, reports) and calls it. The same server works for Claude, for IDEs like Cursor, and for custom orchestrators.
Standardizing that interface pays off quickly. In its 2026 Business Trends Report, Google Cloud describes how pulp manufacturer Suzano cut query times by 95% for 50,000 employees by deploying standardized semantic data interfaces.
But MCP on its own doesn't make data trustworthy. It solves connectivity, not meaning. An MCP server pointed at raw tables is a faster route to the same wrong answers. The quality of what comes back still depends entirely on the governed context sitting behind it, which is exactly where the interesting engineering is.
People and agents working from the same definitions
None of this makes dashboards, analysts, or data teams disappear. It changes the collaboration model.
People define and govern what the business means, what counts as an account, how expansion ARR is calculated, which source system wins when two disagree. Agents perform the continuous investigation humans don't have time for. Both work from the same underlying definitions, and the semantic layer becomes the contract between them.
This matters more than it sounds, because of something Anthropic observes directly: once agents become the consumers of the data model, the person asking the question often can't validate the answer themselves. The reader of a dashboard could sanity-check a number against the chart next to it. The reader of an agent's paragraph cannot. Governance stops being a compliance concern and becomes the thing that makes the output usable at all.
From a modern data stack to an agent-ready data foundation
The usual framing of this problem is vendor sprawl, ingestion here, warehouse there, transformation, semantics, and a custom API on top. That framing misses the point.
The problem isn't that there are too many vendors. It's that traditional data stacks were designed for humans consuming dashboards, not for agents consuming context. A human reading a report brings their own business knowledge to it. An agent has to be given that knowledge explicitly, in a form it can navigate, which is a requirement almost no stack was built to satisfy.
An agent-ready data foundation comes together in four moves:
- Connect your data. Managed ingestion from many sources into a warehouse you control.
- Govern what it means. Define metrics, entities, and relationships once, version-controlled like code.
- Serve it to agents. Expose the governed model through a secure MCP server, so Claude, your IDE, and your own agents all read the same definitions.
- Learn continuously. Definitions, lineage, and skills evolve with the business instead of drifting away from it.
The practical difference at query time: agents don't guess against raw schemas. They work from the same governed definitions your business already trusts, rather than inventing their own interpretation of the underlying tables, which removes one of the largest sources of analytics hallucination.
This article was originally published on the RevOS blog.
Top comments (0)