1.4.2. Microsoft Foundry and the Pro-Code Stack
💡 First Principle: Foundry exists because managed defaults have a ceiling. When a solution needs a specific model, a fine-tuned model, or an agent whose behavior is expressed in code rather than configuration, you need the platform where those knobs exist — and that platform is Microsoft Foundry (rebranded from Azure AI Foundry, so read both names as one product).
Foundry is Azure's AI development platform: a model catalog spanning frontier and open models, tooling to evaluate and fine-tune them, and an agent service for building and hosting pro-code Foundry agents. It speaks the languages of professional software teams — SDKs, CI/CD, Azure RBAC — and it scales to solutions that would be impractical to express in a low-code designer.
What matters most for AB-620 is the composition surface, because the exam tests integrated solutions. Three integration patterns recur: custom prompts in Copilot Studio can select models from the Foundry model catalog instead of the default (2.4.2); generative answers can be grounded through Azure AI Search with Foundry models (2.4.1); and a Foundry agent can join a Copilot Studio multi-agent solution as a connected agent (2.3.3). In each pattern, Copilot Studio remains the conversational front door while Foundry supplies specialized capability behind it.
⚠️ Exam Trap: "We need a specific/fine-tuned model for one task" does not mean rebuilding the whole agent in Foundry. The exam-preferred answer is usually the narrowest integration: keep the Copilot Studio agent, point the relevant prompt or answers node at the Foundry capability.
Reflection Question: A legal team needs contract analysis using a fine-tuned model, delivered inside their existing Teams agent. Which parts of the solution live in Copilot Studio, and which in Foundry?
