In Short: Makers on One Side, Engineers on the Other
Microsoft ships two agent-building platforms, and the choice is less about features than about who is building and how much control the build needs. Copilot Studio is the low-code path: makers assemble conversational agents from topics, connectors and knowledge sources, and deploy them into Teams and Microsoft 365 without writing services. Microsoft Foundry is the pro-code path: engineers compose models, tools, orchestration and evaluation into custom agents deployed like any other software.
Most organisations of any size end up with both, deliberately. The mistake worth avoiding is building an engineering-grade problem in a maker tool, or paying engineering prices for a FAQ bot.
What Copilot Studio Is Good At
Copilot Studio earns its place when the agent's job is conversational and the logic is business process rather than computation.
- Agents over documented knowledge: policies, procedures, product information
- Guided processes with structured steps, approvals and handoffs to humans
- Hundreds of prebuilt connectors into Microsoft 365, Dynamics and third-party systems
- Native deployment into Teams and Microsoft 365 Copilot, where users already are
- Governance through Power Platform environments, DLP policies and admin controls that IT already operates
Its constraints are the flip side: limited model choice, orchestration that stays within the platform's patterns, and consumption pricing that grows linearly with conversation volume. None of that matters for a bounded internal agent. All of it matters for a high-volume, deeply customised one.
What Microsoft Foundry Is Good At
Foundry, the platform formerly known as Azure AI Foundry, is where Microsoft has concentrated its serious agent infrastructure: the Foundry Agent Service for hosting and orchestrating agents, a model catalogue spanning Microsoft's own MAI family, OpenAI, Anthropic and open-source models, and the evaluation, safety and observability tooling an engineering team expects.
- Full model choice, including choosing models per task and swapping as economics change
- Custom tools: your APIs, your databases, your Fabric estate through governed connections
- Orchestration for multi-step and multi-agent patterns
- Evaluation pipelines, tracing and content safety as first-class features
- Azure consumption pricing that rewards engineering effort at volume
The cost is exactly what it looks like: this is software engineering, with everything that implies about skills, lifecycle and ownership. Our breakdown of the agent cost stack covers the consumption side in detail.
The Comparison That Matters
Feature tables age quickly in this space; the durable differences are structural.
- Builder: makers and business technologists (Studio) versus software engineers (Foundry)
- Control: opinionated platform patterns versus full architectural freedom
- Models: managed selection versus open catalogue including MAI, OpenAI and Anthropic
- Cost shape: per-conversation credits versus raw consumption you engineer down
- Governance home: Power Platform admin versus Azure policy and DevOps
- Time to first agent: days versus weeks
A useful heuristic: if the agent's failure would be embarrassing, Studio is fine; if its failure would be expensive, you want Foundry's evaluation and control; if its job is answering questions over governed Fabric data specifically, a Fabric data agent may beat both.
The Pattern That Wins: Studio in Front, Foundry Behind
Microsoft's own architecture increasingly assumes the two compose: complex agents built and evaluated in Foundry, surfaced to users through Copilot Studio and Microsoft 365 Copilot. Business users get one familiar interface; engineering owns the parts that need owning; each layer is billed and governed on its own terms.
For a data-platform organisation, that usually lands as: Copilot experiences and Studio agents as the front door, Foundry for the agents that reason and act across systems, and Fabric data agents wherever the task is analytical questions over the lakehouse. The layers are covered in our six-layer agent stack overview.
Start from the use case, pick the lowest platform that genuinely carries it, and promote to the next layer only when the requirements force you. That discipline, more than any feature comparison, is what keeps agent programmes affordable.
Sources and Further Reading
Frequently asked
Audience and altitude. Copilot Studio is a low-code platform for makers and business technologists building conversational agents with connectors, topics and approvals. Microsoft Foundry is a pro-code platform for engineering teams building custom agents with full control over models, orchestration, evaluation and deployment.
Copilot Studio runs on Microsoft-managed models with limited selection. Foundry exposes a broad catalogue - Microsoft's MAI models, OpenAI, Anthropic and open-source options - with the ability to swap and mix models per task, which matters as model economics shift.
Copilot Studio bills agent usage against purchased credit or message allowances, simple to start and priced per conversation volume. Foundry is Azure consumption: tokens, hosting and services, which scales better at volume but requires active cost engineering. High-volume agents usually run cheaper on Foundry; low-volume business agents are usually simpler on Studio.
Yes, and this is increasingly the recommended pattern: agents built in Foundry can be surfaced through Copilot Studio and Microsoft 365 Copilot, so business users meet one interface while engineering owns the complex agents behind it.
Match the platform to the use case, not the team's ambition. A bounded conversational agent over documented processes: Copilot Studio. An agent that must query governed data, call internal APIs and be evaluated seriously: Foundry, or a Fabric data agent if the scope is purely analytical questions over Fabric data.
