Ask a Fabric data agent a plain-language question about your OneLake data, and it writes the SQL, DAX, or KQL behind the scenes and answers in seconds, no report-building required. It’s a generally available Microsoft product today, not a preview, and Microsoft Learn (2026) caps its default response at 25 rows and 25 columns, read-only throughout. How reliable that answer is comes down almost entirely to the semantic model behind it, the same dependency Snowflake’s Cortex Analyst and Databricks’ Genie carry for their own platforms, and Atlan, the context layer for AI agents, is built to keep that model’s metadata current across all three.
Atlan is the Context Layer for AI: it catalogs the same Fabric and Power BI assets a data agent queries, and keeps the ownership, certification, and quality signals behind those assets current no matter which platform they live on. That context reaches a Fabric data agent through OneLake itself, and it reaches agents on other platforms through Atlan’s MCP server. For a team running Fabric alongside Snowflake, Databricks, or a dozen SaaS systems, this is the difference between an agent that knows one platform’s definitions and one that knows the business’s.
- Fabric data agents are generally available and read-only across up to 5 OneLake data sources.
- Answer quality tracks semantic-model metadata quality, not model capability, per Microsoft’s own documentation.
- A September 2026 preview raises some responses to 1,000 rows; the GA default stays 25 rows and 25 columns.
- Atlan’s Fabric and Power BI connectors extend the same certified context beyond OneLake.
| Field | Value |
|---|---|
| What it is | A GA Fabric item that answers plain-language questions about OneLake data in SQL, DAX, or KQL |
| Status | Generally available, read-only. A September 2026 preview adds up to 1,000-row responses for some queries |
| Data sources supported | Up to 5, mixed: lakehouses, warehouses, KQL databases, Power BI semantic models, ontologies, Microsoft Graph |
| Core dependency | Semantic-model metadata quality (naming, relationships, measures), per Microsoft’s own documentation |
| Related but different | Fabric IQ (a separate, GA ontology and semantic-layer workload); Database Hub’s agents (pre-GA); operations agents (GA, rule-based) |
| Minimum access | Read permission on the semantic model; F2+ Fabric capacity or Power BI Premium P1+ |
What is a Microsoft Fabric data agent?
A Microsoft Fabric data agent is a generally available Fabric item that lets people ask plain-language questions about data in OneLake and get an answer back in seconds. According to Microsoft Learn’s concept guide (Microsoft Learn, 2026), Microsoft calls it “the conversational analytics component” in multi-agent solutions built on Fabric.
Each agent can draw on up to five data sources in any combination, mixing lakehouses, warehouses, KQL databases, Power BI semantic models, ontologies, and Microsoft Graph (Microsoft Learn, 2026). The access bar is deliberately low. Per Microsoft’s setup guide (Microsoft Learn, 2026), querying through a data agent needs only Read permission on the semantic model, no workspace role or Build permission, on an F2 or higher Fabric capacity or Power BI Premium P1 or higher.
A Fabric data agent is one of three distinct agent types on the platform (Azure Blog, 2026; Azure Blog, 2026): the data agent answers questions, Database Hub’s agent layer watches operational databases, and the operations agent monitors live data and acts on rules. The naming overlap confuses people more than it confuses Microsoft, and the Fabric data agent vs. database agent comparison breaks down all three in full. It’s also a different product from Fabric IQ, the newer ontology and semantic-layer workload. A data agent can use an ontology as one of its five sources, but the two products ship, document, and update on separate timelines.
Every answer a data agent gives comes from data that lives in OneLake, Fabric’s single logical data lake, and the quality of that answer traces back to how well that data is modeled, which the next section covers in full.
How does a Fabric data agent turn a question into an answer?
A Fabric data agent turns your question into a query through a fixed pipeline: Azure OpenAI Assistant APIs pick a data source, select a tool, and generate SQL, DAX, or KQL, then return a capped number of rows designed for conversational reading rather than data export. The cap itself has two different answers right now, GA and preview, and getting that distinction right matters more than it sounds.
How a data agent picks a tool and writes a query
Azure OpenAI Assistant APIs choose a data source for your question and call the matching tool: NL2SQL for lakehouses and warehouses, NL2DAX for Power BI semantic models, the same mechanism behind conversational analytics on Power BI more broadly, NL2KQL for KQL databases, plus a path through Microsoft Graph (Microsoft Learn, 2026). This is text-to-SQL for enterprise data extended to two more query languages, and where text-to-SQL breaks in practice applies just as directly to NL2DAX and NL2KQL. The tool-selection step follows the same pattern documented in Microsoft Semantic Kernel and the talk-to-data agent blueprint most conversational analytics products share.
The response cap: GA default vs. the September 2026 preview
By default, every Fabric data agent caps its response at 25 rows and 25 columns. Microsoft Learn (updated 2026-09-29) is explicit about why: the limit is “designed for conversational insights rather than for returning complete datasets,” not a technical ceiling Microsoft is racing to lift.
A September 2026 preview changes one specific slice of that picture. According to Microsoft Fabric’s “What’s new” page (Microsoft Learn, 2026), Fabric data agents can now return up to 1,000 rows for some queries, a preview feature meant for downstream analysis rather than a chat reply, distinct from the data agent’s separate standard-vs-preview runtime track (Microsoft Learn, 2026). That expansion is opt-in and still in preview, and it does not change the default, generally available behavior every other data agent still follows.
| Aspect | Default GA behavior | September 2026 preview |
|---|---|---|
| Response cap | 25 rows / 25 columns | Up to 1,000 rows for some queries |
| Availability | GA, every data agent | Opt-in, preview only |
| Intended use | Conversational insight | Downstream analysis of larger result sets |
| Is this the current default? | Yes | No, still a preview |
If your data agent still returns 25 rows, that’s the product working as designed, not a bug waiting on a fix.
Permissions and policy enforcement
Access stays narrow by default. Per Microsoft’s setup guide (Microsoft Learn, 2026), using a data agent against a semantic model needs Read permission only, no workspace role and no Build permission, and every query runs with the asking user’s own credentials so Microsoft Purview policies still apply. A data agent inherits the access the person already has. It doesn’t grant new access.
A Fabric data agent's answer traces back through the semantic model to OneLake data. Context from outside Fabric only reaches that model through a layer built to carry it there.
Why does a Fabric data agent give a wrong or misleading answer?
Wrong answers from a Fabric data agent almost always trace back to the semantic model, not the underlying AI model, a finding Microsoft documents in its own words and three independent practitioners confirm separately.
Microsoft’s semantic-model best-practices page (Microsoft Learn, updated 2026-09-01) states plainly that “poor data agent performance often comes from a poorly designed semantic model, inefficient DAX measures, or a mix of the two.” The mechanism is specific: the DAX generation tool relies entirely on your model’s metadata to interpret a question, so, in the same source’s words, “ambiguous names can lead to incorrect query generation.” A column named CustID in one table and CustomerID in another doesn’t confuse a person reading both tables side by side. It can send a data agent down the wrong join entirely.
This isn’t one blogger’s theory. At FabCon Europe 2026, Arthur Graus, Power BI and Microsoft Fabric trainer, consultant, and developer, put it directly: “AI is only as good as the semantic model behind it.” Mirko Peters, founder of m365.fm (m365.fm, 2025), reaches the same conclusion from a different angle: “Copilot is not an oracle. It has no epistemology, no concept of truth, only mirrors built from your metadata.” A BI consultancy covering the data agent’s GA launch (Blue Margin, 2026) lands on the same verdict from a third, unrelated direction: “AI accuracy is a data problem before it is an AI problem.” And on Microsoft’s own community forum, a thread titled “Data Agent fails to query Ontology” (Microsoft Fabric Community, 2026) shows the failure happening in production, not just in theory.
Across these sources, the same five patterns keep showing up:
| Failure pattern | Why it breaks a data agent |
|---|---|
| Inconsistent naming (e.g. “CustomerID” vs. “CustID”) | The DAX/SQL generator matches on metadata labels, not meaning; a mismatch misroutes the query |
| Missing relationships between tables | The agent can’t join what the model doesn’t define, so it guesses or fails |
| Ambiguous date fields | Multiple candidate date columns with no clear role produce the wrong time window |
| Duplicate or overlapping measures | The agent can’t tell which measure is authoritative and may pick either |
| Instructions lost via Copilot Studio | Copilot Studio can rewrite or shorten prompts before they reach the data agent, dropping context |
None of this indicts the data agent. It confirms that the types of metadata AI agents need are the same wherever the agent runs, and the gap between a Power BI semantic model and a dedicated semantic layer for AI agents is exactly this: a semantic layer built for AI agents has to carry more than a BI tool’s measures, because an agent asks more of it than a report ever did.
Where Fabric data agents show up today
A Fabric data agent shows up wherever someone needs a quick, read-only answer, not as a destination of its own. Arun Ulag, Executive Vice President of Azure Data at Microsoft, described the whole category simply: “Fabric data agents can be thought of as virtual analysts” (Azure Blog, 2026).
In practice, that shows up in four places:
- Self-service Q&A for business users querying modeled Fabric data directly.
- A tool inside Copilot Studio agents: per Microsoft Learn’s “What’s new” (Microsoft Learn, 2026), a data agent can now be added as a Fabric IQ Data MCP tool.
- A surface inside Microsoft 365 Copilot and Teams.
- A callable item from Microsoft Foundry agents, which can invoke a Fabric data agent the same way they’d call any other tool.
Each surface reuses the same agent and the same semantic model, which is precisely why the model’s quality matters everywhere the agent shows up, not just in one interface.
Does the metadata problem stop at Fabric’s edge?
A Fabric data agent’s query-generation step runs entirely on metadata that lives inside Fabric and OneLake, and for most enterprises, that’s not where all their metadata lives.
Per Microsoft’s own documentation, a data agent has no mechanism to inherit certified definitions, ownership, or quality signals from outside Fabric. It reads the semantic model you built inside Fabric, and nothing else. That’s not a flaw. It’s an architectural boundary, the same one Snowflake’s Cortex Analyst and Databricks’ Genie draw around their own platforms, and the same shape as where Microsoft Purview’s own governance coverage stops at Fabric’s edge. Cortex Analyst’s accuracy against custom text-to-SQL depends on the same thing a Fabric data agent’s does: the semantic layer it was given, not the model underneath it. What OpenAI’s own data agent reveals about enterprise AI tells the identical story at a third vendor. Three independent platforms, one architecture: the agent is as good as the metadata inside its box, and nothing outside the box reaches it on its own.
Most enterprises don’t run on one box. A retailer might model customer data in Snowflake, run marketing in Salesforce, and query Fabric for everything else, each platform with its own name for “customer” and its own idea of which measure is the real one. AI agent accuracy is a context and governance problem, not a model-quality problem, and that’s as true across three platforms as it is inside one semantic model.
To be fair to Microsoft, this gap is narrowing for Fabric-native estates. Fabric IQ’s ontology, the September 2026 ontology-as-context preview, and Microsoft’s push toward shared capabilities across Microsoft experiences all point toward Microsoft building its own unifying context layer inside Fabric. That’s real progress, and it isn’t a fix for the multi-platform reality. A semantic layer that spans only one vendor’s stack will always leave a gap for the Snowflake table, the Databricks notebook, and the Salesforce record that sit outside it. That gap, open across every platform a Fabric data agent can’t see into, is exactly what a cross-platform context layer, including Atlan, is built to close, a case the next two sections make directly.
What to check before you trust a Fabric data agent’s answers
Before you let a Fabric data agent answer for your team, or any conversational agent built the same way, six checks separate a trustworthy deployment from a confidently wrong one.
| Criterion | Why it matters | What to check |
|---|---|---|
| Naming consistency across the semantic model | Mismatched labels misroute NL2SQL/NL2DAX queries | Are column and table names standardized, with no duplicate-meaning labels? |
| Defined relationships between tables | The agent can’t join what isn’t modeled | Are all relevant table relationships explicit in the semantic model? |
| Deduplicated, unambiguous measures | Overlapping measures produce inconsistent answers | Is there one authoritative measure per metric, not several candidates? |
| Ownership and certification on the underlying data | An agent can’t flag what it doesn’t know is stale or unowned | Does every source feeding the data agent have a named owner and a certification status? |
| Context coverage beyond Fabric | A data agent only sees what’s modeled inside Fabric and OneLake | Do definitions used elsewhere, in Snowflake, Databricks, or Salesforce, match what the Fabric semantic model says? |
| Governance and access scope | Read-only enforcement doesn’t substitute for access review | Have you confirmed what the asking user’s own permissions expose through the agent? |
The first four checks are what Microsoft’s own prep-for-AI guidance (Microsoft Learn, 2026) already asks of any team building a semantic model for Copilot or a data agent. They’re AI-ready data basics, and an AI-ready data checklist will walk you through most of them. Microsoft’s Fabric governance and Purview’s controls for AI agents cover the sixth, and the questions worth asking before trusting Fabric’s agents go deeper on ownership and audit. A data agent’s read-only posture is only half that picture. Fabric’s third agent type, the rule-based operations agent that reached GA in mid-2026 (Enterprise DNA, 2026), can act on live data directly, so don’t assume every Fabric agent shares the data agent’s read-only ceiling.
The fifth check is the one most checklists skip, because it points outside the platform you’re auditing. Microsoft is closing part of this specific check itself for Fabric-only estates, through Fabric IQ’s ontology and the ontology-as-context preview; the check still matters wherever your estate extends past OneLake. Who actually governs a Fabric item an agent created, not a person, and whether a governance platform evaluated for Fabric reaches past OneLake, are the two questions that decide whether this checklist, run once, stays true.
How Atlan extends context to Fabric data agents, and beyond
A Fabric data agent is only as good as the metadata inside Fabric and OneLake, and most enterprises keep context worth having in Snowflake, Databricks, Salesforce, and a dozen SaaS systems besides, none of it reachable by a data agent on its own. Microsoft is narrowing part of that gap natively, through Fabric IQ’s ontology and the ontology-as-context preview, and that native work keeps mattering for a Fabric-only estate.
Atlan is the Context Layer for AI: it sits above Fabric and OneLake, extending what Fabric IQ already does inside Fabric to the platforms Fabric IQ doesn’t reach, not instead of them. Atlan catalogs Fabric and Power BI assets, including semantic models, reports, and lineage, and builds a context graph around them that holds ownership, certification, and quality signals in one place. Atlan’s Fabric and Power BI connectors read this context only; they don’t write access changes back to either system. That governed context lives in Atlan’s Context Lakehouse as open Apache Iceberg tables, exposed into OneLake as zero-copy shortcuts, so Fabric compute, and a Fabric data agent with it, can query the same context without a separate copy. A second path runs through Atlan’s MCP server, which exposes definitions, lineage, certification, and policy context directly to any agent that asks, Fabric’s included. Fabric IQ and Fabric data agents handle Microsoft-native context well. Atlan extends the same certified definitions to the agents and people working anywhere else in your enterprise context layer too.
No public case study isolates a Fabric data agent’s accuracy with Atlan’s context added; that specific measurement doesn’t exist yet. What does exist is general, Atlan-wide evidence for the pattern: according to Atlan’s AI Labs benchmark, adding context improved text-to-SQL accuracy by 38% across the agents it was tested on. Read that as evidence the pattern holds, not as a measured result for a Fabric data agent specifically.
Fabric also ships its own MCP surface, and what Fabric’s own MCP servers actually let an agent do is a useful comparison point for teams deciding which protocol handles which job. For teams running Purview alongside a cross-platform layer, Microsoft Purview’s Unified Catalog and Atlan’s context graph answer different questions: native Microsoft governance versus context that spans every platform. And because lineage is the piece teams verify first, proving Fabric and Power BI lineage in a proof of value and which tools support end-to-end Power BI column-level lineage are worth reading before you take any lineage claim, Atlan’s included, at face value.
A Fabric data agent is only as good as the context behind it
Every source gathered for this topic, Microsoft’s own documentation, independent practitioners, and the identical pattern repeating at Snowflake and Databricks, agrees on the same shape: Fabric data agents are a real, generally available, well-engineered product that Microsoft keeps extending, not something to route around. The gap isn’t that the agent is unreliable. It’s that the agent only ever sees what’s been modeled inside Fabric and OneLake, and most enterprises have context worth having in more places than that.
Microsoft is closing part of this gap itself, inside Fabric, with Fabric IQ’s ontology and the ontology-as-context preview. For a pure-Fabric estate, that’s real progress and worth tracking. For the multi-platform estate most enterprises actually run, context engineering that spans Fabric, Snowflake, Databricks, and everything else is still the only way an agent anywhere sees the same certified definition your analysts already trust. How to build an AI agent harness and how to implement an enterprise context layer for AI are the next two steps for a team ready to act on that.
Does your organization know what’s actually inside the semantic model a Fabric data agent reads from today, and does that same definition hold true in Snowflake or Databricks too?
FAQs about Microsoft Fabric data agents
1. What is a Microsoft Fabric data agent?
A Microsoft Fabric data agent is a generally available, read-only Fabric item that answers plain-language questions about data in OneLake. It turns a question into SQL, DAX, or KQL depending on the data source, and returns an answer capped at 25 rows and 25 columns by default.
2. Are Microsoft Fabric data agents generally available?
Yes. Microsoft’s documentation lists the Fabric data agent as generally available, not preview. A separate September 2026 preview feature expands some responses to up to 1,000 rows, but that preview feature sits on top of a GA product, not in place of it.
3. How does a Fabric data agent answer a question in plain English?
Azure OpenAI Assistant APIs select a data source for the question and call a matching tool: NL2SQL for lakehouses and warehouses, NL2DAX for Power BI semantic models, or NL2KQL for KQL databases. The tool writes the query, runs it, and returns a conversational answer.
4. Can a Fabric data agent create, update, or delete data?
No. A Fabric data agent only generates read queries and keeps read-only connections to every data source it touches. It cannot create, update, or delete data, and it does not trigger write workflows like notebooks or pipelines.
5. What is the difference between a Fabric data agent and Microsoft 365 Copilot?
A Fabric data agent is a configurable Fabric item built for Q&A over specific OneLake data sources you choose. Microsoft 365 Copilot is a broader assistant across Microsoft 365 apps that can call a Fabric data agent as one of its tools, rather than replacing it.
6. Why would a Fabric data agent give a wrong or misleading answer?
Most wrong answers trace back to the semantic model, not the AI model. Inconsistent column naming, missing table relationships, ambiguous date fields, and duplicate measures all cause a data agent to misread what a question is actually asking for.
7. Does a Fabric data agent need a Power BI semantic model to work?
Not always. A data agent can query lakehouses, warehouses, and KQL databases directly through NL2SQL and NL2KQL. A Power BI semantic model becomes necessary only when the question needs NL2DAX, the tool that reads measures and relationships defined in that model.
8. Is a Fabric data agent the same thing as Fabric IQ?
No. A Fabric data agent is a conversational Q&A item, while Fabric IQ is a separate workload built around an ontology and a Power BI semantic model that gives agents a shared business vocabulary. A data agent can use an ontology as one of its data sources, but the two products ship and update separately.
Sources
- Fabric data agent creation (concept), Microsoft Learn
- Create a Fabric data agent, Microsoft Learn
- Semantic model best practices for data agent, Microsoft Learn
- What’s new in Microsoft Fabric, Microsoft Learn
- FabCon and SQLCon 2026: Unifying databases and Fabric on a single data platform, Azure Blog
- Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases, Azure Blog
- Fabric data agent runtime, Microsoft Learn
- Prep your data for Copilot and AI features in Power BI, Microsoft Learn
- Arthur Graus, “Fabric Data Agents: Building AI-Ready Semantic Models,” FabCon Europe 2026, Sessionize
- Your Fabric data model is lying to Copilot, m365.fm
- The Fabric Data Agent Goes GA, Blue Margin
- Data Agent fails to query Ontology, Microsoft Fabric Community
- Microsoft Fabric July 2026: Operations agents reach GA, Enterprise DNA
