Creating Data Agents
in Microsoft Fabric

Why data agents matter

Most organisations already have the data. The harder bit is helping people get to the answer without needing to understand SQL, DAX, semantic models, lakehouse tables, or where the right report lives.

A Fabric data agent gives users a conversational layer over curated data. That does not remove the need for modelling, governance, or data quality. In fact, it makes those things more important. The agent is only useful if the underlying data is clear, trusted, and properly secured.

What a Fabric data agent can connect to

Fabric data agents can answer questions over semantic models in Microsoft Fabric. In simple terms, the data agent sits on top of a curated model rather than connecting directly to raw tables or files. This is important because the semantic model already contains the business logic, relationships, measures, hierarchies, and friendly field names that users rely on in Microsoft Power BI.

That means the agent is not just querying data in isolation. It is working against the same governed layer that supports reports and dashboards. Answers are therefore more likely to reflect the way the business actually measures things. For example, if a semantic model already contains approved measures for sales, margin, stock, availability, or budget variance, the data agent can use those definitions when responding to user questions.

This also helps reduce the risk of different users getting different answers depending on which table they query or how they interpret the data. Instead of asking users to understand the underlying schema, the data agent allows them to ask questions in natural language against a model that has already been structured for reporting.

A typical setup might involve a semantic model built over a Fabric Lakehouse, Warehouse, or Direct Lake model. The data agent then provides a conversational layer on top, allowing users to ask things like:

“What were sales last week by region?”

“Which products had the biggest drop in margin?”

“Show me stores where availability is below target.”

“How does this month compare with the same period last year?”

The key point is that the quality of the data agent depends heavily on the quality of the semantic model underneath it. A well-designed model with clear naming, trusted measures, and properly defined relationships will give the agent a much stronger foundation to work from.

The important bit: it is not magic

A data agent is not a shortcut around good BI design. It will not magically fix poor naming, broken relationships, unclear measures, or inconsistent definitions. If your business has three versions of “sales”, the agent needs to know which one matters.

The best results come when the agent is pointed at a well-modelled, business-friendly semantic layer. That means clear measure names, useful descriptions, sensible relationships, and agreed terminology.

Security and permissions

A key point: sharing the agent is not the same as granting universal access to the data. Fabric data agents honour the user’s underlying permissions, including Row-Level Security and Column-Level Security. For Power BI semantic models, users need Read permission on the semantic model.

Where the real use cases are

The best use cases for Fabric data agents are not about replacing reports or giving everyone a magic chatbot. They are about helping people ask better questions of trusted data.

For business users, the value is in making governed data easier to access. Instead of trying to find the right report, tab, filter, or measure, users can ask a question in plain English and get a response based on approved Fabric sources. That is useful in areas like finance, sales, operations, fundraising, stock, margin, and executive reporting. There people often need a quick explanation before they know what to look at next.

For BI teams, data agents create a more guided way for users to explore data without constantly relying on analysts for every follow-up. If the agent is built on top of a well-modelled semantic layer, it can help answer repeatable business questions, explain trends, and reduce some of the demand for one-off analysis. It does not remove the need for dashboards, but it can sit alongside them as a more conversational access point.

For data teams, the opportunity is around controlled self-service. Rather than users exporting data, building their own versions of the truth, or asking questions across disconnected spreadsheets, a data agent can be pointed at curated Fabric items. That means the answers are grounded in the same lakehouse, warehouse, semantic model, or other governed source that the organisation already trusts.

For organisations trying to widen access to analytics, that is probably the bigger story. Data agents make it easier to expose data to people who may never write SQL, build a Power BI report, or understand the underlying model. But that only works if the agent has been set up properly, tested carefully, and connected to data that is genuinely ready to be questioned.

Availability does not mean readiness

This is the point that often gets missed. Just because you can create a data agent in Fabric does not mean it will immediately answer questions well. A data agent needs the right sources, the right permissions, and the right instructions. If it is pointed at a messy warehouse, unclear table names, poorly described measures, or half-finished models, the experience will be weak.

There is also a setup consideration. Data agents need to be created inside the right Fabric workspace and connected to supported data sources. Those sources could include lakehouses, warehouses, Power BI semantic models, KQL databases, ontologies, Graph data, and other supported Fabric items. The important point is that the agent only becomes useful once those sources are structured and described in a way the agent can understand.

Permissions also matter. Users still need access to the underlying data. A data agent should not be treated as a back door around security. The same governance thinking applies as with Power BI and Fabric more broadly: who should be able to use it, what data should it expose, which audiences should see it, and how do we test that it is giving reliable answers?

Most organisations should not roll data agents out to everyone on day one. A better approach is to start with a focused use case, choose a trusted dataset or semantic model, build the agent around a clear subject area, and test it with real business questions. That gives you a much better chance of proving value before scaling it more widely.