Choosing Between Foundry Agent Service and Copilot Studio in Microsoft Foundry
This is the decision that most often gets made by default (whichever tool the first prototype happened to use) rather than deliberately — and it's expensive to reverse once a team has built real workflows on top of either. This post is written as an architecture decision record (ADR), because that's genuinely the right format for this choice.
The decision, visually
The framework
Copilot Studio serves low-code, business-user scenarios: smaller knowledge bases, simpler conversational flows, built by people who aren't primarily software engineers. Foundry Agent Service serves pro-code, complex multi-agent orchestrations with custom models and enterprise networking requirements, built by engineering teams who need fine-grained control.
The mistake is treating this as an either/or for the whole organization. The realistic pattern for most enterprises: both, applied to different workloads, with an explicit boundary for which goes where.
Worked example: splitting a customer support system
Say you're building the customer-support agent system referenced throughout this series. Here's how the split typically shakes out:
| Capability | Tool | Why |
|---|---|---|
| FAQ / policy lookup bot for internal HR team, built and maintained by the HR ops team themselves | Copilot Studio | No engineering team needed to maintain it; small, stable knowledge base; low request volume |
| Customer-facing order-status + refund-processing agent with payment API calls | Foundry Agent Service | Needs idempotent tool calls (Part 5), custom auth, and engineering-owned reliability guarantees |
| Multi-agent escalation flow (support bot → fraud-check agent → human handoff) | Foundry Agent Service | Requires orchestration primitives (Part 7) and custom state management Copilot Studio doesn't expose |
| Internal Teams bot that answers "what's our PTO policy" | Copilot Studio | Business-owned content, needs to be edited by non-engineers, low stakes if occasionally imperfect |
The pattern: Copilot Studio where the failure cost is low and the owner is a business team; Foundry Agent Service where the failure cost is high (money movement, compliance-sensitive actions) and the owner is engineering.
Worked example, architecturally
What happens when a Copilot Studio workload outgrows itself
The scenario worth planning for explicitly, since it happens often enough to deserve its own section: a Copilot Studio bot starts as a simple FAQ bot, a business team iterates on it for months, it becomes genuinely valuable, and then someone asks for a capability — custom multi-step orchestration, integration with an internal system with complex auth, fine-grained cost attribution — that Copilot Studio wasn't designed for. At that point you have three options, and it's worth deciding your organization's default answer before you're under deadline pressure with a stakeholder waiting:
- Rebuild in Foundry Agent Service from scratch. Cleanest long-term outcome, highest short-term cost. Appropriate when the bot has become business-critical and the team is ready to hand ongoing maintenance to engineering.
- Keep the bot in Copilot Studio, add the new capability as an external tool call it invokes. Copilot Studio agents can call out to custom APIs — if the new capability can be encapsulated behind an API that Copilot Studio calls, you avoid a full migration. This works well when the new requirement is narrow (one new integration) rather than architectural (needs multi-agent state).
- Run both in parallel during a transition period, with Copilot Studio handling the conversational front-end and a new Foundry Agent Service backend handling the complex orchestration underneath it, connected via API. This is often the pragmatic middle path — it avoids a disruptive full rebuild while still getting engineering-grade reliability where it's actually needed.
The wrong answer, which is what happens by default without a deliberate choice, is incrementally bolting workarounds onto the Copilot Studio bot until it's doing things it was never designed for, maintained by a business team who now needs engineering support they don't have a relationship with. If your organization doesn't have an explicit escalation path for "this Copilot Studio bot has outgrown its tool," write one — it's cheaper to define in advance than to negotiate during an incident.
Where teams get this wrong
Mistake 1: choosing Copilot Studio because it's faster to prototype, then discovering mid-project that it can't do fine-grained tool orchestration. Copilot Studio's agents do connect into the broader Azure model catalog, but if your workflow needs multi-agent handoffs with custom state passed between them, you'll hit a wall and end up re-platforming under deadline pressure. Decide based on the target architecture, not the fastest demo path.
Mistake 2: choosing Foundry Agent Service for something a business team needs to maintain themselves. If the content changes weekly and the owner isn't an engineer, putting it in Foundry Agent Service creates a bottleneck where every content update requires an engineering ticket. This is a support-burden problem disguised as a technical one.
Mistake 3: no explicit boundary, so both tools sprawl independently. Without a documented decision (this is what an ADR is for), different teams pick different tools for similar problems, and you end up maintaining two parallel agent platforms with no shared observability or governance. Write the boundary down, even informally, and revisit it quarterly.
ADR template you can actually use
## Decision: [Workload name] — Copilot Studio or Foundry Agent Service?
**Context:** [what the agent needs to do, who owns it, what's the failure cost]
**Decision criteria:**
- Failure cost if wrong: [low / high — money, compliance, safety]
- Primary owner: [business team / engineering]
- Orchestration complexity: [single-turn / multi-agent with state]
- Update frequency and who updates it: [weekly by business / infrequent by eng]
**Decision:** [Copilot Studio | Foundry Agent Service]
**Consequences:** [what this commits us to, what we're giving up]Filling this out explicitly, even for workloads that feel obviously one way or the other, forces the conversation about ownership and failure cost before you're locked into an architecture.
What's next
Having decided which workloads live in Foundry Agent Service, Part 7 gets into the orchestration mechanics themselves: how to manage shared state across multiple agents and recover gracefully when one agent fails mid-task.
References
- Foundry Agent Service overview: https://learn.microsoft.com/en-us/azure/ai-foundry/agents/overview
- Copilot Studio documentation: https://learn.microsoft.com/en-us/microsoft-copilot-studio/
- Copilot Studio and Foundry integration: https://learn.microsoft.com/en-us/microsoft-copilot-studio/model-connections
- Architecture Decision Records (ADR) pattern reference: https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record