"Does Fabric have AI?" is a question I get asked a lot, usually by someone who's already decided the answer matters for a platform decision, and it's almost always underspecified. Do they mean AI that helps a developer build a dataflow faster? Or AI that lets a VP ask a plain-English question and get a real answer without opening Fabric at all? Those are different products solving different problems, built by different teams inside Microsoft, shipping on different timelines — and conflating them is how you end up either overselling or underselling what's actually there when someone asks you to evaluate the platform.
I wrote about AI authoring Power BI reports — agents writing PBIR and TMDL directly through a Copilot CLI plugin — as its own narrow piece, because report authoring is a specific, code-shaped problem with a specific tool built for it. This article is the rest of the platform's AI surface: the assistant embedded in every workload for the person building the pipeline, the conversational agent for the person who never opens Fabric's authoring tools, and the AI calls a data engineer can drop straight into a Spark transformation.
What's the actual difference between "Copilot in Fabric" and "Fabric Data Agent"?
Copilot in Fabric is AI assisting the builder — someone already working inside a specific Fabric experience who wants help doing that job faster. It isn't one feature; it's a set of copilots embedded per workload: a copilot in the notebook experience that generates and explains PySpark or Spark SQL, a copilot in Data Factory that helps construct dataflows, a Data Science workload copilot, and the Power BI copilot for report and DAX assistance. Each one is scoped to the surface it lives in and speaks that surface's language.
Fabric Data Agent is a different thing entirely: a generative-AI-powered conversational Q&A system that answers plain-English business questions grounded in real data, for someone who may never log into Fabric's authoring UI in their life. It's a GA capability as of mid-2026 (evolved from an earlier concept Microsoft called "AI Skill"), and its job is to sit between a business question and Fabric's data estate, translate the question into the right query against the right source, and hand back an answer — not a notebook, not a DAX formula, an answer.
The practical test I use: if the AI is helping someone write something — code, a dataflow, a report — that's Copilot. If the AI is answering something for someone who isn't going to look at how it got the answer, that's a Data Agent. Most "does Fabric have AI" conversations get muddled because people use "Copilot" as a catch-all for both.
graph TD
subgraph BUILDERS["Builder side: Copilot in Fabric"]
NB["Notebook copilot
PySpark / Spark SQL generation"]
DF["Data Factory copilot
dataflow construction"]
DS["Data Science copilot"]
PBI["Power BI copilot
report / DAX assistance"]
end
subgraph CORE["OneLake + semantic layer"]
LH["Lakehouse"]
WH["Warehouse"]
SM["Power BI semantic model"]
EH["Eventhouse (KQL)"]
SQLDB["SQL DB / mirrored DB"]
GRAPH["Microsoft Graph"]
end
subgraph CONSUMERS["Consumer side: Fabric Data Agent"]
DA["Fabric Data Agent
conversational Q&A"]
end
subgraph DIST["Publish-everywhere distribution"]
M365["Microsoft 365 Copilot
declarative agent"]
CS["Copilot Studio
multi-agent orchestration"]
MCP["MCP-based agent frameworks
custom integration"]
end
NB --> CORE
DF --> CORE
DS --> CORE
PBI --> SM
CORE --> DA
DA --> M365
DA --> CS
DA --> MCP
Two sides of the same platform: Copilot helps whoever is already building inside a Fabric workload, while the Data Agent sits on top of OneLake and the semantic layer to answer whoever isn't. The Data Agent's distribution fan-out into M365 Copilot, Copilot Studio, and MCP is what gets it in front of people who never touch Fabric directly.
Why is spanning that many source types the genuinely hard part?
A Fabric Data Agent can connect to Lakehouses, Warehouses, Power BI semantic models, Eventhouse (KQL databases), SQL databases, mirrored databases, ontologies, and Microsoft Graph — up to several sources at once, feeding a single conversational surface. That breadth is the part worth taking seriously, because most "chat with your data" tools on the market handle exactly one shape of data well: a warehouse-flavored tool is good at SQL-shaped questions, a BI-flavored tool is good at questions that map cleanly onto an existing semantic model, and neither is built to also reach into real-time event data sitting in a KQL database.
Getting that right architecturally means the Data Agent has to decide, per question, which connected source actually holds the answer, generate a query in that source's native query language, and reconcile results that might come back in genuinely different shapes — a semantic model's pre-aggregated business metric versus a raw KQL event stream versus a warehouse table with none of the business logic a semantic model would have baked in. That's a harder routing and grounding problem than single-source Q&A, and it's the legitimate differentiator here versus a narrower point tool.
A Data Agent is only as trustworthy as the semantic model or metadata it's grounded in — and its failure mode is more convincing than a bad dashboard's. This is the same "garbage in, garbage out" lesson BI has always taught, just wearing a more persuasive costume. A badly-modeled warehouse with ambiguous column names, no documented business logic, and stale relationships will produce a Data Agent that answers confidently and wrong, in fluent English, with no visual cue that anything's off — unlike a broken dashboard, which at least looks broken. If you're rolling this out, the actual prerequisite work is curating the semantic model and the agent/data-source instructions it's grounded in, not just flipping the feature on. Treat semantic-model quality as a launch blocker, not a nice-to-have you'll circle back to.
Why does publishing the Data Agent into M365 Copilot and Copilot Studio matter more than the Fabric-native chat experience?
A Fabric Data Agent isn't trapped inside the Fabric web portal — it can be published as a declarative agent into Microsoft 365 Copilot, so someone asks a data question inside the Microsoft 365 chat surface they already live in, and it can be added as a connected agent inside Copilot Studio for multi-agent orchestration, where a custom Copilot Studio agent calls the Fabric data agent to reason over the org's Fabric data estate without an engineering team building a bespoke integration for every data-heavy ask. There's also a path through MCP-based agent frameworks for teams building custom integrations — a Fabric Data Agent exposed this way is a concrete, production instance of the tool-connection pattern I covered generally in building MCP servers and MCP vs. Agent Skills.
That distribution story matters more than the quality of Fabric's own chat UI, honestly, because most people in a given org never log into Fabric directly and never will. A Data Agent that only answers questions inside the Fabric portal reaches analysts. A Data Agent published into M365 Copilot reaches everyone who already uses Outlook or Teams, which in a typical enterprise is the entire company. The distribution surface is the adoption lever, not the model quality.
Recent platform improvements worth knowing about
| Improvement | Why it matters |
|---|---|
| Service principal support | Agents can authenticate as an app identity instead of requiring a delegated user's credentials — unlocks backend and automated integration scenarios that a human-in-the-loop auth model couldn't support |
| Long-running query handling | Complex questions that take real time to resolve no longer silently time out or drop — a genuine reliability fix, not a cosmetic one, for anything beyond trivial lookups |
| AI-assisted Data Agent setup | A guided configuration flow addressing a real confusion point: agent instructions vs. data-source instructions vs. example queries were easy to misconfigure and hard to debug |
What are AI Functions, and how are they different from both Copilot and the Data Agent?
AI Functions are embedded LLM calls usable directly against Spark dataframes and columns inside a notebook — classify, translate, summarize, extract-entities, and similar operations exposed as function calls over a column, without a data engineer hand-writing the prompt orchestration, retry logic, and response parsing themselves. This is a third, distinct thing from either builder-assist Copilot or the consumer-facing Data Agent: there's no chat interface involved at all. It's an LLM call sitting inline in a pipeline, the same way a `UPPER()` or `REGEXP_EXTRACT()` call would sit inline in a transformation, except the "function" happens to be backed by a model instead of deterministic logic.
# conceptual shape of an AI Function call against a Spark dataframe column
from synapse.ml.services.openai import AIFunctions
classified_df = AIFunctions.classify(
df,
input_col="support_ticket_text",
categories=["billing", "technical", "account", "other"],
output_col="ticket_category"
)
summarized_df = AIFunctions.summarize(
classified_df,
input_col="support_ticket_text",
output_col="ticket_summary"
)The engineering trade-off here is the one you'd expect with any LLM call embedded in a batch pipeline: it's non-deterministic, it's slower and more expensive per row than a deterministic function, and it needs the same evaluation discipline you'd apply to any other AI Function in production — spot-check output quality, don't assume a classify call is as reliable as a lookup join just because it's one line of code. But for the specific class of problem it targets — unstructured text needing rough categorization, translation, or summarization at pipeline scale — it removes a real amount of prompt-orchestration boilerplate a data engineer would otherwise write by hand.
What's the governance question nobody should skip?
Exposing a natural-language Q&A agent over OneLake data multiplies the ways sensitive data can leak through an answer nobody expected. A well-designed row-level security rule on a Warehouse table or an object-level permission on a semantic model was already doing real work before any of this — a Data Agent sitting on top of that layer inherits whatever the underlying security model actually enforces, for better or worse. If the semantic model's security is correct, the Data Agent is safe by construction. If it isn't, the Data Agent is now the fastest, most convincing way for the wrong person to find that out.
The service-principal auth improvement is relevant here for a reason beyond convenience: "who is this agent allowed to see data as" stops being an afterthought and becomes an explicit identity decision the moment you're running agents as automated app identities rather than a logged-in human. That's a real access-control question that deserves the same rigor as any other service-account provisioning decision — least privilege, scoped roles, regular review — not a checkbox you tick once during setup and forget.
None of this is new territory conceptually — it's the same access-control discipline BI teams have needed since row-level security existed in any semantic layer — but a Data Agent changes the blast radius. A misconfigured RLS rule on a dashboard produces a wrong number on a chart someone might notice. The same misconfiguration behind a Data Agent produces a fluent, specific, wrong answer to a question someone asked in good faith, with nothing about the delivery format hinting that it might be wrong.
What to carry away
Fabric's AI story in 2026 isn't one feature, it's three, and they don't compete with each other: Copilot helps the builder inside whichever workload they're already in, the Fabric Data Agent answers the consumer who never opens Fabric at all, and AI Functions embed model calls inline in the data engineering pipeline itself. The Data Agent's multi-source reach across Lakehouse, Warehouse, semantic model, Eventhouse, and Graph is the genuinely hard architectural achievement here, and its publish-everywhere distribution into M365 Copilot and Copilot Studio is what actually drives adoption, more than any improvement to the in-Fabric chat experience. None of it replaces the unglamorous discipline BI has always needed — a well-modeled semantic layer with correct security — it just raises the cost of skipping that discipline, because a bad answer from a Data Agent looks exactly as confident as a good one.