In our previous post, Operationalizing Agentic Applications with Microsoft Fabric, we focused on a core challenge teams encounter once an agentic application moves beyond a proof of concept: operational reality. Specifically, how do you observe, govern, evaluate, and analyze what agents are doing once they interact with real users, data, and business processes at scale? That post introduced a production‑minded reference architecture, grounded in Microsoft Fabric, that treats agent activity as first‑class, governed data rather than opaque logs.
Since then, the solution accelerator behind that reference implementation has evolved. The updates are intentionally pragmatic rather than conceptual: fewer manual steps during deployment, clearer separation of agent responsibilities, and a more explicit use of Fabric’s native AI capabilities where they add real operational value. This post focuses on two of those changes:
- A script‑driven deployment model, using Microsoft Fabric REST APIs, that reduces manual configuration.
- The introduction of a Fabric Data Agent as an optional, read‑only agent
Scripted deployment with Fabric REST APIs
Microsoft Fabric exposes REST APIs for item and capacity management, allowing developers to automate common provisioning tasks such as creating Lakehouses, SQL databases, or other items within a workspace. In the updated agentic app solution, these APIs are used to perform “day‑zero” setup tasks that previously required some manual intervention.From an operational perspective, the significance is not speed but repeatability. Scripted deployment enables:
- Consistent environment setup across dev, test, and production.
- Reduced configuration drift, especially in teams with multiple contributors.
- Clearer ownership, as infrastructure choices are encoded and version‑controlled.
Introducing a Data Agent as a complement, not a replacement
The second notable update is the introduction of a Fabric Data Agent as an optional, read-only agent within the application. You can enable this agent as part of the agentic team via setting an environment variable. A detailed guideline is also provided to help you configure Data Agent in an optimized manner. Note that this agent is deliberately scoped to answering questions over curated, structured data and does not perform transactions or trigger actions.In the original design, task‑oriented agents handled both reasoning and data retrieval. While this works, it conflates two concerns: deciding what to do and answering what the data says. Over time, that blending can make safety and evaluation harder, particularly when users begin to ask exploratory or analytical questions.
Fabric Data Agents are explicitly designed to operate over governed Fabric data sources—such as Lakehouses, semantic models, and other supported Fabric data asset types—and to return answers using natural language. They do not support create, update, or delete operations; that constraint is intentional.
By introducing a Data Agent alongside task‑focused agents, the architecture makes a clearer distinction:
- Task agents' reason, plan, and orchestrate actions.
- Data agents answer questions about existing data, grounded in governed models.
Why consider Fabric’s Data Agent for agentic apps?
From a customer perspective, the value of using Fabric’s Data Agent is not novelty, but alignment with existing data governance. Fabric Data Agents use the same underlying permissions, semantic models, and OneLake‑backed data foundation as the rest of the Fabric platform.This has several practical implications:
Read‑only by Design
Fabric Data Agents do not support mutating operations. As documented, they answer questions using SQL, DAX, or KQL under the hood, but they cannot modify data. This makes them suitable for scenarios where users need transparency and insight without the risk of unintended side effects.Grounded in Curated Models
Rather than exposing raw tables, Data Agents rely on whatever models and tables you explicitly configure. This encourages teams to think carefully about what data should be queryable in natural language, and to reuse the same semantic definitions already used for reporting and analytics.Consistent Governance Across Analytics and AI
Because the Data Agent operates within Fabric, it inherits workspace‑level governance, access controls, and auditing. This reduces the need to build parallel security models just to support AI interactions.Operational benefits without architectural overreach
Taken together, these updates reflect a broader design principle: operational maturity comes from narrowing responsibilities, not expanding them indiscriminately.Scripted deployment ensures that infrastructure is predictable and reviewable. A dedicated Data Agent ensures that data access is controlled, explainable, and easier to evaluate independently from task execution. Neither change alters the core agentic concepts explored in the original post. Instead, they reduce friction and risk as systems scale.
Closing thoughts
Agentic applications are most compelling when their intelligence is matched by their operational discipline. The recent updates to the Fabric‑based reference implementation reflect lessons learned from early adopters, and we know what matters: automation, clarity of agent roles, and tight integration with governed data platforms.These are not features to be marketed in isolation, but safeguards that make agentic systems usable and trustworthy in production. For customers already invested in Microsoft Fabric, they offer a way to extend existing governance and deployment practices into the agentic layer without inventing new ones unnecessarily.
We invite you to explore the repo at aka.ms/AgenticAppFabric and contribute your insights via opening an issue in the GitHub repo!