Microsoft Copilot Studio vs Microsoft Foundry: Which AI Agent Platform Should Your Business Choose?

Published 18 August 2026. Every product claim, price and availability status below was verified against Microsoft's own documentation on that date, and each capability is marked GA or Preview as Microsoft labels it. This is a fast-moving pair of platforms; check the linked source before you commit budget to anything here.

The question usually arrives with two competing internal proposals attached. One team wants Copilot Studio because they can ship next month. The other wants Microsoft Foundry because Copilot Studio "won't scale." Both are usually right about their own case and wrong about the other one.

The framing is the problem. Microsoft does not position these as competitors — its own Cloud Adoption Framework recommends composing them: "Use Copilot Studio's low-code interface with Foundry's advanced models to handle sophisticated use cases while maintaining SaaS security and reliability." They sit at different points on an abstraction axis, not on opposite sides of a bake-off.

So the useful question is not which platform, but which workloads go where — and what does that commit us to.

The three questions that actually decide it

Strip away the feature comparisons and one thing determines everything downstream:

You are not choosing a product. You are choosing who owns the agent's runtime — and cost shape, governance enforcement and delivery speed all follow from that single choice.

Question three is the one that gets skipped in every proposal I review. A platform decision is a staffing decision wearing a technical costume. If the honest answer to "who fixes this at 9pm on day ninety" is a business analyst, the runtime should not be a container you own.

What each one actually is, as of August 2026

Two rows surprise people. Foundry cannot reach Dataverse or the Power Platform connector estate as first-class tools — Logic Apps or an MCP shim is the documented bridge. And if you intend to sell the agent, Copilot Studio is the blocker, not Foundry: only Teams SDK, Microsoft 365 Agents SDK and Foundry agents reach the Microsoft Commercial Store.

Three changes in 2026 retired most of the older advice

If your platform standard was written before this spring, it is probably wrong in three specific ways.

Governance stopped being a platform argument. Agent 365 reached general availability on 1 May 2026 as a single registry and control plane spanning Copilot Studio, Foundry, partner-platform and other-cloud agents. On 1 July 2026, agent security for both platforms moved to requiring an Agent 365 licence. Worth flagging to your security team if nobody has: Microsoft's transition guidance states that tenants configured to Block on the previous rules stopped blocking on 1 July 2026 unless those rules were re-authored. That is a silent loss of enforcement — the kind that surfaces during an incident rather than a review.

Reach stopped being a reason to accept low-code. Publishing a Foundry agent into Microsoft 365 Copilot and Teams became generally available on 10 June 2026 — "one governed publishing pipeline instead of separate rebuilds per surface," in Microsoft's words. Until then, "it's the only way into M365 Copilot" was the strongest argument for building in Copilot Studio regardless of engineering fit.

Autonomy stopped being a differentiator. Microsoft's own comparison now lists retrieval, task and autonomous agent types for both. Meanwhile Copilot Studio split into three harnesses — separate runtimes — and agents cannot be moved between the standard and GitHub Copilot harnesses. So "Copilot Studio can do X" is now an incomplete sentence: name the harness, because the same capability can be GA on one and preview on the other.

The cost question is really two different shapes

Most comparisons put two price lists side by side. That is not the useful comparison, because the two platforms do not bill in the same shape.

Copilot Studio is predictable per unit, variable by volume. There is no paid maker seat, and everything runs on Copilot Credits at $0.01 each, or $200 a month for a 25,000-credit pack whose unused credits do not roll over. The rate card is published and stable, so you can model it precisely given a volume forecast. The trap is that rates span two orders of magnitude: 1 credit for a classic answer, 2 generative, 5 an agent action, 10 tenant graph grounded, 100 per ten premium tool responses. Agent design, not usage growth, moves the bill — changing a knowledge pattern can be a five-fold cost event at flat traffic. Voice is the sharpest edge at 75 credits a minute, or $45 per conversation-hour.

