11.2 Integrate a Foundry Agent

11.2 Integrate a Foundry Agent

Quick Answer: On the main agent’s Agents page, Add an agent → Microsoft Foundry, create or pick a connection with the Foundry project endpoint URL, then set Name, Description, and Agent Id. Publish and test. Use Foundry when specialized Foundry-built agent capabilities should stay outside a single fat Copilot Studio agent—while the parent still owns the user experience.

AB-620 explicitly measures Integrate a Foundry agent under multi-agent collaboration. In product docs this is Connect to a Microsoft Foundry agent (preview)—an external agent type alongside Fabric Data agents, A2A agents, and Microsoft 365 Agents SDK agents. Treat preview status as an exam awareness item: features evolve, but the integration pattern (endpoint connection + Agent Id + description-driven routing) is what scenario items test.

Why Foundry agents appear in Copilot Studio designs

Microsoft Foundry (often discussed as Azure AI Foundry in cloud architecture) is where pro-dev and AI platform teams build agents with Foundry-native tools, models, and evaluation loops. Copilot Studio is where many enterprises want a channel-ready orchestrator—Teams, web, and Power Platform governance—without rebuilding every specialist in maker UI.

Exam trap: Integrating a Foundry agent is not the same skill as “configure custom prompts against the Foundry model catalog” or “generative answers with Azure AI Search with Foundry.” Those are Azure integration / prompt / knowledge leaves. This leaf is multi-agent: another agent is a peer capability on the Agents page.

Prerequisites and portal generation constraint

Before you click through the wizard, confirm:

1. You have a Microsoft Foundry project that hosts the target agent.
2. You can obtain the project endpoint URL for the connection.
3. You know the Agent Id of the Foundry agent to call.
4. The agent was created in the new Microsoft Foundry portal. Microsoft documents that connecting to an agent from the previous portal can produce 404 - Version not found.
5. Security/compliance stakeholders accept cross-platform data flow between Copilot Studio and Foundry for your use case.

Configuration steps (maker path)

Aligned with Microsoft Learn:

1. Open the main Copilot Studio agent.
2. Go to the Agents page → Add an agent.
3. Under Connect to an external agent, select Microsoft Foundry.
4. Select an existing connection or create a new connection by providing the Foundry project endpoint URL.
5. Select Next after the connection is ready.
6. Enter an appropriate Name and Description for the connected specialist. The description must explain purpose so the main agent knows when to use it (see writing effective metadata / generative action guidance).
7. Enter the Agent Id for the Foundry agent.
8. Adjust the description further for the main agent’s context—especially if other tools or agents could overlap.
9. Select Add Agent.
10. Test immediately in the test pane; confirm activity map / orchestration chooses Foundry when intents match.
11. If the Agent Id must change later, open the agent from the Agents list details and update it.

Description engineering for Foundry specialists

Because Foundry agents often have powerful tools, a vague description (“Advanced AI helper”) is dangerous: the parent may over-delegate sensitive work or under-delegate legitimate specialist tasks.

Good description traits:

• Domain boundary (“financial anomaly explanations using the Contoso risk model tools”).
• Explicit in-scope and out-of-scope cues.
• Differentiation from sibling Copilot Studio agents and REST/MCP tools.
• Language that matches how users phrase requests in your channels.

Parent instruction alignment:

• State when the orchestrator must call the Foundry agent.
• Reinforce single user-facing response patterns if the Foundry agent might otherwise surface intermediate chatter.
• Pair with evaluation sets that include both in-domain and near-miss queries (for example legal questions that should not hit a finance Foundry agent).

Runtime behavior and multi-agent impacts

When the parent selects the Foundry specialist:

1. Copilot Studio orchestration decides the Foundry agent matches the task.
2. An extra hop runs the Foundry agent’s own plan/tools.
3. Results return to the parent context for continuation or final answer synthesis.
4. Latency and failure modes now include Foundry availability, auth to the project, and specialist tool errors—not only Copilot Studio topics.

Design monitoring across both planes: Copilot Studio transcripts plus Foundry/Application Insights-style observability where your Azure chapter skills apply. Correlate sessions when debugging “parent chose wrong specialist” versus “specialist failed after correct choice.”

Governance and maker responsibility (explicit in docs)

Microsoft states you are responsible for carefully reviewing and testing connected agents for your use cases. When connecting outside Copilot Studio, you own decisions about:

• Data flows, handling, and sharing between agents (requirements and laws).
• Quality, reliability, security, and trustworthiness of the external agent.
• Permissions, boundaries, and approvals when prudent.
• Observability, identity/traceability, and human oversight.

Exam trap: “Connect Foundry and skip security review because it is Microsoft-hosted” is wrong. Platform hosting does not remove use-case responsibility for what the specialist can do with enterprise data.

Also remember Domain 1 themes: identity strategy, responsible AI, and channel audience still apply to the parent experience even when reasoning lives in Foundry.

Realistic scenarios

Scenario A — Specialist reasoning stays in Foundry. Fabrikam’s data science team ships a Foundry agent with custom tools for warranty fraud scoring. The Copilot Studio customer-support orchestrator answers policy FAQs with knowledge sources but connects the Foundry agent for “score this claim pattern” intents. Makers supply the project endpoint, Agent Id, and a tight description so ordinary “Where is my refund?” questions never invoke fraud scoring.

Scenario B — Portal generation mistake. A maker tries to connect a legacy Foundry (previous portal) agent and hits version errors. The fix is not random Agent Id edits—it is using an agent created in the new Foundry portal (or recreating/migrating per current platform guidance).

Scenario C — Overlap with tools. The parent already has an MCP tool that returns raw telemetry. A Foundry agent also summarizes telemetry narratives. Without distinct descriptions and parent instructions, orchestration oscillates. Clarify: MCP tool for structured metrics pull; Foundry agent for multi-step investigative narratives.

Pitfalls checklist

1. Confusing Foundry agent integration with Foundry model catalog prompts.
2. Connecting old portal agents → 404 version failures.
3. Wrong endpoint or Agent Id.
4. Generic descriptions → over/under invocation.
5. Ignoring data-sharing and approval duties for external agents.
6. No tests for near-miss intents.
7. Expecting zero added latency after adding a second orchestration plane.
8. Disabling parent governance because “Foundry will handle it.”

Success checklist

• Walk the Add agent → Microsoft Foundry path without notes.
• Explain endpoint + connection + Agent Id + description.
• State the new portal constraint.
• Separate this skill from other Foundry-related AB-620 leaves.
• List maker responsibilities for external agent trust and data flow.
• Design parent instructions so Foundry is a specialist, not a second unsupervised front door.

When you can justify why a capability lives in Foundry and show how Copilot Studio safely invokes it, you have this blueprint leaf.