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: a curated model list rather than an open catalogue (wider than it was, with Claude Fable 5.1 and GPT-6 Astra rolling out in Studio since September), orchestration that stays within the platform's patterns, and consumption pricing that grows with usage. 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.
Update, 29 September 2026: Microsoft announced at FabCon Europe 2026 that Fabric data agents are now generally available in Microsoft Copilot Studio. That makes the combination a supported production pattern: a Studio agent can use a Fabric data agent for governed questions over Fabric data instead of rebuilding that logic in the maker tool. More in our FabCon Europe 2026 recap.
Update, 8 October 2026: Both platforms moved in September. Copilot Studio's GitHub Copilot harness gained a model dropdown with experimental models and an extract node for documents, and it bills in Copilot Credits from the moment you start building. Foundry made Routines generally available, so agents can run on a schedule, after a delay or in response to events in systems such as GitHub and Teams, and added voice agents and long-running resilience in public preview, plus a rubric evaluator and Agent Optimizer that Microsoft said would be generally available later in September. The heuristic above still holds, but scheduled, event-driven agents are now a native Foundry pattern - see Foundry Routines and how to evaluate agents in Foundry and Copilot Studio.
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
- Microsoft Copilot Studio documentation
- Microsoft Foundry documentation
- Fabric data agent concepts
- Bringing governed analytics into the flow of work: Fabric Analytics at FabCon Europe 2026 (Microsoft)
- Ship agents faster with expanded model choice, voice agents and continuous optimization (Microsoft Azure Blog)
- What's new in Copilot Studio (Microsoft Learn)
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 offers a curated list of models chosen by Microsoft, which now includes Anthropic and OpenAI options such as Claude Fable 5.1 and GPT-6 Astra, plus experimental models on the GitHub Copilot harness. 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 in Copilot Credits, simple to start and priced on usage; agents on its newer GitHub Copilot harness are charged from the moment you start building. 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.
