Ask a coding agent to add a notebook, change a data pipeline, or schedule a Fabric job. Writing the code may be the easy part. The harder questions are what the agent is allowed to change, what it must understand about the business, and what evidence proves that the change works.

Agent-assisted development in Microsoft Fabric means using a coding agent to inspect, create, or revise supported Fabric assets through permitted files and tools. The agent can propose definitions, invoke development operations, and collect test evidence. Microsoft Fabric remains the platform that stores data and executes jobs. People still own the intended outcome, business rules, access boundaries, and release decision.

This article covers data engineering items such as pipelines, notebooks, and lakehouses. For where Fabric sits among Copilot Studio, Foundry, and the other layers, start with the Microsoft agentic AI stack.

Agent-Assisted Fabric Development at a Glance

A useful mental model starts with responsibilities rather than a particular data architecture:

  • Fabric assets are the concrete objects in scope, such as a data pipeline, notebook, lakehouse, supported item definition, or job schedule.
  • Access routes are the interfaces through which the agent works: source-controlled item files, Fabric REST APIs, or purpose-built Model Context Protocol (MCP) tools.
  • Project knowledge explains the architecture, domain language, data contracts, naming rules, and approval boundaries that are not contained in an API schema.
  • Review evidence connects a requested change to its definition diff, development run, data checks, and release decision.
Agent-assisted Fabric development at a glance

The operating model around a Fabric change.

A scoped request guides a coding agent working through Git, Fabric REST APIs, or MCP. The agent produces a proposed Fabric item change with a diff and development run, and Fabric runs it in the target environment only after an approved release.
The agent authors a proposal through a permitted interface. The reviewed item definition becomes a running system only when Fabric executes it in the target environment.

What Fabric Assets Can an Agent Work With?

A Fabric workspace groups items and establishes an important access boundary. A data pipeline coordinates activities such as copying data or invoking a notebook. A notebook contains executable Python, PySpark, SQL, or other supported source. A lakehouse combines OneLake storage with tables and files.

These assets have different kinds of state. A pipeline definition contains activities, dependencies, parameters, and references. A notebook definition contains source code and metadata. Deploying a lakehouse definition does not move its table rows or Files content. A schedule belongs to a target item and does not prove that the scheduled job has valid credentials, connections, or data.

An agent can therefore help with work such as:

  • inspecting workspaces, items, definitions, and dependencies
  • creating or updating supported pipeline and notebook definitions
  • editing source-controlled item files and returning a Git diff
  • triggering permitted development jobs and checking their status
  • collecting run identifiers, errors, and validation evidence for review

The useful unit of work is an explicit item and a bounded change. “Update this pipeline to call the existing normalization notebook” can be inspected. “Build the data platform” leaves too many architectural and business decisions implicit.

Power BI reports and semantic models are a related but distinct development surface. Their files, authoring tools, and visual acceptance checks are covered in Agentic Development for Power BI Reports and Semantic Models.

Three Ways an Agent Can Work with Fabric

There is no universal interface for every Fabric operation. The best route depends on the asset, the operation, and the review evidence the team needs.

Edit Source-Controlled Item Files

Fabric Git integration stores supported item definitions as files. A Python or PySpark notebook can appear as readable source. A data pipeline uses a JSON definition, including pipeline-content.json. A coding agent can inspect related files, change a definition, add tests, and return a Git diff.

This route is strongest when engineers want to review exactly what changed before syncing or deploying a workspace. Item support varies, and lakehouse data is not part of the Git diff. Generated metadata or logical identifiers should not be changed merely to make a deployment pass.

Call the Fabric REST APIs Directly

Fabric item-definition APIs can create, retrieve, and update supported items. Notebook definitions support a Git-source or a Jupyter notebook representation. Data pipeline definitions expose the activity graph. Separate job APIs execute and schedule supported items.

A small authenticated client can make these calls deterministic, preserve item identifiers, poll long-running operations, and record the result. The API changes the supported definition. It does not carry source credentials, copy lakehouse data, or grant the caller additional rights.

Use Purpose-Built MCP Tools

MCP presents selected operations as named tools that a coding agent can discover and call. Microsoft documents three relevant servers, each with its own tool inventory:

  • The Fabric Core MCP Server is a remote preview endpoint for workspace and item management, including definition tools.
  • The local Fabric MCP Server is an open-source server that runs on the developer's machine. It combines offline API documentation and best-practice guidance with OneLake file and table tools, core tools for catalog search and item creation, and Data Factory tools that create, list, and run pipelines.
  • The DataFactory MCP server has preview tools for creating a pipeline, reading or updating its definition, running and monitoring it, and creating or listing schedules. It does not delete a pipeline or modify an existing schedule, so another authorized route is needed for those operations.

