Agents in Microsoft Fabric for data engineers

Where each level lives in Fabric

The levels from Part 1 map onto Fabric like this:

Level	Fabric feature	Status in the docs
2. Assistant in your tool	Copilot in notebooks	Preview
2. Assistant in your tool	Copilot in Data Factory (Dataflow Gen2, pipelines)	See the docs
4. Configured agent	Fabric data agent	Generally available
4 and 10. Configured, monitoring	Operations agent for pipelines	Preview
7 and 8. Agent loop with shared tools	A coding agent on a Git-connected workspace, with the Fabric MCP server	MCP server: check the repository
9. Multi-agent	A data agent called by an orchestrator (Copilot Studio, Azure AI Foundry, Teams, Microsoft 365 Copilot)	See the docs

Before you start: tenant, capacity and cost

Prerequisites (from the Microsoft documentation):

The tenant setting Users can use Copilot and other features powered by Azure OpenAI must be on. It is enabled by default, but admins may have turned it off.
A paid capacity: F2 or higher, or Power BI Premium P1 or higher.
If your capacity is outside the US or EU, an admin must also enable the cross-geo processing setting for data sent to Azure OpenAI.
Data agents need at least one source with data that you can read, plus the data agent tenant settings.

Cost is capacity, and it is measurable. Copilot requests consume Capacity Units, metered by tokens. At the published rates (subject to change) one 1,000-token block costs:

	CU seconds per 1,000 tokens
Input prompt	100
Cached input prompt	10
Output completion	400

The documentation’s own example: a request with 2,000 input and 500 output tokens costs (2,000 × 100 + 500 × 400) / 1,000 = 400 CU seconds. Copilot operations are classed as background jobs, so Fabric smooths their usage over 24 hours.

Usage shows in the Fabric Capacity Metrics app under the operation name Copilot in Fabric. Microsoft’s advice is to roll out in a small pilot group first, measure each scenario in the Metrics app, and extrapolate before scaling. That is good practice for any agent feature. Check separately how data agent usage is metered on your capacity.

1. Notebooks with Copilot

Copilot in notebooks knows your workspace, the attached lakehouse, its schemas, tables and files, the notebook’s structure, and recent run telemetry such as data sizes and join behaviour. You do not describe your setup. It works in two ways:

Chat pane for multi-step work. It can generate and refactor across several cells and shows an approval diff before applying changes.
In-cell Copilot for focused edits: /explain, /fix, /comments and /optimize.

When a cell or Spark job fails, Fix with Copilot appears under the cell with an error summary, a likely root cause and a proposed fix.

Example questions from the documentation: “How many tables are in the lakehouse?”, “What are the columns of the table customers?”, “Create a dataframe from sales.csv.”

A realistic engineering prompt for a medallion task:

Read bronze_orders. Keep only the latest record per order_id by _ingested_at.
Write the result to silver_orders as a Delta table, and add a cell that checks
for duplicate order_ids afterwards.

The kind of output to expect and review (illustrative):

from pyspark.sql import functions as F, Window

latest = Window.partitionBy("order_id").orderBy(F.col("_ingested_at").desc())

silver = (
    spark.table("bronze_orders")
    .withColumn("rn", F.row_number().over(latest))
    .filter("rn = 1")
    .drop("rn")
)
silver.write.mode("overwrite").format("delta").saveAsTable("silver_orders")

What to check every time: the deduplication key and tie-breaker, whether overwrite is what you want or you need an incremental merge, how nulls and schema changes are handled, and whether the check cell really tests what the prompt asked.

Limits to know: the experience is optimised for lakehouse scenarios, so name other sources explicitly in the prompt. Code for fast-moving libraries may contain mistakes or invented functions. The chat pane does not work if your tenant uses private link. Keep the default setting that asks for approval before running cells or editing code.

2. Data Factory: Dataflow Gen2 and pipelines

Copilot in Data Factory covers two components.

Component	What Copilot can do
Dataflow Gen2	Get data from sources by description, generate transformation steps for a query, summarise a query and its steps, create a new query (with sample data if needed), undo the last step. It produces Power Query M code
Pipelines	Generate a pipeline from a description, explain error messages with troubleshooting steps, summarise a pipeline, build and explain expressions

Prompts from the documentation: “Only keep European customers”, “Count the total number of employees by City”, “Explain my current query”, “Create a pipeline to copy data from SQL Server to Azure Data Lake”, “Summarize this pipeline”.

Limits worth planning around: it cannot transform or explain across several queries in one request, it cannot undo changes after you commit them, it cannot change query layout, and for unsupported requests it may fail without an error message. Copilot in Data Factory needs a paid capacity.

Use it as a scaffolding accelerator. Review the Applied steps list every time, and keep the result in Git like any other item.

3. Pipeline operations: the operations agent (preview)

This is the closest Fabric feature to an autonomous agent. The operations agent for pipelines analyses pipeline runs, logs and performance signals, and works in a loop the documentation describes as observe, analyze, recommend, act.

Create it from the Home ribbon on the pipeline canvas, and choose whether it watches the current pipeline or all pipelines in the workspace.
It uses pipeline execution logs, activity metadata and runtime signals. It produces root cause analysis, bottleneck detection and optimisation recommendations, and sends insights through Teams after you press Start.
From the Monitoring hub, select a failed run and choose Investigate to get the failed activity, a likely root cause and next steps.
You can edit the agent’s instructions, which act as its playbook, and extend it with actions.

Currently it supports health monitoring scenarios only. A sensible way to adopt it: start with Investigate on real failures, compare its diagnosis with what you find yourself for a few weeks, and only then let it send proactive alerts. Treat it as triage, not as automatic repair.

