Building an AI agent on your Fabric data with Microsoft Foundry: what has to exist first

Microsoft Foundry can now reach your Fabric data through a Fabric data agent and the Fabric IQ tool. The five things that have to exist before the first question is answered, the limits Microsoft publishes, and the one line to show your data protection officer.

The question we are asked most often this autumn is some version of "can we put an agent on our data". The answer on a Microsoft estate is yes, and the plumbing is now reasonably clear: a Fabric data agent sits on your lakehouse, warehouse or semantic model, and a Microsoft Foundry agent calls it as a tool. The person asking the question in Teams never sees any of that.

What is less clear to most people is how much has to exist before the first useful answer comes back. This post sets that out, using Microsoft’s own prerequisites and limits rather than a demo.

How does a Foundry agent reach Fabric data?

There are two Microsoft pieces. The Fabric data agent is generally available and lives in Fabric. You point it at up to five sources, give it instructions and example questions, and it turns a plain-English question into SQL, DAX or KQL, runs the query as the user, and returns an answer. The Fabric IQ tool in Microsoft Foundry, currently in preview, lets a Foundry agent pick one or more published data agents from the OneLake catalog and call them. Each data agent appears to Foundry as a Model Context Protocol endpoint, which is to say a tool the agent can decide to use.

Microsoft’s earlier method, adding a single data agent as a knowledge source by workspace ID and artifact ID, is being replaced by Fabric IQ. If you built on the earlier method, plan to move.

What has to exist first?

• A paid Fabric capacity, F2 or higher, or a P1 with Fabric enabled. Trial capacities do not get Azure OpenAI. The workspace must be in a region with the full Fabric stack, not Power BI only.
• The tenant setting for cross-geo processing and storing for AI turned on. For UK capacities, prompts are processed in the EU Data Boundary. Your data protection officer should know this before you switch it on, not after.
• A source with data in it: a lakehouse with tables (not files), a warehouse, a semantic model, a KQL database or a mirrored database. Unstructured documents are not supported by the data agent.
• A published data agent with written instructions and example question-and-query pairs. Microsoft allows up to 100 examples per source. The quality of these decides the quality of the answers more than the model does.
• The same tenant and the same signed-in account for Fabric and Foundry, read access to the data agent and its sources, and the Foundry User and Project Manager roles for the people building it.

What does Microsoft say it cannot do?

These limits are published and they shape what you should promise the business:

• Answers are read-only. The agent cannot insert, update or delete.
• Responses are capped at 25 rows and 25 columns. It answers questions; it does not export tables.
• It works best in English, and you cannot change the underlying model.
• The data source and the agent’s capacity must be in the same region, or queries fail.
• Purview DLP and sensitivity restrictions can block a query or produce an incomplete answer. That is the right behaviour, but people need to know why they got a short answer.
• Responses returned to Foundry may be sent outside Fabric’s compliance boundary or geographic region. This is the line to show your data protection officer.

Why the semantic model matters more than the agent

The agent runs as the signed-in user. That is good: row-level security still applies, and a regional manager cannot ask their way into another region’s margin. But it also means the agent inherits every definition in your model. If gross margin is calculated three ways in three reports, the agent will pick one and sound confident. We have written before about why a CFO can only sign off a number that AI produced when the model does the calculating and the AI does the asking. That is exactly the division of labour a data agent enforces, provided the model is worth trusting.

In practice the order of work is: fix the definitions, certify the model, write the instructions and examples, then build the agent. Teams that start at the fourth step spend the first month discovering the first three. Our guide to Fabric IQ and Copilot on your semantic model covers the preparation.

What does it cost to run?

Data agents and Copilot consume capacity units from the Fabric capacity on the Copilot and AI meter. Microsoft publishes the rates per 1,000 tokens for each model, and they can change. The practical consequence is that a popular agent on an F2 will throttle the rest of the estate. Watch the Capacity Metrics app in the first fortnight and size accordingly. Our post on measuring whether AI analytics is paying off gives the measures worth tracking alongside the cost.

Where to start

Pick one question that is asked every week and answered by someone opening three reports. Build the agent to answer that one question well, with 20 good examples, for 10 users. Measure the hours it saves and the answers it gets wrong. Then widen it. An agent that answers one question reliably earns the right to answer the next one.

If you want help deciding whether your estate is ready, the free data assessment tells you where the model stands, and our Microsoft AI and Copilot page sets out how we approach agent work.

Microsoft’s pages: Data agent concepts, Add Fabric data agents to a Foundry agent with Fabric IQ and Overview of Copilot in Fabric.

Related reading

• Microsoft AI and Copilot
• Fabric IQ and Copilot on your semantic model: a practical guide
• Can a CFO sign off a number that AI produced?
• Only one AI agent in four pays back
• Where does your data live in Microsoft Fabric?