Connecting a Fabric Data Agent to Microsoft Foundry Agent Service creates two reasoning layers. The Foundry model interprets the request, decides whether to invoke the Fabric tool, and produces the final response. The Fabric Data Agent selects a governed source and generates the structured query. A correct answer depends on both layers and on the identity, permissions, semantic model, data, and client channel around them.
Datrick makes those boundaries testable. The implementation uses a published Data Agent, an explicit Foundry project connection, signed-in user identity passthrough, scoped business questions, traceable tool calls, deterministic source checks, and release evidence. The pilot does not treat a successful playground answer as production readiness.
Which users need which governed Fabric answers inside the Foundry agent? Start with that decision and its permission boundary.
Design the two-agent request path
Build and publish the Fabric Data Agent first. In Foundry, create a Microsoft Fabric project connection using the production Data Agent workspace and artifact IDs, then attach the connection through `MicrosoftFabricPreviewTool` or the corresponding SDK or REST representation. Keep project endpoint, model deployment, connection ID, agent version, and Fabric item IDs environment-specific and versioned.
The Foundry model controls orchestration and final response generation; it does not replace the model Fabric uses for natural-language-to-query generation. Changing the Foundry model can alter tool selection, planning, synthesis, latency, and cost even when the Data Agent definition is unchanged. Changing the Data Agent can alter source routing and queries even when the Foundry agent is unchanged.
| Integration layer | Required decision | Acceptance evidence |
|---|---|---|
| Business contract | Users, decisions, supported questions, prohibited use, authoritative sources, latency, quality, escalation, and owner. | Named cohort and ground-truth question set approved by data and business owners. |
| Fabric Data Agent | Published version, source inventory, descriptions, instructions, examples, permissions, capacity, and lifecycle. | Direct Data Agent tests meet source, query, result, security, and latency thresholds. |
| Foundry connection | Same-tenant project, correct workspace and artifact IDs, connection ID, environment mapping, and access ownership. | Connection resolves the intended published item in dev, test, and production without hard-coded cross-environment references. |
| Foundry agent | Prompt or hosted architecture, orchestration model, instructions, Fabric tool guidance, competing tools, conversation behavior, and version. | Tool selection and final synthesis pass deterministic and adversarial cases. |
| Identity | Signed-in user path, Foundry role, Fabric agent access, source permissions, RLS, CLS, consent, and channel support. | Allowed users succeed and denied users fail closed through the complete integration. |
| Operations | Tracing, Application Insights, evaluations, red teaming, SLOs, alerts, token and Fabric cost, incident response, and support. | Every production run can be correlated across orchestration, Fabric tool, source, identity, result, and release version. |
| Preview governance | Current support matrix, regions, SDK versions, SLA position, channel limitations, release review, and exit plan. | Risk owner approves a bounded pilot and can disable or roll back the integration. |
Preserve the end user's identity end to end
Microsoft documents On-Behalf-Of identity passthrough for this Fabric tool path. The Fabric Data Agent runs queries as the signed-in end user, not as a shared application identity. Users need the required Foundry project role, access to the published Data Agent, and effective permission on every source their questions can reach.
Use the tool-specific permission prerequisites for the Foundry integration rather than copying assumptions from another Data Agent channel. Microsoft currently documents user identity authentication and does not support service-principal authentication for this specific integration. The direct Data Agent API or MCP endpoint has different identity capabilities; these paths are not interchangeable.
Create a persona matrix for Foundry RBAC, Data Agent sharing, semantic model or database access, RLS, CLS, Purview policy, and expected questions. Test the same question as allowed, restricted, and denied users. An administrator's successful playground test says nothing about an end user's production access.
Make Fabric tool invocation deterministic enough to operate
Foundry decides whether to call the Fabric tool. Give the agent concise instructions that state which topics and data require Fabric, which questions belong to other tools, and when to clarify or refuse. The published Data Agent description and Foundry connection must identify the domain without implying broader authority.
Evaluate natural tool selection before forcing `tool_choice`. Required tool choice can prove the connection and can be appropriate for a deliberately Fabric-only workflow, but it can hide routing defects in a multi-tool agent. Test in-domain, adjacent, ambiguous, unsupported, competing-tool, multi-turn, and prompt-injection cases.
Diagnose failures by layer
| Symptom | Likely boundary | Diagnostic action |
|---|---|---|
| Fabric tool is never called | Tool attachment, connection, Foundry instructions, prompt scope, model planning, or competing tool. | Confirm the tool in the agent definition, inspect trace, test explicit in-domain prompts, and compare natural versus required tool choice. |
| Invalid artifact or workspace ID | Foundry project connection points to a malformed or wrong Fabric item. | Copy exact GUIDs from the published Data Agent URL and recreate the environment-specific connection. |
| Unauthorized | User lacks Foundry role, Data Agent access, source permission, or the channel did not preserve user identity. | Reproduce as the affected user and walk the persona matrix without granting broad admin access. |
| Item or configuration not found | Data Agent is unpublished, moved, deleted, changed, or the connection references the wrong item. | Verify publish state, active sources, workspace, artifact, connection, and release manifest. |
| Empty or wrong answer | Foundry routing, Data Agent source routing, generated query, semantic model, source data, permissions, or final synthesis. | Trace both agents, compare generated query with direct source result, and locate the first incorrect step. |
| Thread active or intermittent timeout | Conversation concurrency, network, Fabric delay, source latency, model throttling, or retry behavior. | Use a fresh thread when blocked, correlate timings, apply bounded retries, and prevent retry amplification. |
| Works in development but fails after publishing | Identity, RBAC, connection, version, channel, or permission behavior changed at release. | Run acceptance tests through the published endpoint and channel with real user personas before exposure. |
Trace and evaluate the complete answer, not one model
Instrument Foundry with Application Insights and preserve traces for model calls, tool decisions, tool inputs, Fabric results, errors, token usage, latency, and final output subject to privacy policy. Correlate these records with Data Agent version, source version, user persona, generated query evidence, and business ground truth.
Foundry's monitoring dashboard can surface token usage, latency, run success, evaluation outcomes, and red-team results. Those metrics do not by themselves prove business correctness. Build continuous evaluations for tool-call accuracy, intent resolution, task adherence, source selection, query correctness, calculation accuracy, security, answer relevance, refusal, and reproducibility.
- Compare direct Fabric Data Agent quality with the answer after Foundry orchestration and synthesis.
- Run positive and negative personas across all sources and connected channels.
- Include competing tools, prompt injection, stale conversations, missing permissions, unpublished agents, timeouts, and source changes.
- Track p50 and p95 latency, run success, retries, Foundry tokens, Fabric AI Query and generated-query workload, and cost per accepted answer.
- Block release when critical questions regress, security fails, unsupported tool calls rise, or the published channel cannot preserve OBO identity.
Run a three-to-five-week Foundry integration pilot
- Select one governed data domain, one published Fabric Data Agent, one Foundry agent, one supported channel, and a named user cohort.
- Define question scope, ground truth, source authority, identity and permission matrix, quality threshold, SLO, cost envelope, and preview risk owner.
- Create environment-specific Fabric connections, attach the preview tool, configure OBO user access, and validate direct and integrated queries.
- Write concise tool-routing guidance and build natural, forced, competing-tool, unsupported, adversarial, and multi-turn evaluation cases.
- Enable tracing and monitoring; correlate tool calls, Fabric queries, results, identity, errors, latency, tokens, capacity, and release versions.
- Promote through isolated environments, run persona and channel acceptance, exercise failure and rollback, and document support ownership.
- Deliver architecture, connection and release specification, permission matrix, test suite, scorecard, monitoring, runbooks, limitations, and go, limit, or stop recommendation.
Frequently asked questions
Can Microsoft Foundry Agent Service use a Fabric Data Agent as a tool?
Yes. Microsoft documents a preview Fabric Data Agent tool for Foundry Agent Service. A published Fabric Data Agent is connected to the Foundry project, then attached to a prompt or hosted agent through the Microsoft Fabric preview tool. The Foundry model handles orchestration and response generation while the Fabric Data Agent performs its own structured-data query generation.
How does identity work between Foundry and Fabric Data Agent?
The documented Foundry integration uses user identity passthrough, also called On-Behalf-Of authorization. Fabric queries run under the signed-in end user's identity. Each user needs the required Foundry role, access to the published Fabric Data Agent, and effective permission on the underlying sources. Service principal authentication is not currently supported for this specific Fabric tool path.
Why does our Foundry agent not call the Fabric Data Agent tool?
The tool can be missing, connected to the wrong Fabric item, unpublished, or poorly described, and the agent instructions might not provide a clear routing rule. Validate the Fabric project connection, workspace and artifact IDs, published state, tool configuration, and user access. Test natural tool selection with representative prompts and use required tool choice only as a diagnostic or intentionally constrained workflow.
How should we evaluate a Foundry agent that uses Fabric Data Agent?
Evaluate the complete path: user intent, tool selection, Fabric source routing, generated SQL DAX or KQL, source result, final answer, security behavior, latency, tokens, failures, and business usefulness. Include allowed and denied personas, unsupported questions, competing tools, multi-turn cases, timeouts, publication changes, and regressions. Use Foundry traces and Application Insights with a versioned ground-truth dataset.
How long does a Foundry and Fabric Data Agent integration assessment take?
A focused production-shaped pilot can often be completed in three to five weeks for one Foundry agent, one published Fabric Data Agent, one governed domain, and a named user cohort. The work covers connection setup, OBO identity, source permissions, tool instructions, evaluation, tracing, monitoring, failure handling, release controls, and a go, limit, or stop recommendation.
Official implementation references
- Use Microsoft Fabric Data Agent with Foundry Agent Service
- Foundry Agent Service tools overview
- Foundry Agent Monitoring Dashboard
- Microsoft Foundry Agent Service overview
- Fabric Data Agent sharing and source permissions
- Fabric Data Agent configuration best practices
Start with one Foundry agent, one Fabric Data Agent, and one real user permission model. Datrick can implement the connection, prove tool and answer behavior, and deliver a production adoption decision.