How to Build a Microsoft Fabric Data Agent: Grounding, Instructions and Testing

Standing up a Fabric Data Agent is genuinely quick. You point it at a lakehouse, warehouse or Power BI semantic model, and within an afternoon it is answering questions in plain English on Azure OpenAI. That speed is why the demo always impresses and why the second half of the work gets skipped.

The second half is making the agent trustworthy — and it is where the value is. An agent that answers fluently but wrongly is worse than no agent, because people act on it. The difference between an agent operations relies on and one they abandon within a month is entirely in the grounding, the instructions and the testing.

So treat the build as two distinct jobs. The first is configuration, and it is easy. The second is the discipline that makes the answers correct, and it is the reason to bring rigour rather than just enthusiasm.

A Fabric Data Agent can ground on a lakehouse, a warehouse, a Power BI semantic model, a KQL database, a mirrored database or an ontology. The choice matters because the agent inherits the quality and the definitions of whatever it reads. Ground it on a clean, governed semantic model with one definition of each measure and it answers consistently; ground it on raw tables with ambiguous columns and it guesses.

For most operations the best starting source is a well-built Power BI semantic model, because the hard work of defining measures, relationships and row-level security is already done there. The agent reasons over that structure rather than inventing its own. Where the questions span domains the semantic model does not cover, add a governed lakehouse or warehouse rather than reaching for ungoverned data.

The anti-pattern is grounding an agent on everything available in the hope of covering more questions. Breadth over ungoverned data buys you more confident wrong answers, not more coverage. Start narrow on trusted sources, prove the agent, then extend.

Configuration is not enough; the agent needs steering. Fabric Data Agents take source-specific instructions and example questions, and these are how you encode the business context the raw data does not carry — that "throughput" means pallets per hour here, that revenue excludes intercompany, that the default period is the current fiscal quarter.

Write instructions the way you would brief a new analyst: which measures to use for which questions, what filters to apply by default, what to do when a question is ambiguous. Provide example question-and-answer pairs so the agent learns the shape of a good answer for your data. This is the highest-return hour in the build — a well-instructed agent on a decent model beats a bare agent on a perfect one.

Keep the instructions versioned and owned, because they will need refinement as you see the questions people actually ask. The first set is a hypothesis; the monitoring below tells you where it was wrong.

An agent that ignores security is a data-leak risk with a friendly face. Before publishing, enforce the row-level security and sensitivity labels on the underlying data so the agent respects exactly the boundaries your reports do — a regional manager gets their region, not the whole company. Apply Microsoft Purview sensitivity and lean on the OneLake catalog so the grounding sources are endorsed and classified.

Decide the access model too. For a person asking questions in Teams, delegated identity carries their permissions. For an application or another agent calling this one, use service-principal authentication so the app has its own governed identity rather than borrowing a user's. Set cross-geo AI processing appropriately for GCC, UK, US or India tenants.

Governance is a build step, not a hardening pass you bolt on later. Publishing an ungoverned agent and tightening it afterwards means it has already answered questions it should not have.

The step that separates a professional build from a demo is validation. Assemble a set of test questions where you already know the correct answer — computed independently from the data — and run them through the agent before anyone trusts it. This catches the ambiguous measures, the wrong default filters and the questions the instructions did not anticipate.

Treat failures as grounding or instruction problems, not prompt problems. If the agent gets margin wrong, the fix is almost always a clearer measure definition or a sharper instruction, not a cleverer question. Iterate the model and the instructions until the test set passes, then keep the test set as a regression check for when the data or the model changes.

Once live, monitor the real questions: which the agent answers well, which it cannot, where users rephrase because the first answer was off. That stream is how you extend the test set and refine the agent — because an agent is maintained, not finished.

Build a Fabric Data Agent in this order: ground it on clean, governed sources; instruct it with your business context and examples; govern it with RLS, sensitivity and the right access model; test it against known answers; publish on F2+ capacity with service-principal access; then monitor and refine. The configuration is the quick part; the other steps are what make it trustworthy.

The single mistake that sinks these projects is grounding on ungoverned data and hoping the AI compensates. It does not — it produces fluent wrong answers, people lose trust, and the agent is quietly abandoned. Get the foundation right and the agent is a genuine force multiplier for the analyst team and the operation.

That foundation — a governed semantic model, unified data, endorsed catalog — is the same foundation everything else on Fabric depends on, which is why we build it first regardless of the headline feature. The agent is the visible payoff of getting the invisible part right.