Agentic Analytics: What Changes For Data Teams?

Thesis

The three eras of analytics responsibility

To understand what Agentic Analytics means, and why it matters, we should first look at how the responsibility of data teams has evolved.

In the early days of business intelligence, the responsibility of the data team was simple: do the work.

A business stakeholder needed a report, so the analyst wrote SQL. A manager wanted to understand why revenue dropped, so the analyst investigated. A department needed a dashboard, so the data team built it. The analyst acted as the translator between business questions and database systems.

This model works when the company is small and the number of questions is limited. But as the organization grows, the data team becomes a bottleneck. Every question becomes a ticket. Every dashboard becomes a dependency. Every follow-up question waits behind other requests.

The industry's answer to this problem was the second era: self-service BI.

Instead of answering every question manually, the data team would model the business. They would define reusable datasets, metrics, dimensions, dashboards, and governed exploration paths. Business users could then answer many questions by themselves through drag-and-drop interfaces, filters, dashboards, and exploration tools.

This was an important shift. The data team moved from doing all the analytical work to setting up the modeling layer so others could self-serve.

But now we are entering a third stage.

In the agentic era, the data team's responsibility shifts again. It is no longer enough to model data so humans can self-serve. The data team must now set up the system so agents can help humans self-serve.

This is a subtle but important distinction.

A human self-service user needs a clean interface, trusted metrics, and understandable dashboards. An agentic self-service system needs all of that, plus much more. It needs machine-readable semantics, contextual knowledge, version-controlled definitions, evaluation mechanisms, permissions, feedback loops, and a way to improve over time.

The data team's job is no longer merely to produce answers. It is to build an environment where analytical work can be delegated safely.

What Agentic Analytics actually means

Why "chat with your data" is not enough

Many AI analytics demos today begin with a user asking a question like:

What was our revenue last month?

The system translates the question into SQL, runs the query, and returns a number.

This is impressive the first time you see it. But it does not take long before the harder questions appear.

What does "revenue" mean? Is it gross revenue, net revenue, recognized revenue, invoiced revenue, or collected cash? Should refunds be excluded? Should internal test accounts be removed? Should the number follow finance's definition or the sales team's definition? If the user asks for "customers", does that mean accounts, workspaces, billing entities, active users, or companies?

In real organizations, analytical questions are rarely just database queries. They are embedded in business context.

A senior analyst knows this instinctively. When someone asks, "Why did revenue drop last month?", the analyst does not immediately write SQL. The analyst first tries to understand the question.

Which revenue metric are we talking about? Compared to what period? Is this for the whole company or a segment? Are we looking for accounting explanation, sales pipeline explanation, product usage explanation, or customer behavior explanation? Is the drop even real, or is it caused by a data issue?

This is why text-to-SQL alone is insufficient. It treats analytics as a query generation problem. But analytics is not just query generation. Analytics is a reasoning workflow.

The query is only one step in the process.

An agentic analytics system must be able to participate in the whole workflow: understanding intent, finding the right context, choosing the right metric, planning the analysis, querying through governed definitions, explaining the result, and knowing when the answer is not reliable enough.

A chat box without this deeper system is just a nicer interface on top of the same old ambiguity.

The limits of traditional self-service BI

Traditional self-service BI was created to solve a real problem. It gave non-technical users a way to explore data without learning SQL.

The typical approach is familiar. The data team prepares datasets, defines relationships, creates metrics, and exposes business-friendly concepts through a BI interface. Users can then drag and drop fields, filter by dimensions, drill into dashboards, and answer common questions on their own.

This works well for many use cases. A sales leader can filter pipeline by region. A product manager can break down activation by signup cohort. A finance user can track revenue by month. A marketing team can inspect campaign performance without asking the data team for every number.

But self-service BI still assumes that the user knows how to drive the analytical process.

The user must know which dashboard to open. They must know which metric to use. They must know which dimensions are meaningful. They must know how to interpret a change. They must know what follow-up question to ask. They must know when a number looks suspicious.

In practice, many business users do not want a blank canvas. They want help thinking through the problem.

This is where AI agents become useful.

An agent can help the user clarify intent. It can suggest relevant metrics. It can explain the difference between similar definitions. It can propose analytical paths. It can inspect prior analyses. It can create a new model or dashboard when the existing ones are insufficient. It can turn an ambiguous business question into a sequence of concrete analytical steps.

