Forum Discussion
Designing AI Agent Workflows on Modern Data Platforms
Hi everyone,
I have been exploring how AI agents can work with modern data engineering platforms to automate business processes.
A common architecture I see is that data pipelines collect and prepare information, AI agents analyze the context and determine the next action, workflow services execute tasks through APIs or connected systems, and the results are stored for reporting or further processing.
I am interested in how teams are approaching this with Microsoft Fabric.
Are you using AI agents directly with Fabric workflows, or keeping the AI layer separate?
What patterns work well for connecting AI agents with Lakehouse, Data Pipelines, or notebooks?
How do you manage security and permissions when AI applications need access to enterprise data?
Are there recommended approaches for combining Fabric workloads with external AI services?
I would be interested to hear what architecture patterns others are using and what challenges you have encountered.
3 Replies
- v-csrikanth
Community Support
We would like to inquire whether have you got the chance to check the solutions provided by other users in community to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.
In my view, one feasible approach is to leave Microsoft Fabric with the role of the regulated data and orchestration system and to assign to the AI agent a different decision-making layer.
For instance, the Lakehouse serves to store meaningful business context, Data Pipelines are able to ensure ingestion and transformation of the data, and notebooks help to derive more advanced features from data and create agent-ready datasets. The agent will use only what is needed through some restricted APIs and/or functions and will ignite Fabric pipelines and subsequent business processes instead of having full access to the Lakehouse.
In terms of security, I would rather implement identity-based authorizations with the minimum level of access given and designing a firm line between what the agent is allowed to “read” and what the agent is able to “execute”.
From my point of view, the tricky moment here is to define the exact demarcation line between Fabric’s internal AI capabilities and the level of involvement of third-party models and agents that will not lead to unnecessary data movements and violations of governance requirements.
- ShivekMaharaj
Memorable Member
Hi codeautomation,
I would generally separate the agent/orchestration layer from the deterministic data-processing layer, even if both live within the Microsoft ecosystem.
A pattern I like in Fabric is:
Agent/orchestrator
-> decides what information or action is requiredFabric Data Agent
-> retrieves governed context from Lakehouse, Warehouse, Power BI semantic models, KQL, etc.Fabric User Data Function / Pipeline / API
-> performs an explicitly allowed business actionLakehouse / Warehouse / Eventhouse
-> remains the governed system of recordMicrosoft's Fabric Data Agent is now generally available and is well suited to governed conversational access over Fabric data. I would treat it primarily as the reasoning/query layer over enterprise data rather than as the component that owns long-running workflow execution.
For the action side, Fabric User Data Functions are becoming quite useful. They provide reusable serverless Python logic that can be invoked from pipelines, notebooks, Activator rules or external applications through REST endpoints.
Pipelines and notebooks are still where I would keep deterministic ETL, Spark processing, scheduled jobs and heavier transformation logic.
For an external AI agent, Microsoft now also supports exposing a published Fabric Data Agent through Fabric IQ / MCP into Microsoft Foundry. That gives the external agent a governed Fabric data tool rather than requiring it to connect directly to every Lakehouse/Warehouse itself. That integration is currently Preview.
On security, I would avoid giving an agent broad workspace-level access or embedding user credentials. Use a dedicated service principal or workspace identity where the workload supports it, then grant only the Fabric/item/data permissions required for that specific tool. OneLake security can further restrict access to specific folders, tables, rows and columns.
I would also separate read and write capabilities. For example, an agent might be allowed to query a Data Agent freely, but any action that changes enterprise data should go through a small set of explicit functions/APIs with validation, idempotency and audit logging.
One other consideration when using external AI services: Microsoft notes that when Fabric Data Agent responses are consumed outside Fabric, those responses can be processed outside Fabric's compliance/geographic boundary depending on the consuming service, so that should be included in the architecture/security review.
So personally, I would not build one large "AI agent with full Fabric access." I would use Fabric as the governed data/action platform and expose narrow tools to an agent orchestrator.
That keeps reasoning flexible while keeping data access and business actions deterministic and auditable.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
