Integrating Foundry Agents
Understand Microsoft Foundry as an AI platform and connect Foundry agents to Copilot Studio for advanced reasoning and custom model capabilities.
What is Microsoft Foundry?
Think of Copilot Studio as a restaurant kitchen and Foundry as a gourmet chef you can hire.
Your kitchen (Copilot Studio) has everything you need for most meals — ovens, stoves, standard recipes. But when a customer orders a complex molecular gastronomy dish, you bring in a specialist chef (Foundry) who has training, custom techniques, and specialised equipment your kitchen does not have.
Foundry is Microsoft’s AI platform where developers build agents using custom models, advanced reasoning, and specialised AI capabilities. When Copilot Studio’s built-in AI is not enough — say, you need medical image analysis or complex financial modelling — you build that piece in Foundry and connect it back to Copilot Studio as a connected agent.
Copilot Studio vs Foundry — when to use which
Both platforms build agents, but they serve different developer profiles and use cases. Understanding the boundary is key for the exam.
| Feature | Best for | Developer profile | AI models | Deployment |
|---|---|---|---|---|
| Copilot Studio | Conversational agents with topic routing, enterprise channels, M365 integration | Low-code / citizen developers and pro-devs doing integration work | Built-in GPT models — you do not choose or fine-tune them | Teams, M365 Copilot, websites, custom channels — built-in channel support |
| Microsoft Foundry | Custom AI logic — advanced reasoning, domain models, multi-step AI workflows | AI engineers and developers comfortable with Python SDKs, REST APIs, and model selection | Full model catalog — GPT-4o, GPT-4o mini, Phi, Llama, Mistral; supports fine-tuning | API endpoints, Azure-hosted — needs Copilot Studio or custom frontend for conversational UX |
| Best together | Copilot Studio handles conversation + channels; Foundry handles complex AI reasoning behind the scenes | Copilot Studio dev builds the orchestrator; AI engineer builds the Foundry agent | Copilot Studio uses default model for routing; Foundry uses specialised model for domain tasks | User talks to Copilot Studio agent in Teams; Copilot Studio calls Foundry agent for heavy AI work |
How integration works
Connecting a Foundry agent to Copilot Studio follows the same connected agent pattern you learned in the multi-agent module — but the connected agent lives in Foundry instead of Copilot Studio.
Integration steps:
- Build the Foundry agent — create an agent in Foundry using the Agent SDK, configure its model, tools, and knowledge sources
- Deploy the Foundry agent — deploy to an Azure endpoint so it has a reachable URL
- Register in Copilot Studio — in your orchestrator agent, go to Settings then Connected agents then Add then Foundry agent
- Configure the connection — provide the Foundry agent’s endpoint and authentication details
- Set trigger descriptions — define when the orchestrator should route to the Foundry agent
- Test the handoff — verify that context passes correctly and the Foundry agent returns structured results
What gets passed between the agents?
When Copilot Studio routes to a Foundry connected agent, it sends the conversation context (user message, relevant variables, and any context you configure). The Foundry agent processes this with its own model and tools, then returns a response. The orchestrator presents this response to the user.
Key point: the Foundry agent runs in its own security context with its own Azure credentials. It does not inherit the Copilot Studio agent’s DLP policies — you must configure security on both sides.
When to use Foundry agents
Not every scenario needs Foundry. Here are the signals the exam uses:
| Signal | Use Foundry | Stay in Copilot Studio |
|---|---|---|
| Custom model needed | Medical diagnosis, legal reasoning, domain-specific fine-tuned model | Standard Q&A, policy lookup, FAQ |
| Advanced reasoning | Multi-step analysis, chain-of-thought, complex calculations | Simple routing, data retrieval, form filling |
| Model choice matters | Need Phi for cost efficiency or GPT-4o for accuracy on specific tasks | Default model handles the task well |
| Evaluation pipelines | Need systematic model evaluation with test datasets | Manual testing in Copilot Studio is sufficient |
| Python/code-first | Team prefers Python SDKs, wants full control over agent logic | Team prefers low-code visual authoring |
Scenario: Lena builds clinical decision support with Foundry
Lena’s healthcare analytics firm needs an agent that helps doctors interpret lab results. The agent must:
- Use a fine-tuned medical model that understands clinical terminology (Copilot Studio’s default model is not trained on medical data)
- Run multi-step reasoning — compare results against reference ranges, flag anomalies, suggest follow-up tests
- Pull from a curated medical knowledge base indexed in Azure AI Search
- Return structured citations so doctors can verify every recommendation
Lena builds this as a Foundry agent: she selects GPT-4o from the model catalog, connects it to the medical knowledge index, and writes evaluation tests against real clinical scenarios. Then she works with the IT team’s Copilot Studio developer who adds Lena’s Foundry agent as a connected agent in the hospital’s employee assistance bot. Doctors talk to the bot in Teams — routine HR and IT questions go to other connected agents, but lab interpretation routes to Lena’s Foundry agent.
Exam tip: Foundry is for what Copilot Studio cannot do alone
If the exam describes a scenario where the built-in model is insufficient — custom training, domain-specific reasoning, model selection — Foundry is the answer. If the scenario just needs a new knowledge source or connector, stay in Copilot Studio.
Lena needs her healthcare agent to use a fine-tuned medical model for lab result interpretation. Where should she build this capability?
What is the primary advantage of the Copilot Studio + Foundry pattern over building entirely in Foundry?