But for the agent to do this reliably, the old self-service layer is not enough.

The semantic layer must become deeper. The documentation must become more connected. The source of truth must become inspectable by both humans and machines. The analytical workflow must become evaluable. The system must learn from repeated usage.

The Agentic Analytics approach

The advantages of both approaches naturally point us to a new direction.

What if we can combine the governance of semantic modeling, the flexibility of analytics-as-code, the usability of self-service BI, and the reasoning ability of AI agents?

The answer is Agentic Analytics.

In this model, the analytical system is no longer just a collection of dashboards, datasets, and query tools. It becomes an environment where humans and agents collaborate through a shared source of truth.

The business user brings intent. The data team maintains the semantic and contextual substance. The agent helps bridge the gap between the two.

The architecture of Agentic Analytics

Agentic Analytics requires a few important layers.

The Consumption layer

The first layer is the consumption layer. This is where users interact with the analytical system.

In the pre-agentic world, BI consumption mostly happened through dashboards and exploration interfaces. Dashboards were good for recurring questions. Exploration interfaces were good for flexible slicing and dicing. SQL editors were good for analysts who needed full control.

In the agentic world, chat becomes another important consumption mode. But it should not be the only one. Different analytical situations require different interfaces.

Chat is useful when the user's intent is ambiguous, exploratory, or conversational. A user can ask, "Why did expansion revenue slow down in Q2?" and the agent can clarify the scope, suggest possible causes, and guide the investigation.

Dashboards are useful when the organization needs shared operating views. A leadership team should not need to ask an agent every morning what revenue, churn, activation, and pipeline look like. Some views should remain persistent, curated, and visible.

Exploration interfaces are useful when users want direct manipulation. Sometimes the fastest way to understand a metric is still to drag dimensions, apply filters, compare segments, and inspect the resulting chart.

Agentic Analytics does not replace dashboards. It connects chat, dashboards, and exploration into the same analytical loop.

A user might begin with a dashboard, ask an agent to explain a change, drill into an exploration view, ask for a new breakdown, and then save the result as a reusable artifact. The agent helps the user move between these modes.

The Source of Truth layer

The second layer is the source of truth layer.

This is the layer that defines what the organization knows about its data. It should not live only in the heads of senior analysts. It should not be scattered across dashboards, Slack threads, spreadsheet formulas, and tribal knowledge.

In an agentic analytics system, the source of truth needs to be explicit, version-controlled, and readable by both humans and agents.

A practical implementation is a Git mono repo containing several types of artifacts.

First, there is the semantic layer source code: models, metrics, dimensions, relationships, datasets, and other analytical definitions.

Second, there is the transformation layer source code, such as dbt models and tests.

Third, there is a markdown-based wiki containing business definitions, metric explanations, domain knowledge, analytical playbooks, known caveats, and historical decisions.

This matters because agents need something concrete to reason over.

If the definition of "active customer" lives only inside a dashboard title or an analyst's memory, an agent cannot reliably use it. If the transformation logic lives in one system, metric logic in another, and business context in a third, the agent will have a fragmented understanding of the organization.

A Git-backed source of truth changes the situation. Definitions can be reviewed, diffed, tested, and rolled back. Agents can inspect them. Humans can review agent-generated changes. Evaluation systems can run against them. The organization's analytical knowledge becomes durable.

This is one of the reasons analytics-as-code becomes more important in the agentic era, not less.

Agents work best when the world is represented through explicit artifacts. Code, markdown, metadata, tests, and examples give agents stable handles. A GUI-only semantic layer may be convenient for humans, but it is much harder for agents to inspect, modify, review, and evaluate.

The Context Management layer

The next layer is context.

A schema tells us what tables and columns exist. A semantic layer tells us how business concepts map to data. But neither is enough by itself. Real analytical work depends on context.

Why was this metric created? Who owns it? Which dashboard is considered official? What data quality issues are known? Which customer segments matter to the business? What did the finance team decide last quarter? Why do two teams define activation differently? Which Slack discussion explains the change in pipeline stages? Which incident caused last month's data anomaly?

A good analyst carries this context in their head. A good agentic analytics system must externalize it.

However, context ingestion is not just dumping documents into a vector database. If the system retrieves irrelevant or stale context, the agent becomes more confused, not less. If it retrieves too much, the agent may overfit to noise. If it retrieves too little, the agent may miss important assumptions.

