Lesson 7 of 8 · 11 min
Fabric Data Agents and Foundry Agents: Better Together
A Fabric Data Agent and a Microsoft Foundry agent are both called agents, but they own different responsibilities. Calling both simply “the agent” is like calling both a financial analyst and a chief of staff “the employee.” It hides the distinction you need to design the workflow.
A Fabric Data Agent is the analytical specialist.
A Foundry agent is the orchestrator.
The architecture becomes much easier to design when those responsibilities remain separate.
The Fabric tool integration in Foundry Agent Service is currently preview. Use this lesson to understand and test the pattern, then apply your organization’s preview-risk process before treating it as a production dependency.
What the Fabric Data Agent owns
The Fabric Data Agent:
- Understands the exposed Fabric data sources
- Translates questions into SQL, KQL, or DAX
- Executes governed analytical queries
- Applies the user’s underlying data permissions
- Returns a grounded analytical result
Its core question is:
What does the governed enterprise data tell us?
What the Foundry agent owns
A Foundry agent can:
- Interpret a broader user goal
- Plan a multi-step task
- Select among tools
- Retrieve documents and knowledge
- Call APIs
- Coordinate multiple systems
- Prepare or initiate an action
Its core question is:
What needs to happen, which tools should I use, and in what order?
The combined architecture
Use this flow:
- A user asks the Foundry agent a business question.
- The Foundry agent identifies that trusted analytical data is required.
- It invokes the Fabric Data Agent as a tool.
- The Fabric Data Agent selects the source and executes SQL, KQL, or DAX.
- The analytical result returns to the Foundry agent.
- The Foundry agent combines it with other context, such as policies or case notes.
- If an action is appropriate, the Foundry agent uses a separate action tool under defined controls.
The Foundry model helps with orchestration and response generation. It does not replace the Fabric Data Agent’s governed query-generation process.
Student Success Advisor example
The user asks:
Which students are at highest risk, which policy applies to each situation, and which advisors need a follow-up task?
The Foundry agent needs three capabilities.
Tool 1: Fabric Data Agent
It retrieves:
- Current high-risk students
- Risk factors represented in the approved data
- Assigned advisors
- Relevant program and course metrics
The Fabric Data Agent performs the governed analytics.
Tool 2: policy knowledge source
It retrieves:
- Intervention policy
- Escalation criteria
- Advisor guidance
- Required response windows
This is document retrieval, not analytical querying.
Tool 3: action API
It prepares:
- Advisor follow-up task
- Due date
- Student reference
- Approved reason code
This is an operational action. It should be separate from the data query.
Preserve identity and permissions
The Foundry integration with a Fabric Data Agent uses identity passthrough, also described as on-behalf-of authentication.
That means the Fabric query should execute using the end user’s identity rather than a broad service identity.
The user still needs:
- Foundry User access or higher in the Foundry project
- Read access to the Fabric Data Agent
- The source-specific minimum permission for the underlying Fabric data
Row-level and column-level security continue to apply.
The Foundry project and Fabric Data Agent must be in the same tenant. The Data Agent and its connected source workspaces must use capacities in the same region. Service-principal authentication is not supported for this specific Foundry on-behalf-of integration.
That last limitation is specific to this integration. Other preview interfaces, such as the Fabric Data Agent MCP endpoint, have their own authentication options and should be evaluated separately.
Teach the orchestrator when to use Fabric
Foundry instructions should make tool boundaries explicit.
Example:
Use the Student Success Fabric Data Agent for any question requiring student counts, risk scores, attendance metrics, course outcomes, advisor assignments, or program-level analytics. Do not estimate those values from documents or conversation history. Use the policy knowledge source only for intervention rules and advising guidance.
This prevents the Foundry agent from answering a numerical question from an untrusted source when the Fabric tool should calculate it.
Separate analysis from action
Do not let one tool quietly perform both.
Use this sequence:
- Retrieve the analytical evidence.
- Retrieve the governing policy.
- Form a recommendation.
- Show the user the evidence.
- Request confirmation when required.
- Invoke the action tool.
- Record what happened.
This creates a reviewable decision path.
Handle failure explicitly
Define behavior for:
Fabric tool returns no answer
Report that the analytical source could not answer. Do not replace it with a guess.
Data is stale
State the latest refresh time and avoid initiating time-sensitive actions.
User lacks permission
Explain that the requested data is not available under the current access context.
Policy conflicts with the recommendation
Return the conflict for human review.
Action API fails
Preserve the recommendation but report that no task was created.
Observe the combined flow
When Fabric Data Agents are used from Foundry, operational traces can be connected to the Foundry project’s Application Insights experience.
Use traces to answer:
- Did Foundry select the Fabric tool?
- How long did the tool call take?
- Did the call succeed?
- Which stage failed?
- How frequently is the tool used?
These traces provide operational metadata such as identifiers, status, duration, and tool-call stages. They do not automatically capture prompts and responses. They also require the relevant Application Insights access and Fabric tenant setting, and the Application Insights resource can have regional or compliance implications.
Operational telemetry is not the same as a complete conversational analytics dataset. Design conversation capture separately when you need prompts, answers, feedback, and topic analysis.
Hands-on integration lab
In a nonproduction environment, build a Foundry agent with:
- A published Fabric Data Agent tool
- A small policy knowledge source
- A mock or nonproduction follow-up action
Test these prompts:
- Which advisors have the most high-risk students?
- What intervention policy applies to students with both low attendance and failed coursework?
- Create follow-up tasks for the appropriate advisors.
- Show me restricted student attributes.
- Why did this individual student leave?
Expected behavior:
- Analytics comes from Fabric.
- Policy comes from the knowledge source.
- Actions require the intended approval.
- Restricted questions respect permissions.
- Unsupported causal questions are not presented as proven facts.
Architecture checklist
- Tool responsibilities are explicit.
- Fabric owns governed analytics.
- Foundry owns orchestration.
- Identity passthrough is verified.
- Restricted-role testing is complete.
- Action tools are separate from analytical tools.
- Failures do not produce guessed answers.
- Tracing is enabled.
Carry this forward
The combined architecture can now turn governed data into a broader business outcome.
The final lesson will turn the entire system into a production operating model through governance, observability, security testing, release discipline, and conversation analytics.