, I have the opportunity to try new AI-powered analytical tools, including Microsoft Fabric’s data agent. That’s why I want to share what I’ve learned, explain what a data agent is, and highlight the difference between it and a “standard” AI agent.
So, without further ado, here is my definition of a data agent:
A data agent is a report you can talk to.
For those of us in analytics, this means two long-held wishes might finally become a reality:
#1: Analysts spend way less time building visualisations.
#2: Self-service insights come closer to business users.
Let me elaborate on each of these points a bit more.
Fewer visualisations, not fewer insights
I really enjoy a good report that can tell me “what’s up” with the metrics I am currently interested in. But being trained in analytics, I know how reports can sometimes cast metrics in the wrong light, leading business users to frequently ask analysts for KPIs interpretation, usually 10 minutes before important meetings.
And that’s one of the reasons we often end up in a vicious cycle of having dashboards no one is using, and stakeholders constantly wanting “the number” served ad hoc or via spreadsheets.
On the bright side, visualisations and spreadsheets are not going anywhere, but serving the insights has a new way with a Fabric data agent.
Instead of wrapping queries in graphs, you can wrap them in prompts and instructions paired with the consumption-ready governed data estate in Fabric, i.e., in a lakehouse, warehouse, Power BI semantic models, KQL database, or even an ontology. This implies the underlying data still needs to be prepared and modelled to answer business questions such as “What was the revenue this week compared to last week?”
However, from a design perspective, rather than creating a scoped visual report to answer this business question, you now create a scoped data agent to provide this, and other subsets of answers derived from the underlying data model(s).
More precisely, the input-output flow goes as follows:
(1) a stakeholder asks a question, (2) the agent, powered by Azure OpenAI Assistant API, interprets the question and “decides” which of data sources is most likely to have the answer based on source schemas and agent instructions, (3) generates the appropriate query (SQL, DAX, or KQL depending on the source type), (4) validates it, (5) executes it under the stakeholder’s credentials, and (6) returns the result as a text or a table, not (yet) as a visual.
In sum, a stakeholder interaction with insights via the data agent is a Q&A session on top of the curated dataset, and drill-down visuals can be replaced with follow-up questions, such as “Can you also break the revenue out by segment?”
With that, it is clear how analysts’ work no longer needs to be re-expressed only via dashboards, aka the long-known tangible proof that the work of capturing the business logic within data models was delivered.
Now, let’s talk about…
Self-service insights, closer to where business users “live”
I mentioned before that reports can sometimes misrepresent metrics, but that’s not the only reason why “If you build it, they will come” rarely works for them or analytics in general. The truth is, the knowledge barrier is often too high to understand the underlying semantic models and how to use BI tools to create visuals on top.
Although this points to data literacy, which is a change-management problem, it’s a fact that the targeted business audience, who should be report consumers, often has too much on their plate to bother learning BI tools for self-service analytics.
That’s why it’s important to bring insights closer to where end users “live”, which nowadays points towards AI-powered tools like M365 Copilot.
With the possibility to expose insights via data agents outside of Fabric, analysts can now focus on the analytical logic behind self-service data agents, and end users can access insights in the same AI-powered tools that support their other daily tasks, without the complexity of switching to another platform.
I have to note this is not the only way to integrate Fabric data agents in the workflows, and regardless of whether you’re a developer or a consumer, it’s good to know…
The difference between data and an AI agent
We’ve learned so far that the Fabric data agent is an analytical agent focused on read-only, governed data access, capable of translating natural language prompts into complex database queries that unlock insights, even outside the Fabric tenant.
On the other side, an AI agent is defined as a system that allows Large Language Models (LLMs) to do things, not just respond to prompts, on behalf of users or other systems by accessing tools and knowledge.
Meaning, the whole magic is in the AI agent setup, where you can use a Fabric data agent as a specialised tool or knowledge source.
I’ll illustrate this with one simple example.
Imagine an authorised user requests the AI agent to “Draft an email to the team summarising last week’s revenue by segment.” To get this work done, the AI agent would, among other things, need to prepare revenue insights from the enterprise database. So, in an aim to reduce errors in revenue calculation, the developer would design an agentic workflow to route the input prompt to the Fabric data agent tool, which would handle the heavy lifting of determining the schema, writing the query, executing it, and returning the precise figures. Finally, the AI agent would then use those figures to finish its broader workflow and write the email.
What’s the difference between those two, then? It’s that an AI agent acts, while the data agent grounds.
Thank you for reading.
If you found this post valuable, feel free to share it with your network. 👏
Want to learn more about data agents?
If that’s the case, check out the following resources:
Fabric data agent creation – Microsoft Fabric
Learn how to create a Fabric data agent that can answer questions about data.learn.microsoft.com
Implement Microsoft Fabric Data Agents – Training
Implement Microsoft Fabric Data Agents (chat with your data)learn.microsoft.com