Agentic analytics

What is agentic analytics?

Agentic analytics is analysis where an agent runs the whole investigation instead of answering one question. It decides what to look at first, queries several times, checks its own result against a second angle, and comes back with a finding plus the queries it used.

The difference from asking a question is easier to see than to define. Ask a chat assistant "what was our margin last month" and you get one number from one query. That is conversational analytics, and it has its own entry. Ask an agent "our margin dropped, find out why" and no single query answers it. Somebody has to decide to split margin by product group first, then by customer inside the group that moved, then to test whether the mix alone explains the gap. That deciding is the work, and it is what the agent takes over: the walk an analyst does with a pivot table on the first Tuesday of the month.

Seen from the inside it is five steps.

1. It breaks the question into steps.
   Confirm the drop is real, find where it sits, find what changed inside that, test whether the obvious explanation covers the gap.

2. It queries more than once.
   The first query narrows, the second lands inside that narrowing, the third goes back to a different table. One business question routinely turns into a dozen queries or more, and Snowflake's documentation notes that a Deep Research investigation can take up to ten minutes.

3. It checks its own answer.
   The version worth paying for recomputes the number a second way. Take August margin, apply July's customer mix, and see how much of the gap disappears. If most of it survives, the cause is price.

4. It notices something you did not ask about.
   This falls out of the querying, not the prompt. While grouping order lines by supplier it sees sixty lines with no purchase price. Nobody asked, and it is often the most useful line in the report.

5. It reports, or it acts.
   Most shipped analytics agents stop at reporting. Fabric data agents generate only read queries and never trigger a write workflow. Acting on a finding is a separate design, and that is the operations agent entry.

The value is in steps one and three, the two a busy person skips. The price is that an agent choosing its own next query touches far more of your data than a chat box ever does.

The four things that have to exist first

This is the part that gets sold as a feature and turns out to be the project.

A governed model that says what revenue means. The agent cannot choose between two plausible definitions of margin, because both look correct in the data. Snowflake puts it plainly in the Cortex Analyst documentation: generic AI struggles with text-to-SQL when it is handed only a database schema, because a schema does not carry business process definitions or how a metric is supposed to be handled. A semantic model with a Margin measure your finance team signed off removes the choice. Without one, the agent settles on a definition per investigation and nothing on the screen tells you which.

Permissions that follow the person asking. This gets its own section below, because it is where most first designs go wrong.

A way to check an answer. Not a feeling that it looked about right. Write down twenty questions where you already know the answer, in the words your colleagues actually use, and run them again after every change to the model, the instructions or the model version. An agent that scores worse than a new hire is not ready, whatever the demo looked like.

A record of what it ran. Every query, in order, with the measure and the filters, kept somewhere a person can read it two weeks later. Microsoft documents that prompts and responses from a Fabric data agent can be picked up by Microsoft Purview auditing and eDiscovery, with those Purview controls still in preview at the time of writing. Snowflake points at role-based access control and audit trails to keep an agent's autonomous actions inside the boundaries an admin set. If your tool cannot show you the queries behind a conclusion, the conclusion is an opinion with a chart attached.

Who the agent is when it queries

The easy way to build this is a service account with read access to the warehouse. It works on day one and it is wrong.

An agent running under a service account sees every row. Ask it for margin per customer and it can hand a sales rep the accounts they are not supposed to see. Ask it for payroll cost per department and it will answer that too. This is the same trap the RAG entry describes for document assistants, and the answer is the same: identity-aware access is not a hardening step you add later, it is the design.

The governed products handle it the same way, and it is worth checking that yours does. A Fabric data agent uses the requesting user's credentials, so row-level and column-level security still apply. Snowflake's agent inherits the row-access policies and column-level security attached to the user's role. Ask your vendor one question and insist on a straight answer: when the agent runs a query, whose permissions apply? If the answer is a service account, you are building a data leak with a chat interface on the front.

There is a second half to this. The audit trail has to record who asked, not only what ran. Otherwise you can tell that somebody pulled the salary table and not who pulled it.

A margin drop, worked out step by step

A technical wholesaler in Limburg, forty people, roughly 1.2 million euro of revenue a month. August closes at 28.9 percent gross margin against a twelve-month average of 31.2. The owner types one sentence: our margin fell in August, find out why.

1. Confirm it. Margin per month over twenty-four months. August is the lowest of the last twelve and July was normal, so this is one month and not a trend.

2. Find where it sits. Margin per product group. Fittings, about 360k of August revenue, came in at 26 percent against a usual 34. Eight points on 360k is roughly 29k of missing margin, which is the entire company gap.

3. Look inside the group. Margin per customer within fittings. One customer took 110k in August against a normal 20k, at their contract margin of 11 percent.

4. Check the explanation. The agent recomputes fittings margin with that customer back at their usual 20k and lands at 31 percent. So the customer explains five of the eight points. The other three are still open: the rest of the group came in just under 33 percent instead of 34, which points at price rather than mix.

