Can AI agents replace data analysts?

It is a fair question to ask, and we get asked it a lot. The honest answer is more interesting than yes or no.

In our last insight we described the fast routes we build on Microsoft Fabric for everyday questions. Above them sits something different: an analyst agent. It is an AI analyst, built to do the work of a data analyst, so it is the right place to think the question through honestly.

What the analyst agent does

Give the analyst agent a question like “Why did sales fall in the north in Q3, and what should we prioritise in Q4?” and it does two jobs, the same two a good analyst does.

Job one: orchestrating the analysis. It breaks the question down into what it needs to know, then sends each part to the agent best placed to answer it: fast agents for well-defined figures, curated 360s for the full picture on a customer or product, search for what sits in notes and documents, and a Fabric data agent for anything new. Every answer that comes back is judged. Is it complete? Does it agree with the rest? Is there enough to draw a conclusion? If not, it asks again, asks somewhere else, or follows the new lead.

Job two: synthesising the results. Once it has what it needs, it brings everything together into one comprehensive analysis: what happened, why, what it means and what to do next. This is the part a simple search or a single query can never do, and it is where most of an analyst’s value has always been.

It takes a few minutes. The same analysis would, we estimate, take an experienced analyst hours of gathering, checking and writing.

On the legwork, then, the agent is already there. The open question is everything around it.

The brief decides the analysis

Here is what we have learned from building and testing these agents: the quality of the analysis tracks the quality of the brief, almost exactly.

Ask a vague question and you get a vague, generic analysis. It will be well written and it will look convincing, which is the risk. Ask a precise question, with the context behind it, and you get something genuinely useful.

Compare two briefs for the same problem:

“Sales are down in our northern stores this quarter. Can you look into why, and tell me what we should do about it?”

“Sales in our northern stores fell in Q3 against last year, despite running our new product marketing campaign across social and email from mid-July. Our strategy this year is to grow market share in the north, even at some cost to margin, and our focus is on the core range and new products rather than clearance lines. We changed pricing on the core range in July, ran a two-week summer promotion in August, and refitted two of the larger northern stores in September, so they traded at reduced capacity for part of the month. Q4 is our biggest quarter. I need to know what explains the drop, whether anything else is going on, and what we should prioritise in Q4 to achieve our target of £2m for the quarter. Please give me the main causes in order of impact, with the figures behind them, and three recommendations I can take to the leadership team.”

The second brief tells the agent what the business is trying to do, what has changed, what decision the analysis is for and the target it needs to hit. It gets a far better answer, and it gets it faster, because the agent spends its effort on the right things.

The agent cannot write that brief. Someone who knows the business has to: what changed, what matters, what is already known and what decision is waiting on the answer.

Giving it the business and operational context

Look again at the second brief. It is long, and most of it isn’t the question at all. It doesn’t include the figures or the causes; finding those is the analysis. Almost everything else is context, and it comes in two kinds.

Business context is typically static. It changes slowly: the strategy, how outcomes are designed to be achieved, the focus areas, the targets that matter (like that £2m for Q4) and the trade-offs the business is willing to make. It goes well beyond semantic definitions. Knowing what “gross margin” means is the starting point; knowing that the business is deliberately trading margin for market share in the north is what makes the analysis useful.

Operational context is dynamic. It is what the business has actually done, as it happens: the pricing change on the core range in July, the new product marketing campaign, the summer promotion, the store refits. It moves every week.

Both live in the analyst agent’s knowledge base, stored once and available on every question. The business context is reviewed as the strategy moves on. The operational context is recorded as things happen.

That second part is the one people tend to skip. The assumption is that the agent will work the operational context out for itself, and sometimes it can: a step change in prices shows up in the data if you look for it. But it shouldn’t have to. Working it out on the fly is slower, it is less reliable, and an agent that has to guess why the numbers moved can easily guess wrong. Telling it what changed, and when, is far quicker and far safer.

With both in place, the brief is now simply a question:

“Why did sales fall in the north in Q3, and what should we prioritise in Q4?”

The agent already knows the £2m target for Q4 and the strategy behind it. It knows you changed the pricing on your core range in July, that the new product marketing campaign and the summer promotion ran, and that two stores were being refitted. So it can judge whether the campaign underdelivered or the price change cancelled it out. It finds the size of the drop for itself, along with anything else going on, such as a lost key account, because that is what the analysis is for. And it judges everything it finds against what the business is actually trying to do, so its recommendations fit the strategy rather than fighting it.

For everyday analysis like this, the effort shifts from explaining the business every time to keeping the knowledge base current, and that needs an owner. The question still has to be the right one, but anyone who knows the business can ask it.