An MCP tool does not bypass Fabric permissions. It invokes an operation using the configured identity, and a typed tool does not make a generated definition correct.

The available interfaces

Choose the interface by operation and evidence.

A capability matrix compares Git item files, direct Fabric REST APIs, and Fabric MCP servers for definition changes, jobs and schedules, and OneLake data. The MCP row shows which of the Core, local, and DataFactory servers covers each operation.
Files provide the clearest definition diff, REST APIs provide explicit operations, and MCP offers selected agent-friendly tools. Teams can combine the routes without treating them as interchangeable.

A coding agent might edit notebook source in Git, call a REST API to deliver it to a development workspace, and use an MCP tool to inspect a pipeline run. The route can change during the lifecycle, but the identity performing each operation and the evidence it produces should remain visible.

Guiding the Agent with Skills and Project Knowledge

Fabric APIs tell a coding agent which structures and operations exist. They do not teach it the safest procedure or the business meaning behind a change. Microsoft's Skills for Fabric fill the first gap: a skill is a reusable instruction package that tells a compatible coding tool how to perform a class of work, such as resolving an existing pipeline, updating its definition, and collecting run evidence. A skill is guidance. It still needs an authenticated REST or MCP route to act.

Reliancy recommendation: keep a small, versioned set of Markdown project notes beside the code. They should hold the system map (workspaces, items, owners, and the permitted interface for each change), the domain rules (source contracts, table grain, mappings, and quality rules), and the local guardrails (forbidden changes, approval gates, and required tests). Each approved note needs an owner and review date, and it should link to credentials in a secret store rather than contain them.

Keep the work record separate from that knowledge. An open issue, the decision taken, the change with its diff and run identifiers, and the validation result should link to one another in the tracker the team already uses, such as Azure DevOps Boards or GitHub Issues. A later engineer or agent can then see why an approach was rejected instead of proposing the same failed fix again.

One Bounded Change from Request to Release

Consider a supplier feed that must be ingested by an existing pipeline and normalized by an existing notebook. The team already knows the source contract, accepted product mapping, target table grain, reject policy, and reconciliation result. Those facts belong in the project notes before the agent starts.

One bounded change

Each stage of the change leaves its own evidence.

A six-stage sequence for one Fabric change. People frame the request; the coding agent inspects current state, drafts the change, and runs it in development; people review it and release it separately. Beneath each stage is the evidence it leaves, from a scoped request and item identifiers to a definition diff, run and data checks, a review decision, and an operations plan.
An API success response proves only that an operation was accepted. Definition, execution, data, and operations evidence accumulate across the stages, and release remains a separate human decision.

A typical agent-assisted lifecycle then has six distinct states, and each one produces evidence of its own:

  1. Frame the request: name the target items, environment, expected outcome, prohibited changes, and acceptance evidence.
  2. Inspect the current state: resolve existing item identifiers, dependencies, connections, schedules, open issues, and applicable decisions before generating anything new.
  3. Produce a reviewable proposal: choose the permitted interface, change the pipeline or notebook, preserve unrelated definitions, and return the diff with assumptions. The definition evidence shows that the activity graph, notebook source, parameters, and references match the request.
  4. Run in development: execute through an authorized identity and capture job and activity results. The execution evidence shows that connections resolve and failures are observable. The data evidence shows that the output matches the accepted grain, mapping, and reconciliation logic, with exceptions still visible.
  5. Review the evidence: approve, revise, or reject the change, and record the decision against the issue.
  6. Release separately: promote under the target environment's controls with a known schedule, monitoring owner, rerun behavior, and rollback plan. DevOps and Release Automation for Microsoft Fabric covers that release path.

Notebook identity deserves particular attention. Interactive runs, scheduled runs, and a notebook invoked by a pipeline can have different security contexts. A successful development run by an engineer does not prove that a scheduled pipeline will have the same access.

If the team uses a medallion architecture, its Bronze, Silver, and Gold rules belong in the project notes. They are not a required structure for agent-assisted Fabric development.

What to Decide Before a First Pilot

Choose one Fabric change with a stable source contract and an outcome the team can test. Then decide:

  • which item and environment the agent may change
  • which interface is permitted for each operation
  • which project knowledge is authoritative and who reviews it
  • where issues, decisions, changes, and validation evidence are recorded
  • which system owns definitions, runtime state, work status, and credentials
  • what evidence is required before a human may approve release

A good first pilot produces a bounded Fabric change that another engineer can understand, reproduce, validate, and recover.

Discuss an agent-assisted Fabric engineering pilot with Reliancy.

Sources and Product Documentation

All articles