One line deserves a lawyer's attention: employee-facing Copilot Studio usage is included in a Microsoft 365 Copilot licence when the agent runs under a licensed user's identity — but only on Microsoft channels, with voice and Work IQ excluded, and subject to "fair usage limits" Microsoft "reserves the right to update." An uncapped, unilaterally variable term underneath your business case is worth raising in negotiation rather than discovering later.

Foundry has no platform fee and no published unit prices. Microsoft states the platform is free and features bill at normal rates. What the overview pages omit is that the standard agent setup requires customer-owned Cosmos DB, Storage, AI Search and Key Vault, with Cosmos provisioned at a documented 3,000 RU/s minimum — a three-figure monthly floor before a single token is consumed, and no Microsoft page connects that compliance-driven choice to its cost.

Harder still: provisioned throughput rates, hosted-agent compute rates and the dollar value of a Claude Consumption Unit are not published anywhere in Microsoft's documentation. I would treat any third-party figure claiming otherwise with suspicion. A buyer cannot build a defensible Foundry cost model from public information alone — a procurement finding that belongs in the business case as a stated assumption, not a confident number.

Two more things worth knowing. Microsoft's own worked example of agentic retrieval costs $4.32, of which $3.30 is Azure AI Search reranking and $1.02 is the model — so teams budgeting for "the model" underestimate by roughly four times. And the commercial commitment has decoupled from the platform: since February 2026 each Agent Commit Unit is worth "$1 of Copilot Credit or Microsoft Foundry usage," so you no longer have to pick a platform in order to buy capacity.

The governance asymmetry nobody quotes

Put Purview's two capability tables side by side and they look identical — ticks for DSPM for AI, auditing, classification, sensitivity labels, DLP, insider risk, eDiscovery and compliance manager on both.

The parity is superficial, and the footnote is where the decision lives. Microsoft's Foundry documentation states that Purview data security policies apply to API calls using Entra ID authentication with a user-context token, and that "for all other authentication scenarios, user interactions are displayed in Microsoft Purview Audit and AI Interactions with classifications in DSPM for AI Activity Explorer only."

Read plainly: an app-only authenticated Foundry agent — the default pattern for an autonomous backend agent — is observed but not enforced. DLP does not block it. If your control narrative to an auditor is "Purview prevents the agent from exfiltrating regulated data," that holds for user-context calls and not for the unattended ones.

Copilot Studio has its own version. Label enforcement there is bound to the knowledge source — SharePoint, OneDrive, Dataverse — not to the agent, so an agent grounded elsewhere sits outside it.

There is also a registration asymmetry worth checking in your own tenant. Copilot Studio issues an Entra agent identity automatically on creation and, from July 2026, this cannot be disabled. For Foundry, Microsoft's blog says every agent gets an identity and auto-registers in Agent 365, but the Entra reference documentation does not name Foundry and describes an explicit developer integration step. I flag that as documentation drift, not settled fact — verify rather than assume parity.

Gartner's framing is the most useful third-party lens here: it predicts that "by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur," and argues that binary governance — locked down or fully trusted — is the root cause. That is analyst prediction, not survey data, but the implication holds: tier controls by agent autonomy, not by build platform.

You compose them. You do not migrate between them.

This is the constraint that should shape the decision most, and it is the least discussed.

There is no documented migration path from a Copilot Studio agent to a Foundry-hosted agent. Foundry's migration guidance covers Foundry-internal and OpenAI Assistants moves and does not mention Copilot Studio at all. The one Microsoft guide that names Copilot Studio — for a within-platform identity change — states there is no automated or in-place path, calls the approach "recreate and deprecate," and recommends ten to fourteen days of parallel validation.

To be precise about the strength of that claim: it is an argument from documented absence, and Microsoft has not said a cross-product tool will never exist. But plan as though a Copilot Studio agent that outgrows the platform is a rebuild, because today that is what it is.

What Microsoft offers instead is composition, and three of the four paths are GA. The one I would design around is MCP — the only interop surface generally available on both sides at once, which makes it the natural place to put a governed tool boundary both platforms consume.

