Build Once, Use Everywhere: Fabric Data Agents as the Gate to Your Data
Everyone talks about Lakehouses, Warehouses and Direct Lake. Here are six reasons why Data Agents deserve a seat at that table too.
Let me start with the bottom line: Data Agents are one of the coolest things in Microsoft Fabric right now. And I think they are underestimated.
In most data platform discussions I’m part of, we spend hours on the classic topics. Lakehouse or Warehouse. Medallion layers. Capacity sizing. Direct Lake or Import. All important. The Data Agent usually shows up at the very end, as “the AI part”. A nice demo, a few wows, next topic.
I think that’s a mistake. A Data Agent is not a chat feature on top of your platform. It’s the layer that makes your platform usable, for people and for other agents.
In short: a Data Agent answers questions about your data, fast, with a chart if you need one. It plugs into Microsoft 365 Copilot, Copilot Studio, Foundry and any MCP client. And with ontologies, it starts to understand the language of your business.
Let’s go through it.
How it flows:
- Question: A user asks a question in Microsoft 365 Copilot, Teams, a Copilot Studio agent, a Foundry agent or any MCP client.
- Hand-off: The client passes the question to the published Data Agent.
- Context: If an ontology is attached, the agent uses it to understand the business terms.
- Query: The agent generates a SQL, DAX or KQL query and runs it against the right source, under the user’s permissions.
- Answer: The grounded answer goes back to the client, with a chart where supported.
1. It answers questions about YOUR data
Sounds obvious. But this is the key point.
A Data Agent doesn’t answer from the internet or from what a model “remembers”. It answers from the data you connect to it: lakehouses, warehouses, Power BI semantic models, KQL databases (including Eventhouse), mirrored databases, ontologies and even Microsoft Graph. Up to five sources per agent, in any combination.
Under the hood, it translates the question into a source-native query (SQL, DAX or KQL), runs it against the source and gives you the result. It’s strictly read-only. And it respects your security model: it uses the requesting user’s identity and permissions, row-level and column-level security stay in place, and Microsoft Purview policies still apply.
What makes the difference in practice: agent instructions, data source descriptions and example queries. That’s where you teach the agent how your data works. A Data Agent without instructions is like a new colleague without onboarding. Smart, but lost. (Small catch: example queries aren’t supported for Power BI semantic model sources yet. There, the model itself and the instructions do the work.)
And yes, it’s generally available. This is not a lab toy.
2. It dramatically shortens your time to answer
Think about the last ad-hoc question someone in your business asked. “How did returns develop in the south region after the price change?”
The classic way: the question becomes a request. Someone models the data, builds a report, reviews it, iterates. And the next question starts the whole cycle again.
With a Data Agent, the question is the starting point and the answer is one conversation away. The follow-up question? Same conversation.
To be clear: I’m not saying dashboards are dead 😄 Recurring KPIs, governed reporting, executive views: keep your dashboards. But for the long tail of ad-hoc questions, a Data Agent is simply faster. And it frees your BI team for the reports that really matter.
Two honest notes, so expectations are right:
- Insights, not exports: Data Agents are built for conversational insights, not for returning complete datasets. Chat responses are currently capped at 25 rows and 25 columns.
- English first: Non-English languages aren’t supported yet. For the best results, write questions, instructions and example queries in English.
3. It shows you the answer, not just tells you
Sometimes a number is enough. Often you want to see the trend.
Data Agents can return interactive charts next to the text and table answer. You can ask for one explicitly (“as a line chart”), implicitly (“show me sales by region”), or the agent decides that a visual helps, for example for a trend over time.
Supported today: line, column, stacked column, pie, scatter, area and stacked area charts, plus multi-line and multi-column variants. The visuals are built on Fabric Visuals, the same foundation used across the Fabric platform. You can steer them through agent instructions, for example “always show a trend as a line chart”.
Honest note: the rendered charts currently live in the Data Agent experience in Fabric, and they chart up to 200 rows. Other clients (SDK, Microsoft 365 Copilot, Teams, Foundry) don’t render them yet. But the chart specification (type, axes, aggregated data) is part of the run steps, so a client can rebuild the chart. And in Microsoft 365 Copilot, you can use code interpreter to build visuals from the agent’s results.
4. It’s the gate between Fabric and the rest of the Microsoft world
This is the point I find most underestimated.
You build the agent once, in Fabric, close to the data and governed with the data. Then you use it where people already work:
- Microsoft 365 Copilot and Teams: Publish it to the Agent Store. Users chat with it directly or @mention it in Copilot chat.
- Copilot Studio: Add it to a custom agent as a connected agent (preview). Your Copilot Studio agent handles the conversation and the workflow. The Data Agent brings the enterprise data. Today this setup is validated for Teams. A Copilot Studio agent with a connected Data Agent isn’t supported in Microsoft 365 Copilot yet.
- Microsoft Foundry: Add the Fabric IQ tool (preview) to your Foundry agent and pick your published Data Agent from the OneLake catalog. The Foundry agent delegates the data questions to Fabric. If you still use the older Fabric data agent tool in Foundry: Microsoft recommends migrating to the Fabric IQ tool. Your Data Agent itself stays the same.
The pattern behind it: the data team owns the data and the agent that knows it. App and agent teams consume it. No copies of data, no separate business logic re-built in every bot. That’s a clean separation of concerns, and a very good argument in any architecture discussion.
5. It speaks MCP, so it fits anywhere
When you publish a Data Agent, it becomes an MCP server that exposes a single tool: the agent itself. Any client that supports MCP over streamable HTTP and can attach a Fabric token can connect. VS Code with GitHub Copilot, a Python script, your own agent framework.
Get Karim Wahby’s stories in your inbox
Join Medium for free to get updates from this writer.
Two things I really like here:
- Description = contract: The description you write when you publish becomes the tool description. Clients read it to decide when to call your agent. So write it well: what the agent knows and which questions it can answer.
- No custom integration: No custom API, no wrapper. One protocol, many clients.
Practical notes: the MCP server doesn’t support dynamic client registration, so your client handles authentication and attaches the token itself. The token can be a user or a service principal, so unattended jobs work too. Long-running questions are covered as well: the server supports MCP tasks, so a client can pick up the answer later instead of holding the connection open. And bring your governance team in early. When you consume the agent from an external client (and the same applies to Copilot Studio and Microsoft 365 Copilot), responses might be processed outside Fabric’s compliance boundary, according to that client’s terms.
6. It can tap into ontologies, and that’s a whole new discussion
Here it gets really interesting.
A Fabric ontology (part of Fabric IQ, currently in preview) describes your business. Entities like Customer, Order, Store or Freezer. How they relate. Their definitions and synonyms. And how they map to the tables in OneLake.
Add an ontology to a Data Agent, and the agent uses that context to interpret the question, pick the right source and generate the right SQL, KQL or DAX query. The ontology provides the meaning. The source executes the query, under the user’s permissions. Your users ask in business terms. They don’t need to know table names, columns or joins.
Why this matters: for years, business context lived in people’s heads, in report names and in a wiki nobody updates. Semantic models helped for BI. Ontologies bring that context to agents: governed, reusable, built in Fabric. And the same ontology can also ground agents in Foundry.
That moves the conversation from “which tables do we have?” to “how does our business work, and how do our agents know it?”. That’s a data platform discussion, not just an AI one.
Getting started is not a six-month modeling project either. You can generate an ontology from a Power BI semantic model you already have in production, including its DAX measures as metrics. Or you use the ontology agent (preview), which builds a first draft from your workspace data in a chat experience.
Preview reality check: when the underlying source is a Power BI semantic model, the agent might not use all of the ontology context yet. Lakehouse, warehouse and KQL sources get the full benefit today. And ontology changes can take up to 10 minutes to reach the agent, unless you refresh the context manually.
So why are they underestimated?
My take, from customer conversations:
- Positioning: They’re seen as “a chat feature”, not as an integration layer.
- Expectations: People expect perfect answers out of the box, without investing in instructions and example queries.
- Ownership: Is it a BI topic, an AI topic or an app topic? Often it falls between teams.
Fix those three, and Data Agents become a core building block of your platform.
Getting started (the short version)
- Prerequisites: A paid F2 or higher capacity (or P1+ with Fabric enabled), the Data Agent tenant settings enabled (including cross-geo processing and storing for AI, where your region requires it), and the agent and its sources on capacities in the same region.
- Start small: One business domain, a few well-described sources.
- Teach it: Agent instructions, data source descriptions, example queries.
- Publish: With a clear and specific description. Remember, it becomes your tool description.
- Consume: Teams, Copilot Studio, Foundry or MCP. Go where your users are.
What’s next: Data Agents answer. Operations Agents act.
Data Agents answer when you ask. But what if an agent watched your data for you, and acted when something happened?
Remember the freezer question from the ontology example? Now imagine nobody has to ask it. An agent notices the humidity dropping, tells the store team in Teams and proposes the right action before anyone opens a chat.
That’s where operations agents come in. They’re part of Real-Time Intelligence and of Fabric IQ. They monitor an eventhouse or an ontology, generate a playbook with business concepts and monitoring rules, and message you in Teams when a condition is met. With a recommended action: a Teams message, a Fabric notebook or pipeline, or a Power Automate flow. You approve, the agent acts. And you can even configure them through a remote MCP server (preview).
In my next post, I’ll go from “ask and answer” to “observe and act”. Stay tuned.
Until then: if you’re already using Data Agents, or you tried them and gave up, I’d love to hear about it. Happy to exchange, reach out anytime.
Karim
Opinions are my own. Feature status as of November 2026. Fabric moves fast, so check the docs below for the latest.
Further reading
- Data agent as Model Context Protocol server
- Fabric data agent concepts
- Get visual responses from a Fabric data agent
- Use Ontology as context in Fabric data agent
- Consume a data agent in Microsoft Copilot Studio
- Consume a data agent from Microsoft 365 Copilot
- Connect agents to Microsoft Fabric with Fabric IQ (Foundry)
- Use the ontology agent
- What is Fabric IQ?
- Create and configure operations agents
- Remote MCP server for operations agents
