What is agentic analytics?

Agentic analytics is a way of working with data where an AI agent answers a business question by writing and running its own queries, then returns the answer in plain language. You ask “what was revenue in the EU last quarter” and the agent works out which tables to use, writes the SQL, runs it against your warehouse, checks the result, and replies. No dashboard, no ticket to the data team, no SQL from you.

The word “agentic” is the important part. A normal chatbot answers from what it already knows. An agent takes actions. An analytics agent plans a set of steps, uses tools like a warehouse connection and your documentation, looks at what comes back, and corrects itself when the first attempt is wrong. That loop is what separates agentic analytics from a text box that returns a single guess.

How agentic analytics works

Most analytics agents run some version of the same loop.

1. Understand the question. The agent reads your question and works out what you actually want. “Top customers” could mean by revenue, by order count, or by lifetime value. Good agents ask when it is ambiguous instead of guessing.
2. Find the right data. The agent looks at the schema, the table and column descriptions, and any business definitions it has been given, then decides which tables and joins to use.
3. Write the query. It generates SQL, or a query against a semantic layer, for your specific warehouse dialect.
4. Run and check. It executes the query, looks at the result, and sanity-checks it. If the query errors or the numbers look off, it revises and tries again. This retry step is often called the agentic loop.
5. Answer. It returns the number, usually with a short explanation and often a chart, so you can see how it got there.

The parts that matter for trust are steps 2 and 4. Anyone can get a language model to produce SQL. The hard part is getting it to produce the right SQL against a real, messy warehouse, and to catch itself when it is wrong.

Why it is happening now

Two things changed.

First, language models got good enough at code and reasoning to write SQL that runs. Text-to-SQL has been a research topic for years, but recent models cleared the bar where the output is usable often enough to build on. Benchmarks like BIRD and Spider 2.0 track exactly this, and they also show how large the gap to human accuracy still is on real databases.

Second, data teams stayed a bottleneck. Business users still cannot get answers without waiting on someone who knows SQL. Self-serve BI promised to fix that and mostly did not, because dashboards only answer the questions someone thought of in advance. An agent can answer the question you have right now. The comparison with traditional BI goes deeper on this.

Why it is hard

The demo always works. Production is where agentic analytics gets difficult, and the reasons are worth knowing before you trust one.

Real warehouses are messy. Column names are cryptic, the same concept lives in three tables, and “revenue” is defined one way by finance and another by the growth team. A model that has only seen the raw schema will guess, and a confident wrong number is worse than no number.

The failure is silent. When code is wrong, it usually breaks. When a query is wrong, it still returns a number. It just returns the wrong one, formatted exactly like the right one. Benn Stancil made this point well in Can analysis ever be automated? You cannot verify an analytical answer the way you verify code, so trust has to come from somewhere else.

This is why raw text-to-SQL alone tends to fail on enterprise data. dbt Labs benchmarked it directly and found that querying through a governed semantic layer reached near-perfect accuracy while raw text-to-SQL lagged well behind, mostly because the semantic layer removes the ambiguity the model would otherwise guess at.

What makes an analytics agent reliable

The reliable ones are not the ones with the biggest model. They are the ones with the best context.

• A semantic layer or shared metric definitions, so “revenue” means one thing and the agent does not reinvent it on every query.
• Documentation and business rules the agent can read, like what each table is, which one is canonical, and which filters to always apply.
• An evaluation suite of real questions with known answers, so you can measure accuracy before you deploy and catch regressions after.
• A correction loop, so a failed or suspicious query gets retried rather than returned.

The industry has a name for the practice of assembling all of this. It is called context engineering. Anthropic wrote a good primer on it, and it is the single biggest factor in whether an analytics agent can be trusted. The model is mostly a commodity. The context is the product. Open-source agents such as nao treat that context as the core artifact, something the data team builds, versions, and tests rather than a one-off prompt.

Who uses agentic analytics

Two groups, with different jobs.

The data team builds and governs the agent. They connect the warehouse, define the metrics and rules, write the evals, and decide what the agent is allowed to touch. They stop answering the same ad hoc questions over and over. They curate the context that lets everyone else self-serve.

Everyone else asks questions. Analysts, PMs, ops leads, and founders get answers in plain English without writing SQL or filing a ticket. The good deployments feel less like a new BI tool and more like a fast, always-available analyst that happens to show its work.

Where to go next

If you want the hands-on version, the learn path walks through building and deploying an agent step by step, from connecting a warehouse to keeping it reliable. If you are weighing up tools, the compare page puts the current agents side by side on the things that actually matter, like open source, governance, evaluation, and how they handle context.

Is agentic analytics the same as text-to-SQL?

No. Text-to-SQL is one step inside an analytics agent, the step that turns a question into a query. Agentic analytics is the whole loop around it, including finding the right data, running the query, checking the result, correcting mistakes, and answering in plain language. Text-to-SQL on its own, with no context and no correction, is the part that tends to fail on real data.

Is agentic analytics just a chatbot for data?

Not quite. A chatbot answers from what the model already knows. An analytics agent takes actions. It queries your live warehouse, reads your business definitions, and checks its own work. The answer comes from your data, not from the model’s memory.

Do you still need a data team for agentic analytics?

Yes, and arguably more than before. The data team stops answering repetitive questions and starts building the context the agent relies on, meaning the metrics, the rules, the documentation, and the tests. The agent is only as good as that context, and that context is the data team’s work.

Can you trust the numbers an analytics agent gives you?

Only if it was built for it. Trust comes from a governed semantic layer, clear business rules, an evaluation suite that measures accuracy on known questions, and a correction loop that catches bad queries. An agent without those can still produce answers, but you have no way to know whether they are right.