Fabric’s Data Agent SDK now has two query paths—and neither is the old Assistants workflow

Microsoft’s Fabric Data Agent SDK documentation now tells developers who still use the Fabric OpenAI client to move data-agent queries away from the OpenAI Assistants API. The supported destinations are the Fabric OpenAI Responses client or the published agent’s Model Context Protocol endpoint. The change applies to querying code; Microsoft says creation, configuration and publishing remain unchanged. Microsoft Fabric SDK documentation

That distinction matters because this is not one API replacement across the entire agent lifecycle. Microsoft describes the Python SDK as a management-plane tool built on Fabric’s public REST API: it creates the artifact, attaches sources, sets instructions and examples, and publishes a staged configuration. A published agent is then consumed through a separate runtime surface. The documentation presents MCP as that surface for tools, applications and other agents. Microsoft Fabric SDK documentation

What changes in application code

Microsoft’s migration notebook shows that FabricOpenAIResponses removes the Assistants objects developers previously had to create. There is no assistant or thread setup. A question goes through one responses.create(input=...) call rather than a sequence involving assistant creation, thread creation, message creation and run creation. Follow-up context can be carried either with previous_response_id or with a conversation ID. Microsoft migration notebook

Operational code changes too. Clients poll a response with responses.retrieve rather than polling a run; terminal states include completed, failed, incomplete and cancelled. Tool calls, tool outputs and code-interpreter activity appear in response output items instead of a separate run-steps listing. Microsoft also warns that tabular results may arrive as output items rather than streamed text, so an integration that records only text deltas can miss useful results. Microsoft migration notebook

The evaluation path is not switched automatically. The sample says evaluate_data_agent still defaults to the Assistants API; developers must pass client_class=FabricOpenAIResponses to exercise the new path. That creates a practical migration test: run the same evaluation set through the Responses client before changing production consumers, and inspect both row-level results and the per-step tool-output table. Microsoft migration notebook

MCP is a different boundary

For applications choosing MCP instead, the agent must be published before its endpoint works. Microsoft documents a workspace-and-artifact URL, bearer-token authentication for either a user or service principal, and a server exposing a single tool that accepts a question and returns the generated answer. Publishing to Microsoft 365 Copilot is an exception: Microsoft says that action does not yet use the public API and still requires Fabric’s portal or an SDK run inside a Fabric notebook. Microsoft Fabric SDK documentation

The safest reading is therefore a two-part migration. Keep management automation stable, but explicitly choose and test the consumption contract: Responses for code already shaped around the Fabric OpenAI client, or MCP for interoperable agent and tool consumers. Do not treat a successful publish as proof that either runtime client handles conversation state, traces and non-text outputs correctly.