Connect coding agents to Fabric notebooks with FNTK (Preview)

The Fabric Notebook Toolkit (Preview) helps developers shorten the feedback loop between writing code and validating it with live notebook results. It connects coding agents to Microsoft Fabric notebooks through a command-line interface (CLI) that runs in the terminal alongside tools such as Claude Code, GitHub Copilot CLI, and Codex. An agent can inspect the current code, run one cell, review its output, make a targeted change, and run it again without resubmitting the entire notebook—much as a human programmer working interactively.

Figure: Animated GIF A coding agent uses FNTK from the terminal to interact with a Microsoft Fabric notebook.

From code suggestions to notebook execution

A coding agent can help write a transformation, but a proposed change is not the same as a working result. When execution happens elsewhere, developers must move code into a notebook, run it, and bring the results or errors back to the agent. FNTK connects those steps so the agent can work with a running Fabric notebook and its execution results instead of relying only on code shared in the conversation.

Interactive development and debugging are the central use cases. You can ask an agent to inspect a notebook, investigate a failing transformation, or validate a change using actual execution output. The notebook remains in Fabric and uses Fabric capacity for distributed data processing, while FNTK provides the terminal commands the agent uses to interact with the live session.

Run, inspect, and refine one cell at a time

FNTK keeps the notebook session active while the agent works, so developers can explore and refine code without repeatedly restarting the workflow. For example, an agent can inspect a schema, adjust a conversion, check several records, and return to the same transformation as new information emerges. This mirrors the iterative way developers work in notebooks and keeps each change grounded in actual execution results.

The toolkit brings the operations needed for that workflow into the terminal. An agent can discover the target notebook, read and update its cells, execute code, and retrieve results. Instead of treating every adjustment as a new whole-notebook submission, it can focus on the code being investigated.

• Find workspaces, notebooks, and lakehouses to establish the context for the task.
• Read, add, or update notebook cells as the work develops.
• Execute a cell's code and inspect its output before deciding what to change.
• Reuse the live session to refine and rerun the relevant code.

For example, a transformation may fail because an input column has a different type than expected. An agent can inspect the schema, revise the affected code, and rerun it in the existing session to check the result. This avoids restarting the entire notebook merely to test that change and keeps the investigation focused on the failing operation.

Give the agent the evidence to debug

FNTK gives the agent the execution evidence needed to determine the source of a failure. It exposes cell output and Spark job state, along with driver logs, executor logs, and logs from Livy, the service that manages Spark sessions. With this context, the agent can investigate the likely source of a problem instead of relying on source code alone.

The CLI can return structured JavaScript Object Notation (JSON) responses that identify results, errors, and suggested next actions. An agent can use this information to determine whether execution has finished, retrieve diagnostics, and choose what to investigate next. This shortens the feedback loop between writing code and understanding its behavior while reducing the need to copy outputs and logs manually between tools.

FNTK in practice at Microsoft

For our data engineering team at Microsoft, FNTK filled a gap between generating code and working with real data. Previously, we used an AI assistant to draft code locally, then copied it into Fabric notebooks to run it and brought the results back into the conversation. With FNTK, we can stay in GitHub Copilot, execute code in Fabric, and use the results to iterate.

We started by installing the toolkit, connecting with the appropriate permissions, and asking questions about a data source. Exploratory work quickly became a valuable use case. We could ask for row counts, distributions, or samples, then follow up based on the actual results. From there, we built shared workflow skills and a developer plugin around FNTK, incorporated our engineering standards, and connected the plugin to Azure DevOps through the Model Context Protocol (MCP) to bring user-story context into the same workflow.

In practice, this has sped up development and helped us work across multiple user stories, with more of our time spent reviewing changes rather than writing every line ourselves. Copilot handles the reasoning; FNTK provides the connection to live notebook execution. We can still inspect the runs in Fabric, and our existing source-control, quality, and human-review practices remain in place.

In practice, this workflow has helped us work across multiple user stories and spend more time reviewing changes instead of writing every line ourselves. Copilot handles the reasoning; FNTK provides the connection to live notebook execution. We can still inspect the runs in Fabric, and our existing source-control, quality, and human-review practices remain in place.

Figure: FNTK connects an AI developer agent to live Fabric notebook execution, alongside MCP tools for context and delivery tools for human-reviewed changes.

Capabilities with FNTK commands

Get started

To try the workflow, install the toolkit and connect your coding agent by following the FNTK installation and quick-start documentation, including fntk init for workflow skill setup. Then choose an existing development notebook and a focused task, such as inspecting one transformation. Run the code, review the output, and use the result to guide your next change.