Context needs management.

Some context should be attached to metrics. Some should be attached to models. Some should be attached to teams. Some should be attached to time periods. Some should be attached to incidents, decisions, or analytical workflows.

When a user asks about revenue, the agent should know which revenue metric is official. When a user asks about activation, the agent should know which product team owns the definition. When a user asks about an anomaly, the agent should know whether there was a data incident, pricing change, product launch, or accounting adjustment during that period.

This is where the boundaries between BI, documentation, knowledge management, and AI begin to blur.

The Evals system

This may be the most important layer of all.

If we let agents participate in analytical work, we need a way to evaluate whether they are doing the work correctly. Otherwise, we are just replacing slow human bottlenecks with fast unreliable answers.

Every stage of the agentic workflow should have evaluation criteria.

When the agent interviews the user, did it understand the business question correctly? Did it ask clarification questions when the request was ambiguous?

When the agent creates an analytical plan, did it choose the right metrics, dimensions, and segments? Did it avoid unnecessary complexity? Did it identify the assumptions?

When the agent collects context, did it retrieve the relevant documents and definitions? Did it ignore stale or unrelated information?

When the agent writes or modifies data models, are the changes correct, reusable, and consistent with existing conventions?

When the agent creates semantic-layer artifacts, are the definitions accurate? Are they composable? Are they documented? Are they governed?

When the agent queries the data, does it go through the semantic layer instead of bypassing governance with raw SQL?

When the agent presents the result, does it explain the reasoning clearly? Does it cite the assumptions? Does it avoid overclaiming? Does it distinguish correlation from causation?

This mirrors the role of tests in software development. Software teams do not rely only on developers being careful. They use unit tests, integration tests, type systems, code review, CI pipelines, and production monitoring. These mechanisms allow teams to move faster while maintaining reliability.

Analytics needs the same treatment for agentic workflows.

The Learning system

A well-designed Agentic Analytics system should improve over time.

When users repeatedly ask the same question, perhaps a dashboard should be created. When the agent repeatedly struggles with a metric, perhaps the metric definition is unclear. When business users correct the same explanation, perhaps the wiki is missing important context. When analysts frequently override generated plans, perhaps new eval cases should be added. When two teams use conflicting definitions, perhaps the semantic layer needs refactoring.

In this sense, the agent is not only a consumer of the analytical system. It is also a sensor.

It reveals where the organization's knowledge is incomplete. It exposes ambiguity in metric definitions. It surfaces missing documentation. It identifies gaps in the semantic layer. It shows which analytical workflows deserve to become reusable.

A good Agentic Analytics system does not merely answer questions. It improves the organization's analytical substrate over time.

The agentic analytics workflow

Once these layers exist, we can imagine a new analytical workflow.

The workflow begins with interview and requirements gathering. A user may ask a vague question, such as:

Why did our enterprise conversion rate drop last quarter?

In the old model, this would become a ticket for the data team. In a basic AI model, the system might immediately generate a query. In an agentic model, the agent first interviews the user.

What does "enterprise" mean here? Which conversion rate? From signup to qualified opportunity, opportunity to closed won, or trial to paid? Are we comparing quarter over quarter or against target? Are we looking for product, marketing, sales, or pricing explanations?

After the intent is clarified, the agent creates a plan.

It identifies the relevant metrics, dimensions, time periods, and possible hypotheses. It proposes which breakdowns to inspect. It identifies what context may be needed. It may also generate evaluation criteria for the analysis: what would count as a sufficient answer, what definitions must be used, and what assumptions must be checked.

Next, the agent collects contextual data and information.

It inspects the semantic layer, dbt models, wiki pages, past analyses, known data issues, and relevant dashboards. It may discover that the enterprise definition changed recently, or that a pipeline stage was renamed, or that the sales team changed qualification criteria.

Then comes data modeling.

If the existing models are sufficient, the agent can proceed. If not, it may propose model changes. For example, it may discover that the required segment is not modeled cleanly, or that a dimension is missing, or that a transformation needs to be added.

In a governed system, the agent does not silently mutate production logic. It creates a proposed change. The data team can review it through the same process they use for code: pull requests, tests, comments, and approvals.

After the modeling layer is ready, the agent creates or updates semantic-layer artifacts.

This may include a metric definition, a reusable dataset, a dashboard component, or an analytical view. These artifacts should not be one-off query fragments. They should become part of the governed analytical system.

