Two doors, one runtime

The question comes up in every other workshop, and it almost always arrives phrased wrongly: which is better, Copilot Studio or Microsoft Foundry?

The answer is unsatisfying and still the right one. These are not competitors. They are two entrances to the same thing, and the choice has less to do with technology than with who maintains the thing in two years.

What Microsoft built

Since Build 2026 the structure is clearer than before. Microsoft describes an agent platform in three layers: build, deploy, operate.

At the bottom sits the Microsoft Agent Framework, open source, stable for Python and .NET. It brings the enterprise foundations of Semantic Kernel together with the multi-agent orchestration of AutoGen. The choice between the two disappears, and that was overdue.

Above it sits the Foundry Agent Service with hosted agents as a managed runtime. Each session runs in its own sandbox with isolated compute, memory and file system. The notable part is that the runtime is framework-agnostic: agents from the Microsoft Agent Framework, the GitHub Copilot SDK, LangGraph or other SDKs run there without rewriting.

And Copilot Studio is the low-code door into the same world, by now with the GitHub Copilot harness as the runtime underneath.

What that means in practice: the question is no longer which platform can do more. The question is which surface fits your team.

The decision criteria that actually hold

Who maintains it in two years? That is my first question, not my last. An agent built by the business department that only IT can change is dead the moment the process changes. Conversely: an agent hanging off a core process that nobody can review because it lives inside a designer is an operational risk.

Is there a repository? If your team already works in git, reviews pull requests and has a pipeline, then Foundry is the smaller break. If not, Foundry will not cause those practices to appear. It will cause nobody to touch the agent.

What does the path to the user look like? Something important shifted here. Since June 2026, Foundry agents can be published directly to Microsoft Teams and Microsoft 365 Copilot, with identity, permissions and policy carried through. The old reflex of "if it has to land in Teams, it must be Copilot Studio" no longer holds.

How deep does the requirement go? If you need your own evaluation loops, fine-grained observability over OpenTelemetry or custom orchestration patterns, Copilot Studio is the wrong door. If a departmental process needs to run in three weeks and will then be maintained by the people who understand it, Foundry is the wrong door.

How is it billed? Copilot Studio on the GitHub Copilot harness bills through Copilot Credits, from the first build step. Foundry bills through Azure, with mechanisms your cloud cost centre already knows. That is not a detail. It is frequently the point where a decision actually turns.

My rules of thumb

I now use four sentences to settle the decision in a meeting:

Copilot Studio, when the process belongs to a business department, changes frequently, and the requirement can be described in language. Invoice intake, onboarding assistant, internal helpdesk. The GitHub Copilot harness handles multi-step processes with files, tools and exceptions, and that covers the vast majority of these cases.

Foundry, when the agent is part of a product, borders a codebase, or needs its own orchestration. Anything meant to be built, tested and deployed in a pipeline.

Both, if you are honest. The most workable arrangement in larger organisations: Foundry for the capabilities that are hard and shared, Copilot Studio for the surfaces that sit close to the business and call those capabilities. Over A2A and MCP that now works cleanly.

Neither, when a workflow would do. That is the recommendation given least often and correct most often. If a procedure runs identically every time, it does not need an orchestrator reasoning about it afresh. It needs an automation.

The point I consider most important

Microsoft explicitly treats the agent harness as a flex point rather than a commitment. Investments in LangGraph, the GitHub Copilot SDK or the Claude Agent SDK carry over; hosted agents accept them without rewriting.

That is strategically relevant. The last few years consisted of every platform having its own agent model, where switching meant rebuilding. If the runtime is framework-agnostic and skills travel between systems as Markdown, then lock-in shifts from the application layer to identity, governance and data. Which is where it always was.

For architecture decisions this means: the choice of build surface has become more reversible. The choice of where identity, context and logging live has not. Give the second question the care you used to put into the first.

What I cannot judge yet

How well the boundary between the two doors holds day to day. On paper it is one runtime with two surfaces. In practice Copilot Studio has its own solution and ALM model over Dataverse, Foundry has one over Azure resources and repositories. Running both means running two operating models, and that appears in no architecture diagram.

One note in my own interest: I deliberately avoid citing concrete Agent Framework API signatures here. They change between package versions, and a wrong signature in a text somebody copies is worse than none. If you want to get started, begin with the repository and the quickstart documentation, not with a blog post.

Sources

• Build and run agents at scale with Microsoft Foundry at Build 2026, Microsoft Foundry Blog, 2 June 2026
• Choose a harness, Microsoft Learn
• Publish Foundry agents to Microsoft 365 Copilot and Teams, Microsoft Learn
• microsoft/agent-framework on GitHub