5. Report the thing nobody asked for. While grouping by supplier the agent finds 62 order lines, about 18k of revenue, with a purchase price of zero, all from the same supplier. Those lines show up at 100 percent margin. The supplier's price file failed to import on 4 August. Put a normal cost back on them and August margin is a full point lower than the report says, and fittings is closer to 22 percent than 26.

Now the part that would have gone unnoticed. In step two the agent picked a measure called Gross margin. Suppose that measure runs on standard cost while your finance team reports on landed cost with freight and customs in it. Every number above stays internally consistent. The group still moved, the customer still explains five points, the missing price file is still real. The level is wrong by a point and a half everywhere, and nothing in the output says so, because the agent never made a choice between two definitions. It used the only one it could find. That is the whole argument for settling the definition in the model before you put an agent on top of it.

What the agent does well, and what it gets wrong

It is good at the work a person skips for lack of time. Nobody runs the counterfactual from step four by hand on a Tuesday afternoon; the agent runs it because it costs nothing. It turns twenty anomalies into the three worth someone's attention, with a reason attached to each. And it drafts the query, which used to mean waiting on the one colleague who knows the warehouse.

What it cannot do is one stubborn thing: it does not know which of two plausible definitions your business uses. A better model will not fix that. It is a decision nobody has written down, and only a person can make it, which is why the semantic layer sets the ceiling on how far this gets in your company.

There is a measurement behind it. The XLANG research lab built a test set called Spider 2.0 out of real enterprise warehouses, 632 problems against databases running past a thousand columns. In the first round the strongest general reasoning model solved about 17 problems in every 100, against roughly 87 percent on the older academic version of the same test. The leaderboard has climbed since, but through purpose-built systems with a lot of engineering around the model, not through better models.

Which is why an answer that is wrong but looks right costs more than no answer: it gets acted on. A demo optimises for the conversation. A rollout has to optimise for what the demo never shows, whether the answer can be checked and whether anyone can find out later what it ran.

Agentic analytics compared to a dashboard with alerts

Both of them notice. The dimension that separates them is what happens in the hours after something looks wrong.

With a dashboard and an alert rule, the automation ends at the notification. The alert says margin is under 30 percent. Somebody opens the report, filters to August, exports to Excel, asks the colleague who knows the ERP, and two days later has a cause. The alert was accurate and it did nothing with those two days.

With agentic analytics, the alert is where the work starts. The agent runs the decomposition a person would have run, and the notification arrives with a shortlist of candidate causes and the queries behind each one. Two days of digging become ten minutes of reading.

What does not change is who is responsible. Someone still decides whether to call the customer, renegotiate the contract or fix the price file. And the dashboard does not go away. Numbers that have to come out identical every time, the board pack and anything an auditor sees, belong on a page a person built and checked.

What has actually shipped, and what is a roadmap slide

September 2026, and worth separating carefully, because this category is being sold on what it promises for next year. Fabric data agents are generally available, read-only and governed, with up to five data sources and queries that run as the person asking. Snowflake shows the whole spread inside one product: it rebranded Snowflake Intelligence to CoWork on 2 June 2026, where the chat and the domain agents are generally available, Deep Research was listed in that same announcement as generally available soon, and multi-agent orchestration, memory and time-based automations as public preview soon.

Read that as it is written. On one day, in one product, the answering is finished, the investigating is nearly there, and the acting on a schedule of its own is a preview. ThoughtSpot and Salesforce sit in the same place. And every vendor, asked why their answers are right, points at their semantic layer.

Where an SME starts

Pick one recurring analysis somebody already does by hand every month: the margin walk, the debtors review, the stock report that eats half a day. Write the definition down first, because if your team argues about it for twenty minutes that argument was coming anyway. Then give the agent last month's data and last month's question, where you already know the answer because somebody produced it by hand.

Compare the finding, not the number. Did it land on the same cause, in the same order, and explain the same share of the gap? Then read the queries, all of them, because that is where you learn whether it got the right answer for the right reason. Repeat for three months before anyone else sees it.

Get the number right and the reason wrong even once and you have found a hole in your model, which is the more useful outcome. You were going to fall into that hole eventually.

What to watch out for with agentic analytics

A confident cause is harder to check than a wrong number. A wrong total gets caught, because somebody at the table knows roughly what revenue was. "The drop is driven by customer mix in fittings" has nothing to check it against but the queries underneath.

The agent stops once it has a plausible story. It found a customer that explains five of eight points and wrote that up as the answer. Ask for the share of the gap explained in every report, and treat anything under eighty percent as unfinished.

The cost is per investigation, not per question. A dozen queries and a long reasoning chain per run, times everybody who can press the button, times every morning. Put a spend cap on it before you roll out, as you would with any agent that spends money on its own.

Missing data fails quietly. An agent working on a warehouse where a load failed reports on what is there and has no idea what is not. Freshness and completeness checks on the source belong in the design.

Language. The governed Microsoft option supports English only at the time of writing, so your colleagues in Genk typing their question in Dutch is not the tested path.