Ontology gives your data shared meaning. Semantic models give it structure. But most business users still can’t get an answer out of either one without someone writing a query for them first.
That’s the gap the Fabric data agent is meant to close.
What is a Fabric Data Agent?
A Fabric data agent is a conversational Q&A layer, built on generative AI, that sits directly on top of your data in OneLake. Users ask questions in plain English instead of writing SQL, DAX, or KQL, and the agent handles the translation behind the scenes.
The point isn’t just saving a few keystrokes. It’s opening data up to people who don’t know where it lives or how it’s structured, and still getting them a precise, grounded answer.
How the Fabric Data Agent Works
Every question a user submits runs through a fairly deliberate pipeline before an answer comes back.
The agent first parses and validates the question using Azure OpenAI Assistant APIs to figure out intent. From there, enforcement mechanisms, including Azure AI Content Safety, check the request against the user’s own permissions. The agent then identifies which connected data source is relevant, using that same user’s credentials to inspect schema.
Once a source is identified, the agent picks a translation tool based on what it’s talking to:
- NL2SQL for lakehouses and warehouses.
- NL2DAX for Power BI semantic models.
- NL2KQL for KQL databases.
- Microsoft Graph queries for organizational data.
The generated query gets validated for correctness and security before it ever runs, then executes against the source, and the result is translated back into a natural-language answer.
Data Agent vs. Copilot: What’s the Difference?
It’s tempting to lump every AI feature in Fabric under “Copilot,” but data agents and copilots aren’t solving the same problem.
| Feature | Fabric Copilot | Fabric Data Agent |
|---|---|---|
| Configuration | Fixed, built-in behavior | Configurable with custom instructions and examples |
| Scope | Assists with tasks inside Fabric, like generating notebook code or warehouse queries | Answers natural-language questions about your data |
| Best Use Case | Speeding up development work | Building a reusable Q&A experience over your data estate |
Configuring a Data Agent
Setting one up feels a lot like building a Power BI report. You pick your data, narrow the scope, then refine.
A single data agent supports up to five data sources, in any combination of lakehouses, warehouses, KQL databases, and semantic models. You don’t have to expose an entire source either. Choosing the specific tables relevant to the questions you expect keeps the agent focused and reduces ambiguity.
The real accuracy gains come from context. You can add instructions that steer how the agent should behave, and example question-and-query pairs that model the kind of answers you want to see.
Microsoft expanded on this in 2025 with Data Source Instructions, which let you define guidance per data source instead of one generic instruction set for the whole agent. Per the Fabric Community blog announcing the feature, this helps when different datasets follow different business rules, share ambiguous column names like date or status across tables, or need consistent join logic applied every time. A good instruction might tell the agent which table to check for historical sales, or that state codes should use two-letter abbreviations instead of full names.
Developer-provided instructions don’t override anything above them. Organizational policy and workspace-level permissions still sit higher in the chain.
Governance and Security
Because a data agent can touch sensitive data, Microsoft Purview does a lot of the heavy lifting here. Purview DLP policies and access restriction policies can detect and block sensitive data before it reaches a response. Outbound access protection at the workspace level still applies, and when a data agent is surfaced through Microsoft 365 Copilot, the same governance policies carry through with it.
A data agent doesn’t sit outside your existing security model. It operates inside it.
Built for ALM, Not Just Experimentation
Fabric treats data agents as first-class items with real application lifecycle management support. Built-in diagnostics help monitor behavior and troubleshoot query generation issues. Git integration lets you version-control agent configuration. Deployment pipelines let you promote an agent from development to test to production the same way you would a warehouse or a pipeline.
Current Limitations
A few constraints are worth knowing before you scope a use case:
- Agents only generate read queries and can’t write back to your data.
- Unstructured data, like PDFs, Word docs, or plain text files, isn’t supported.
- English is currently the only well-supported language for questions.
- You can’t swap out the underlying LLM.
- Conversation history isn’t guaranteed to persist in every scenario.
- Access to Power BI semantic models through a data agent still respects Read permission on the model itself.
Final Thoughts
Ontology gives your data shared meaning. The data agent is what lets people actually talk to that meaning, without learning SQL, DAX, or KQL first.
It isn’t a replacement for a governed semantic layer. It’s built on top of one, and it inherits the same security and governance boundaries already in place. As Fabric keeps pushing toward a more conversational way of working with data, the data agent feels like the natural next step after ontology and semantic models: less about restructuring how data is stored, and more about finally letting people ask it questions directly.