Not every question is this familiar, though. Exploring a new idea, testing a hypothesis or looking at something the business has never looked at before is a different kind of analysis. The knowledge base can’t set its direction, because nobody has set it yet. That still needs a proper brief.

The human in the loop

So people stay essential, underneath the work as well as at both ends of it.

Underneath: owning the knowledge base. Someone has to review the business context as the strategy moves on and record the operational context as things happen. It is the least visible job in the loop, and the one that most quietly decides how good every analysis is.

Before: asking the right question for everyday analysis, and setting a clear direction for anything new.

After: reading the result critically. Does it make sense against what you know? Has it missed something? Is it confident about something it should not be? The agent checks its own work, but it can only check against the data it has. The person who asked knows things that are not in the data.

For everyday analysis, none of this strictly needs a data analyst. It needs people who understand the business: someone to own the knowledge base, and users who know how to ask good questions and challenge what comes back. That could be an analyst. It could just as well be the operations manager, the finance lead or the sales director, becoming their own analyst, as long as they have learned how.

Briefing is a skill, and it can be taught

Everyday questions can be simple. New analysis can’t. When you are exploring a new topic, testing an idea or looking at something the business hasn’t examined before, the agent needs direction, and that takes a proper brief.

This is a common theme with AI, not just analysis: the tools are only as good as the people using them, and most people have never been taught to use them well. The good news is that briefing an agent is a learnable skill, and it is not a technical one. The habits that make a good brief are the same ones that make a good brief to a person:

• Be specific about the question. Which figures, which period, which part of the business.
• Set the direction. What you are exploring and why, what you suspect, and what is in and out of scope.
• Say what it is for. The decision the analysis needs to support.
• Say what good looks like. A recommendation, a comparison, a list of causes in order of impact.
• Push back on the answer, every time. Ask follow-up questions, challenge the conclusions and ask what would change them. If something doesn’t feel right, ask the agent to revalidate it against the data.

When we roll out AI analysis for a client, teaching people to brief it well is part of the work, not an afterthought. It is the difference between a tool people try once and a tool they rely on.

Why not just use Claude?

It is a reasonable question. Connect Claude or ChatGPT to your data and ask it to analyse something, and it will have a go. So why build an analyst agent and a set of specialist agents at all?

• Speed. The specialist agents and curated 360s already know where the answers are, so the groundwork is done before the question is asked.
• Cost. Only the analyst agent needs a powerful model. The focused agents underneath it run on lighter, cheaper ones.
• Context. The knowledge base is there on every question, rather than relying on what someone remembers to put in a prompt.
• Consistency. The definitions and logic live in the agents, not the prompt, so everyone gets answers built on the same rules.

It is not either/or. In fact, Claude or ChatGPT is the ideal front door, connected over MCP, as it is for an AI layer we built on Databricks. That brings two big benefits. External research: the front door can bring in market trends, competitor activity or economic conditions and feed them into the analyst agent, so the analysis covers what was happening around the business as well as inside it. And presentation: once the analysis is done, tools like Claude Design can turn it into the deck, document or report you need to take to the leadership team.

So, can AI agents replace data analysts?

Partly, and the part they can replace is bigger than most people expect. With the agent doing the legwork and the business and operational context kept current, everyday analysis no longer needs a dedicated analyst. More business users can become their own analysts, asking their own questions and getting proper answers in minutes. That frees analysts to focus on the new, complex and exploratory work where their judgement counts most.

That depends on a lot going right, and far more on the business than on the technology. Here are the considerations we would weigh:

• Who will ask, and who will brief? Everyday questions can be asked by anyone with the right set-up, if they learn to ask well and challenge the answer. New, exploratory analysis needs someone who can set a clear direction, and that is where an analyst’s judgement counts most.
• Who keeps the context current? The business context needs reviewing as the strategy moves on, and the operational context needs recording as things happen. If nobody owns that, the analysis quietly gets worse.
• How much coaching will it take? Asking well and briefing well are both learnable, but neither happens by itself. Budget for training and for coaching in the first few months, not just for the agents.
• Who checks the answer? The agent checks its own work against the data. Someone still needs to check it against the business, and to own the decision it informs.
• What would analysts do instead? The new and complex analysis, plus the work that makes everyone else’s analysis good: curating the data, owning the knowledge base, designing the 360s and agents, and coaching. That may simply be where the analyst role is heading.

Perhaps the better question is not whether AI agents can replace analysts, but whether the business is ready to do what analysts used to do for it: ask the right question, and recognise a good answer when it sees one.