Fabric data agent

What is a Fabric data agent?

A Fabric data agent is something you build inside Microsoft Fabric that answers questions about your data in ordinary language. You point it at a handful of data sources, you give it instructions and example questions, you publish it, and then your colleagues can start asking it things.

Microsoft makes a comparison that works well here. Setting up a data agent feels a lot like building a Power BI report. You design it, you refine it, you test it, and then you share it with people who never see the plumbing behind it. The difference is that a report answers the questions you thought of in advance, and an agent tries to answer the ones you did not think of.

Two things in that description matter more than the rest. The agent is read-only, which means it only generates queries that look things up, and never anything that creates, changes or deletes data. And it runs as the person who asked, using their permissions, so your row level security and column level security keep working exactly as before. An agent is not a back door around the access rules you already have.

How a data agent answers a question

Behind a single question there is a short chain of decisions.

1. It reads and checks the question
   Before anything runs, the question is checked against the security rules, against the responsible AI policies, and against the permissions of the person asking.

2. It picks a data source
   The agent reads the schema of the sources it is allowed to see and decides which one fits the question. Your instructions steer that choice, so you can send financial questions to the semantic model, raw exploration to the lakehouse, and log questions to the KQL database.

3. It writes the query
   For each type of source the agent calls a different tool. It uses natural language to SQL for a lakehouse or a warehouse, natural language to DAX for a Power BI semantic model, natural language to KQL for a KQL database, and a Microsoft Graph query for organisational data.

4. It validates and runs the query
   The system checks the generated query for form and for policy, and then executes it. The result comes back as a readable answer, usually with a small table or a short summary.

Your users never see the SQL, the DAX or the KQL. That is exactly what you want, but it is also why the setup work matters so much. The only picture the agent has of your business is the schema plus whatever you took the time to write down.

How a data agent differs from a Copilot

Fabric has both of these, and teams mix them up all the time.

A Copilot in Fabric comes preconfigured and helps you with your own work in whichever tool you happen to be standing in. It can generate notebook code, draft a warehouse query, or summarise a report. You cannot tune how it behaves.

A data agent is a separate item that you configure yourself. It queries across OneLake and your semantic models, it carries your instructions with it, and you can call it from outside Fabric as well: from Microsoft 365 Copilot, from Copilot Studio, from Microsoft Foundry, or from Teams. Other orchestrators and multi-agent setups can call it too, while the agent itself stays on read-only, governed access to your data.

Put simply: a Copilot helps the person building things, and a data agent serves the people asking questions.

What you configure

Data sources
You can attach up to five per agent, in any combination of lakehouses, warehouses, KQL databases, Power BI semantic models, mirrored databases, ontologies and Microsoft Graph. You could use five semantic models, or you could mix two semantic models with a lakehouse and a KQL database.

Tables
For each source you choose which tables the agent is allowed to use. For a lakehouse that means tables and not loose files, so a CSV sitting in the files area does not exist for the agent until you load it in or expose it as a table. Keeping that table list short is the cheapest way there is to improve accuracy.

Instructions
This is free text that steers which source gets picked and explains your vocabulary. It is where you write down that your financial year starts in April, or that "customer" means the party being invoiced and not the delivery address.

Example queries
These are pairs of a question and the query that answers it, up to 100 per data source. They teach the agent the shape of your data far better than instructions do. At the time of writing they do not work yet for Power BI semantic models.

Governance and lifecycle

Because the agent uses the permissions of the person asking, it inherits the access model you already have instead of replacing it. On top of that, your Microsoft Purview policies apply to the underlying sources. Data loss prevention on a warehouse can block a query, and access restriction policies can keep sensitive assets out of an answer completely. Questions and answers can also fall under Purview audit and eDiscovery.

Microsoft describes the behaviour as a stack with a clear order of precedence. Your tenant policy beats workspace governance, which beats the instructions you gave the agent, which beat whatever the user types. So if someone asks the agent to ignore its own rules, they do not get to overrule an administrator.

For day to day management, a data agent behaves like the other items in Fabric. You get Git integration, so you can version your instructions and example queries. You get deployment pipelines to move it from development to production. And you get built-in diagnostics, so you can see how it chose a source and built a query.

What to watch out for with a Fabric data agent

It is built to answer, not to export. Answers are capped at 25 rows and 25 columns, and earlier answers in the same conversation colour the ones that follow. So if someone asks for "all the lines from this year" and then asks a follow-up question, they are reasoning on a truncated result. Starting a new conversation usually fixes that.

It does not handle unstructured data. PDF, Word and text files fall outside its scope. If the answer your colleague needs is sitting in a contract, then a data agent is the wrong tool and you want a retrieval setup instead.

English only, at the time of writing. Questions, instructions and example queries all work best in English. For a Dutch-speaking or French-speaking company that is a real question about adoption, not a footnote.

Capacity and region are hard requirements. You need a paid F2 capacity or higher, and the capacity of the data source has to sit in the same region as the capacity of the agent. A lakehouse in North Europe with an agent in France Central simply fails.

The quality follows the effort you put in. An agent that is pointed at every table in a workspace without a single instruction will disappoint you. The teams that get real value out of it treat the instructions and the example queries as something they maintain, and not as a one-off setup step.