4. A coding agent on a Fabric workspace repository

For code-heavy work, the pattern with the best return is a coding agent working on a branch, with CI and a human as the gates. Fabric’s Git integration makes that possible, because it stores workspace items as files in a repository.

What Git integration supports (from the documentation):

Providers: Azure DevOps and GitHub (including GitHub Enterprise), cloud-based only. Integration is at workspace level and preserves the folder structure.
Items include notebooks, lakehouses, Spark job definitions, pipelines, Dataflow Gen2, warehouses, environments, and data agents, with some items such as dbt jobs and the operations agent in preview.
Unsupported items can stay in a connected workspace, but they are ignored and not synced.

The workflow:

Each developer works in a development workspace connected to a feature branch.
A coding agent edits notebook and pipeline files in the repository on that branch (level 7). It never has credentials for production.
A pull request runs checks, such as linting, tests and a review of the diff.
A human merges. Fabric deployment pipelines promote the items from development to test to production.

Item definitions are structured files, so let the agent change the code inside them and verify by syncing into a development workspace, rather than trusting the diff alone.

The Fabric MCP server gives such an agent knowledge of Fabric and, optionally, the means to act. It is local-first and has four toolsets:

Toolset	What it covers
`docs`	API specifications, item definitions, best practices, examples (bundled, no live connection)
`core`	Workspaces, items, capacities, catalog, long-running operations
`onelake`	Files, tables, shortcuts, data access roles
`datafactory`	Pipelines and Dataflow Gen2, including running them

Configuration for any MCP-capable client (needs Node.js 22 or later):

{
  "mcpServers": {
    "fabric-mcp-server": {
      "command": "npx",
      "args": ["-y", "@microsoft/fabric-mcp@latest", "server", "start", "--mode", "all"]
    }
  }
}

The documentation tools never touch your tenant. The operational tools act under the identity you configure, so use a dedicated identity with the least access that works. A Docker container does not reuse your az login session, so it needs a service principal whose secrets are kept outside the repository.

Prompts that suit this setup (illustrative):

Using the Fabric docs tools, show me the item definition for a notebook and
the required API fields, then draft the call that creates one in workspace X.

List the shortcuts in the lakehouse bronze_lh and tell me which ones point to
storage outside OneLake. Do not change anything.

Good tasks for an agent here: refactoring a long notebook into functions, adding docstrings and tests, generating documentation from item definitions, and reviewing a pull request for patterns such as collect() on large data or joins without a key. Start with read-only requests, and let it create or change items only in a development workspace.

5. Fabric data agents for business questions

A Fabric data agent is the configured agent for analysts. It routes each question to the right source, writes SQL, DAX or KQL, validates and runs the query, and answers in plain language. It is read-only and runs with the asking user’s identity: you do not supply an Azure OpenAI key, and Purview policies apply.

Set-up in short:

Create the item, add up to five data sources (lakehouses, warehouses, semantic models, KQL databases, ontologies, Microsoft Graph), and tick the tables it may use. For lakehouses it uses tables, not loose files.
Write instructions (up to 15,000 characters): which source answers which kind of question, plus definitions of your terms.
Add example queries (up to 100 per source): question and SQL pairs. They are not supported for Power BI semantic models.
Test, then publish with a clear description. Orchestrators use that description to decide when to call the agent.

Descriptive table and column names matter more than any prompt. Microsoft’s own tip: SalesData beats TableA, and IsCustomerActive beats ActCu.

Instructions that do real work, written as routing and rules (illustrative):

Sources
- lakehouse_sales: use for questions about orders, revenue, customers and
  products. Tables: fact_sales (one row per order line), dim_customer,
  dim_product, dim_date.
- sales_semantic_model: use for headline KPIs (revenue, margin, year on year)
  and anything that must match the Power BI reports.

Rules
- "Revenue" always means net revenue after discounts, excluding VAT.
- The financial year starts on 1 April.
- If no period is given, use the last 12 complete months.

An example pair that encodes a business rule once (illustrative):

Question: Net revenue by product category last month

SELECT p.category, SUM(f.net_revenue) AS net_revenue
FROM fact_sales f
JOIN dim_product p ON f.product_key = p.product_key
JOIN dim_date d ON f.date_key = d.date_key
WHERE d.is_last_complete_month = 1
GROUP BY p.category
ORDER BY net_revenue DESC;

Limits to design around:

Answers are capped at 25 rows and 25 columns, because it is built for conversation, not for exporting datasets. Send people who need the full data to a report.
It does not read unstructured files (PDF, Word, text), and it is documented as working best in English.
Questions needing reasoning beyond retrieval are out of scope. Microsoft’s examples: “Why is our factory productivity lower in Q2?” or “What is the root cause of our sales spike?”
The data agent’s workspace capacity must be in the same region as the source’s capacity.

Data agents are items like any other: they support Git integration and deployment pipelines, so keep instructions and example queries in the repository, review changes in pull requests, and promote through environments. Test every change against your golden questions (see Part 1).

6. Rollout checklist for a Fabric team

Confirm the tenant settings and capacity size, and decide who can use Copilot.
Start with a pilot group, and watch Copilot in Fabric in the Capacity Metrics app.
Connect workspaces to Git before any agent edits code, and separate development from production.
Give any agent identity (such as the Fabric MCP server’s) the least access that works, development only at first.
Improve names and descriptions in the gold layer before building a data agent on it.
Write golden questions, run them on every change, and add real user misses to the set.
Keep approvals on in notebooks, and review every diff.
Pilot the operations agent on a few non-critical pipelines, and compare it with your own diagnosis first.

Sources

Rates, limits and preview status change, so the documentation is the source of truth. Code marked illustrative was written for this guide.