For years, the pattern has been the same: a business user has a question about data, goes to an analyst, and the analyst builds a view, a filter, or an entire report. Then the question changes slightly, and the cycle starts again. I’ve seen this dynamic across multiple implementations, and frankly, it’s a communication gap between the world of reports and the world of day-to-day decisions. Fabric Data Agent is Microsoft’s answer to this gap. I tend to approach new tools with caution, as most of them require users to change their habits. This one doesn’t. Users ask questions exactly as they always have - just not to a person, but to a system that understands the organization’s data.
What exactly is Fabric Data Agent
It is a specialized AI assistant embedded in Microsoft Fabric, working in tandem with Power BI. Its scope is narrow and well-defined: it analyzes structured business data in response to natural language queries.
This is not a general-purpose model for writing emails or summarizing documents. The agent works directly on your data. Its knowledge base consists of the tables, relationships, and measures defined within your organization.
From a technical perspective: when a user asks a question, the agent considers its initial instructions, any example queries, and the reasoning of the language model. Based on that, it generates a DAX or SQL query, sends it to the data source, and returns the result in a user-friendly format-most often as a table.
The user doesn’t need to understand this chain of operations. For them, it’s simply an answer.
Access to the agent is controlled via Microsoft Entra ID. For large organizations, this is essential. There is no uncontrolled data flow to external models.
When Fabric Data Agent makes sense
The answer is not “always” or “for everyone.”
- The agent adds value when data is already in Microsoft Fabric - or when migration is planned in the near term. It can then act as a central access point across multiple sources: Power BI semantic models, Lakehouse tables, and operational data. A single report shows what an analyst designed. The agent answers questions no one anticipated, using the same relationships and measures already defined in the model.
- It also makes sense where users do not work with DAX or SQL - which is essentially everyone outside BI teams. A sales rep reviewing order history before a meeting, a logistics manager identifying low-stock products, or a finance specialist verifying margins on a portfolio - all of these questions can be asked directly, without intermediaries.
Teams is also worth considering. In organizations where it’s already in use - which includes most large companies in Poland - the agent is available without opening Fabric, without additional login, even from a mobile device. The entire data layer becomes accessible through a single chat window.
Who benefits and what they gain
I see four main beneficiary groups:
- Sales, operations managers, product managers - people without analytical skills gain direct access to data they previously had to request from others. They ask questions in their own terms: “which products are performing worst this month?” or “which customers haven’t ordered in over 30 days?” The result is a table.
- BI teams experience fewer ad hoc requests. What used to become a ticket - “can you pull sales for X broken down by Y” - is now handled directly by users. Analysts can focus on high-value reporting instead of repetitive queries.
- Executives gain the ability to verify operational data without intermediaries. A question before a board meeting, an answer within minutes via Teams on a phone - this is a different level of access compared to waiting for prepared reports.
- IT and administrators retain full control over data access. Permissions are managed via Entra ID and Fabric roles. The chat interface does not alter existing security rules.
What working with data looks like in practice
Using a data model I generated, I configured the agent for a sales environment: customers, orders, order lines, products, and inventory-connected through defined relationships.
First query: the last three orders of a specific customer. The agent returned correct order numbers. The question was too general, so I refined it - show each order separately, with date, product, quantity, and total value.
The agent split the request into three separate database queries and returned three tables. I then asked for a summary of each order outside the table, including date and order number. The result matched the requested format.
Next, I tested context switching: how does this customer rank compared to others by order value? The agent returned a ranking, but included full customer names - data I did not want exposed. I asked to replace names with customer IDs and extend the ranking to the full list, highlighting the selected customer. The result was exactly as requested.
In most cases, changing the topic mid-conversation did not require starting over. The agent retained the preferred format.
“Do the same for January, but without ranking customers” produced results in the same structure I had previously defined.
The agent learns preferences within the conversation and maintains context. This makes a noticeable difference in everyday use.
Complex queries and inventory status
Next test: one complex query instead of multiple simple ones.
Provide sales for a specific product in a given month - total quantity, value, a breakdown by date and quantity, a per-customer breakdown without personal data, and current inventory levels.
The agent split the request into four queries and returned a complete picture. Ten units sold, four remaining in stock. Given the current sales pace, this indicates a need for replenishment.
I then asked for other low-stock products - and received a list of seven items to reorder, without browsing reports.
These types of questions - fast, operational, cross-sectional - are the agent’s natural environment. Reports have fixed structures. The agent answers what decision-makers need at a given moment.
Handling incorrect or imprecise queries
A practical example: a user searches for a product called “Bear Daisy,” while the database contains only “Deer Daisy.”
A strict matching system would fail. The user would assume the product does not exist.
A properly configured agent handles this differently. It breaks the query into components, searches across product names and collections, and returns possible matches. The user selects the correct one.
In this case, the agent returned products from the “Bear” collection and items partially matching “Daisy.” The issue turned out to be a simple memory error.
This mechanism requires configuration - it does not work out of the box. And that illustrates what working with an agent actually means: building instruction layers and exception - handling logic that make it usable in real scenarios.
Instructions determine quality
Fabric Data Agent operates based on initial instructions. Their quality directly impacts output quality.
In configurations I build, these typically include:
- the agent’s role and scope,
- communication rules (format, currency, language, level of detail),
- data structure descriptions (especially important for Lakehouse sources),
- exception-handling procedures.
Instructions should evolve iteratively. If users repeatedly request hiding personal data, this should become a default rule - not an exception.
The agent improves not through model updates, but through better configuration.
From a technical standpoint, naming conventions matter. Table and column names should be readable. “CustomerID” works. “CustID_v2_final” does not.
If Power BI models include measures, adding descriptions helps. The agent uses them instead of inferring meaning on the fly.
Query logs as a source for report development
One particularly valuable aspect: every generated DAX or SQL query is logged along with its logic.
This is more than a diagnostic tool.
If users repeatedly ask the same question - for example, product sales share in a given month - you already have ready to - use DAX code. It can be added to a Power BI report as a measure or visualization.
The agent not only answers questions - it reveals gaps in existing reporting.
The right approach is to treat the agent as a tool for exploration and operational queries, and reports as the final layer for structured analysis. One without the other is less effective.
What Fabric Data Agent does not do
It does not create visualizations. No charts, no dashboards, no matrices.
If a user requests a chart, the agent suggests moving to a report and generates DAX code. This is by design - and reasonably so. Forcing visualization through a language model usually leads to poor results.
Fabric Data Agent is suited for exploration - fast, irregular, operational queries. Power BI reports are suited for presentation - structured, repeatable, visual analysis.
For decision-makers who need both dashboards and quick answers, the combination works.
FAQ
Does Fabric Data Agent require rebuilding existing data infrastructure?
No, if data is already in Microsoft Fabric. The agent connects to existing Power BI semantic models and Lakehouse tables without migration. However, metadata quality - clear naming and measure descriptions - significantly improves results.
How is data access controlled?
Through Microsoft Entra ID and Fabric roles. The agent only accesses defined tables and sources. Users see only what they are authorized to see.
How long does implementation take?
It depends on data quality. With a well-built Power BI model, a working setup can be configured within a day. Iterative refinement and testing follow during pilot phases.
