What a Fabric data agent actually is#

A Fabric data agent is a standalone, configurable artifact that lets you ask plain-language questions over governed Fabric data and get an answer back [S1]. It's easy to confuse with a Fabric Copilot, but they're built differently: Copilots are preconfigured, non-customizable helpers scoped to in-product tasks like generating notebook or warehouse code, while a data agent is an artifact you configure yourself and can be invoked by orchestrators outside Fabric entirely [S1]. Microsoft also frames it as a "virtual analyst" for a specific domain, grounded in your semantic models, and publishable to surfaces like Microsoft 365 and Copilot Studio [S4].

Fabric Data Agent architecture

What it can connect to, and what it can't do#

A single agent can attach up to five data sources, in any mix of lakehouses, warehouses, KQL databases, and Power BI semantic models [S1]. It stays read-only: the agent only ever generates SELECT-style read queries, never create, update, or delete statements, and it can't directly query unstructured files like PDFs unless those are first exposed as tables [S1]. Because it executes under the requesting user's own credentials, a question only ever surfaces data that user was already allowed to see [S1]. Responses are also capped at 25 rows and 25 columns, even across follow-up questions in the same chat — this is a conversational Q&A layer, not a bulk export tool [S1].

Configuring one#

Building or evaluating a data agent requires a paid F2-or-higher Fabric capacity (or Power BI Premium P1+ with Fabric enabled), plus a tenant-level switch an admin must separately enable: cross-geo processing and storing for AI [S2]. An agent's behavior then comes from four configuration surfaces: agent-level instructions, per-data-source instructions, data source descriptions, and example queries [S3]. Agent-level instructions sit above any one source — up to 15,000 characters of plain English — and set the agent's overall objective, a priority order across sources, and any domain terminology it would otherwise misread [S2] [S3]. Publishing keeps two versions side by side: an editable draft and a separately shareable published copy, so you can keep iterating without disrupting people using the live version [S2].

A worked example#

Say your team wants a Q&A agent over sales data. You attach a lakehouse and a Power BI semantic model, then write agent-level instructions to prefer the semantic model for revenue questions [S1] [S2] [S3]. A colleague asks "what were total sales last quarter by region" — the agent inherits their own permissions, generates a query against the semantic model, and returns a table capped at 25 rows [S1].

What goes wrong#

  • Expecting bulk data export. The 25x25 cap applies every time, even mid-conversation [S1].
  • Forgetting the tenant-level AI switch. Capacity alone isn't enough; cross-geo AI processing must be separately enabled [S2].
  • Assuming it's the same as Copilot. A data agent is a customizable artifact you build; a Copilot is a fixed, in-product assistant [S1].