Then the agent queries through the semantic layer.

This is important. The agent should not bypass the official definitions by writing arbitrary raw SQL whenever it is convenient. If the organization has invested in a semantic layer, the agent should use it as the primary interface to data – ideally through a purpose-built query language that keeps the agent inside governed abstractions. Otherwise, the AI system will recreate the same problem that self-service BI tried to solve: many inconsistent answers generated from many inconsistent interpretations of raw data.

Finally, the agent presents the analytical output.

This output may be a chart, a dashboard, a written explanation, a memo, or a recommendation. In some cases, the human user consumes the answer directly. In other cases, a human analyst reviews the output before sharing it more broadly.

The important pattern is not that agents do every step autonomously. The important pattern is that every step becomes explicit, inspectable, and evaluable.

What changes for the data team

Agentic Analytics changes the role of the data team.

The data team still needs to understand data modeling, business logic, SQL, metrics, and visualization. These skills do not disappear. In fact, they become more important because the agentic system is only as good as the substance it operates on.

But the center of gravity shifts.

Data teams will spend less time answering repetitive questions manually. They will spend more time designing semantic systems, managing context, writing evals, reviewing agent-generated artifacts, and improving the analytical development lifecycle.

The data team becomes responsible for the quality of analytical delegation.

This includes defining the official business concepts that agents should use. It includes maintaining the source of truth. It includes deciding which actions agents can perform automatically and which require human review. It includes designing eval cases for common analytical workflows. It includes building feedback loops so the system gets better with usage.

This is a higher-leverage role than ticket-taking.

The best data teams will not be the ones that answer every question themselves. They will be the ones that create an environment where many questions can be answered safely without them, while still preserving governance, context, and trust.

Why analytics-as-code matters more in the agentic era

When we start thinking about agents as participants in the analytics workflow, the similarities between analytics and software engineering become even more apparent.

Software teams already know that complex systems require explicit artifacts and repeatable processes. Code is stored in version control. Changes go through review. Tests run automatically. Deployments are tracked. Incidents are investigated. Documentation is maintained. Tooling is built around the development lifecycle.

Analytics has been moving in this direction for years through Analytics Engineering and analytics-as-code. Agentic Analytics makes this movement more urgent.

Agents need files they can read. They need definitions they can inspect. They need tests they can run. They need examples they can learn from. They need diffs humans can review. They need stable interfaces to modify the system without causing chaos.

This is much harder when the analytical system is locked inside GUI configuration spread across multiple tools.

A code-defined analytics layer gives agents a better operating environment. A markdown wiki gives agents readable business context. A Git repo gives humans a review mechanism. A semantic layer gives agents a governed way to query data. An eval system gives the organization a way to measure whether the agent is doing useful work.

This is why the agentic era does not make data modeling obsolete. It makes data modeling more central.

A new analytics paradigm

Self-service BI, semantic modeling, analytics-as-code, context management, evals, and AI agents are not new ideas in isolation. But when combined, they point to a new way of thinking about business intelligence.

We call this the Agentic Analytics paradigm.

In the old BI paradigm, the main question was:

How do we help analysts produce reports?

In the self-service BI paradigm, the question became:

How do we help business users explore governed data on their own?

In the Agentic Analytics paradigm, the question becomes:

How do we build a governed analytical system where humans and agents can work together to produce trustworthy answers?

This is not just a product feature. It is an operating model.

It changes how we think about the data team's responsibility. It changes how we design the semantic layer. It changes how we manage context. It changes how we evaluate analytical work. It changes how BI interfaces are designed.

The winners in this new era will not be the tools with the flashiest chat demos. A chat box is easy to copy. The real differentiator is the system underneath: the source of truth, the semantic model, the context layer, the evals, the learning loop, and the workflow that connects them.

Analytics Engineering made analytics more software-like. It brought version control, testing, automation, and engineering discipline into the analytics process.

Agentic Analytics extends this idea from data pipelines to analytical reasoning itself.

The goal is not to remove humans from analytics. The goal is to let humans delegate more of the mechanical, repetitive, and intermediate work while retaining control over definitions, judgment, and trust.

In the self-service era, data teams modeled data so humans could explore.

In the agentic era, data teams will model data, context, and evaluation systems so humans and agents can reason together.

That is the next frontier of data analytics.