A selection rule you can put in a standard

This next section is my own construct — author-proposed guidance, not Microsoft documentation. It is the rule I use in architecture reviews.

Two rules go with it. Decide the platform per workload and write down the reason — a one-line justification per agent is what stops the estate drifting toward whichever tool the last enthusiastic team preferred. And never let a preview status carry a production dependency. The Copilot Studio to Foundry agent call, the Foundry IQ connection and the inbound A2A endpoint are all preview; A2A in particular is text-only, non-streaming and JSONRPC-only on the receiving side. That is a prototype path, not an integration architecture.

What I would actually do

Run both, deliberately, with a written boundary. Put the long tail of business-process agents in Copilot Studio, where the connector estate and free maker licences make a failed experiment cost a few hundred credits rather than a sprint. Put the agents that carry real authority, touch regulated data or need a runtime you control in Foundry — and staff those like software, not like documents.

Then govern the whole estate through Agent 365, tier controls by how much autonomy each agent actually has, and re-read the boundary document quarterly. Three of the assumptions in this article were sound a year ago and are wrong now; three more will be by Christmas.

The platform question feels like the hard one because it has a vendor page attached. It isn't. The hard question is how much authority you are willing to delegate to a system that cannot be cross-examined afterwards — and neither platform answers that for you.

If you are choosing between these platforms right now — or you already have both and no written boundary between them — that is the work Avalon does: platform selection assessments with the cost shapes modelled honestly, agent estate reviews against Agent 365 and Purview enforcement boundaries, tiered governance frameworks based on agent autonomy rather than build tool, and target architectures for the composition paths that are actually GA. It sits at the centre of my enterprise AI and security practice, and the contact page is the best way to start a conversation.

For the deeper technical treatment of the Foundry side, see Microsoft Foundry: enterprise architecture for production-grade AI agents. For how these platforms sit within the wider Microsoft portfolio, see the Microsoft AI stack explained.

Sources

All verified on 18 August 2026. Where two Microsoft pages disagree, the disagreement is named in the text rather than resolved by guesswork.

Positioning and comparison — CAF: plan your AI agent technology strategy (opens in a new tab) · Custom engine agents for Microsoft 365 (opens in a new tab) · Microsoft agents hub (opens in a new tab)

Copilot Studio — What is Copilot Studio (opens in a new tab) · Choose a harness (opens in a new tab) · Knowledge sources (opens in a new tab) · Select a primary AI model (opens in a new tab) · Bring your own model for prompts (opens in a new tab) · Connect to a Foundry agent (preview) (opens in a new tab) · Entra Agent IDs (opens in a new tab) · Billing rates (opens in a new tab) · Licensing and billing (opens in a new tab) · Copilot Studio pricing (opens in a new tab)

Microsoft Foundry — Agent Service overview (opens in a new tab) · Hosted agents (opens in a new tab) · Tool catalog (opens in a new tab) · Standard agent setup (opens in a new tab) · Publish to Microsoft 365 Copilot and Teams (opens in a new tab) · Migrate to the new Agent Service (opens in a new tab) · Claude Consumption Unit billing (opens in a new tab) · Foundry pricing (opens in a new tab) · Agentic retrieval overview (opens in a new tab)

Governance — Agent 365 overview (opens in a new tab) · Agent 365 general availability (opens in a new tab) · Transition agent security to Agent 365 (opens in a new tab) · Purview for Copilot Studio (opens in a new tab) · Purview for Microsoft Foundry (opens in a new tab) · What are agent identities (opens in a new tab) · Migrate Copilot Studio agents to Agent ID (opens in a new tab) · Gartner on AI agent governance, 26 May 2026 (opens in a new tab)

---

Published 18 August 2026; all sources verified on that date. Availability and pricing for both platforms change monthly — verify against Microsoft Learn before making a commitment. The selection rule in this article is author-proposed guidance, not Microsoft documentation. No client, employer or engagement is named anywhere in this article, and any scenario described is an illustrative composite rather than a description of specific customer work.