We have spent years building lakehouses, warehouses, semantic models, dashboards, and governance processes in Microsoft Fabric. Yet one of the most common problems remains surprisingly simple: a person has a valid business question but does not know how to get the answer from the data.

The data may already exist. It may already be modeled, secured, and refreshed. The user may even have access to it. But the user does not know which report to open, which measure to trust, what filters to apply, or whether the answer requires DAX, SQL, or KQL.

This is the problem I believe Fabric Data Agents can help us solve.

A Fabric Data Agent gives people a conversational way to ask questions of governed data. The agent translates a business question into a read-only query against an approved Fabric data source and returns an answer using the permissions the user already has.

That sounds straightforward, but it changes an important part of the user experience: people can begin with the question instead of beginning with the technology.

Start with the question, not the report

Consider a sales leader who wants to understand which customer renewals may require attention next quarter.

Today, that question might begin with a search for the right Power BI report. Once the sales leader finds it, the next challenge is understanding which page, slicer, date field, and status measure to use. The report may show the overall renewal forecast but not answer the immediate follow-up questions:

• Which regions account for most of the risk?
• Are the affected accounts concentrated in one market segment?
• Which renewals changed status recently?
• What records are contributing to the total?

At that point, the sales leader may export the data, ask an analyst for help, or request a change to the report. A reasonably small question has now become a BI request.

A well-designed Fabric Data Agent gives the sales leader another way to continue the investigation. Instead of waiting for a new visual or report page, the sales leader can ask the next question directly.

That does not mean the data agent replaces the dashboard. The dashboard still provides the consistent visual experience, approved measures, trends, and shared view of performance. The data agent helps the user investigate what the dashboard reveals.

This is why I see dashboards and data agents as complementary. A dashboard helps people see what matters. A data agent helps them continue asking questions when the answer is not already on the page.

The agent can generate SQL, DAX, or KQL based on the configured source and the question being asked. The user does not have to know which query language is required. More importantly, the user should not have to understand whether the answer is coming from a semantic model, warehouse, or KQL database. Deciding which source should answer a particular type of question is part of how we design the agent.

Make the knowledge behind the data reusable

The sales leader’s renewal question may appear simple, but the correct answer depends on knowledge that often lives in several places.

Questions that come up in the real world: What qualifies as a renewal? Which date determines the quarter? What does “at risk” mean? Should cancelled accounts be included? Is the approved renewal measure in a Power BI semantic model, or should the question be answered from detailed warehouse records?

An experienced analyst may know all of this. The user asking the question probably does not.

This is where I think the value of a data agent is often misunderstood. The agent is not valuable simply because it accepts natural-language questions. Its real value depends on how well we give it the context needed to interpret those questions.

In Fabric, that context can come from semantic-model measures and relationships, business-friendly names, synonyms, source descriptions, agent instructions, verified answers, and example question-and-query pairs. These are the elements that help the agent understand that “renewals next quarter” has a specific business meaning and is not just a phrase to match against a column name.

For the renewal scenario, I would want the approved business measures to come from a curated Power BI semantic model when the user is asking about official metrics. I might use a warehouse when the user needs detailed transactional records and a KQL database when the question involves operational events. The agent’s source descriptions and instructions should make those responsibilities clear.

The objective is not to connect the agent to everything and hope it figures everything out. The objective is to give it a focused set of authoritative sources and enough business context to use those sources correctly.

This also changes where analysts and data engineers can spend their time. Instead of repeatedly answering variations of the same renewal question, they can improve the reusable data product by:

• Clarifying the definition of renewal risk
• Creating or validating the appropriate measures
• Improving table, column, and measure descriptions
• Documenting which source should answer each type of question
• Adding representative examples
• Testing the agent with the questions users actually ask
• Comparing the results with known-correct answers

The expertise is not removed from the process. It is captured and made reusable.

Make conversational access governed and trustworthy

Making data easier to question does not mean bypassing the controls already built around it.

A person using a Fabric Data Agent still needs permission to the underlying source. For example, a user can ask questions of a Power BI semantic model through an agent with Read permission on that model, without requiring Build permission or membership in the workspace. Existing row-level and column-level security continue to apply.

In the renewal scenario, that means the sales leader should only receive information the sales leader is authorized to see. The conversational interface does not create a separate security model. The permissions on the underlying Fabric items still matter.

This is one of the reasons I view governance as an enabler, especially for data agents rather than a barrier. Clear ownership, approved sources, well-designed permissions, and consistent business definitions give us the foundation needed to make conversational access useful.

At the same time, we need to be realistic about what an agent does and does not do.

A Fabric Data Agent performs read-only queries. It does not update the renewal status, assign an account owner, or write notes back to a source system. It is also not intended to act as a bulk data-extraction mechanism. If the business process needs to take action after identifying a renewal risk, the data agent may need to be combined with Copilot Studio, Power Automate, or a custom application.

The agent also cannot independently determine why a customer is at risk unless the necessary information and analytical logic exist in its approved data sources. It can help the sales leader identify patterns, compare records, and continue investigating the available data. It should not present an unsupported assumption as root cause.

This is where production testing matters.

A demonstration can look successful when the agent is asked a few carefully selected questions. Actual users will ask those questions in different ways, use unexpected terminology, omit important context, and continue with follow-up questions. The same question may behave differently depending on the available metadata, selected source, wording, and conversation history.

Before treating a data agent as a production data product, I would test it with representative questions from the people who will actually use it. For the renewal scenario, that test set should include the obvious questions, ambiguous wording, follow-up questions, permission differences, and questions the agent should not attempt to answer. The results should be checked against known-correct answers, not simply reviewed for whether they sound reasonable.

Final Thoughts

Fabric Data Agents do not eliminate the work required to create trustworthy data products. They make the quality of that work more visible.

If the underlying data is curated, the measures are clear, the permissions are tested, and the business terminology is documented, a data agent can make that investment useful to more people. If the data is duplicated, poorly described, inconsistently defined, or broadly permissioned, a conversational interface will not correct those issues. It may expose them faster.

Through experience, I have come to see the most promising role for a Fabric Data Agent as the governed conversational layer over a focused business domain. It gives users a more natural way to ask the next question while allowing the organization to retain its existing Fabric security, semantic models, and authoritative data sources.

Relevant Posts

• Ground Truth Before Go-Live: Building Better Fabric Data Agents with Automated Evaluation Datasets