Microsoft Opens the Copilot Harness: One Agent Foundation, Swap Models Without Rewriting

On October 28, Microsoft announced on its official blog that it is opening up the agent "harness" behind its Copilot products, available to developers and enterprise customers through Microsoft Foundry. It reads like another platform announcement, but the interesting part is not that there is one more product. It is that Microsoft moved the competitive focus one layer down: models can be swapped, the harness is the asset. For a year the contest was about whose model was strongest. This move says models will rotate, while the machinery that puts models to work is the long-term asset.

Start with the core facts. Microsoft defines a harness as "everything around the model": the orchestration layer that gives an agent the right instructions, context, execution environment, and controls to accomplish meaningful work. The same harness powers Copilot Code, Copilot Studio, the GitHub Copilot app, the Copilot CLI, and VS Code. It was built by GitHub's engineering team and has been adopted company-wide at Microsoft. What is now open is that same harness, reached through Microsoft Foundry: download the SDK and run it yourself, or run it in the cloud managed by Foundry, where Microsoft runs the agent loop and sandbox with governance and optimization built in. Developers bring the instructions, skills, tools, and model choice.

What exactly is being opened

First, multi-model operation. Microsoft says the harness is built to perform across model families, supporting more than 20 frontier models plus bring-your-own-key, routing work to the right model or models based on the task. Read that carefully: the promise is not that every model works equally well, but that you no longer have to rebuild your orchestration layer to change models. The cost of switching models drops from "rebuild the orchestration" to "change a model selection". Note, though, that the blog gives no cross-model benchmark numbers and does not explain what the routing policy looks like: by cost, by speed, by task type? That is unstated, and can only be verified by using it.

Second, open standards. The harness supports open standards such as MCP, plus agent skills and agent plugins. That matters because it decides whether the harness only connects to Microsoft's own things. Microsoft adds at the end that its platforms remain open and interoperable, so developers can keep bringing any harness and framework they want. That sentence is aimed at enterprises worried about lock-in. Honestly, though, supporting open standards is not the same as zero-cost switching: once skills, tools, and governance configuration are written deeply in this harness's way, migration still costs real work.

Third, performance engineering. Microsoft says it recently ported the harness runtime to Rust, delivering industry-leading performance with reductions in session overhead and time to first token. But the post gives no figures: reduced by how much, against what baseline, measured in what scenario, all unstated. So that claim can only be heard as a vendor statement for now, not a measured conclusion. Likewise, the claim that the harness is battle-tested at the scale of millions of users and hundreds of real-world use cases is Microsoft's own product scale as endorsement, not an independent evaluation.

Fourth, the division of labor. Microsoft states it plainly: Microsoft runs the agent loop and sandbox, with governance and optimization built in from day one; you bring the instructions, skills, tools, and model choice. That division is friendliest to small teams: instead of building a model router plus sandbox plus approvals plus observability, you write only the business part, the instructions and tools. The other side of the division is that the defaults for governance rules, sandbox boundaries, and optimization strategy sit with Microsoft. What tools your agent may call, how much it may spend, how it stops on error: check those defaults before deploying, rather than accepting them wholesale.

Why now: models rotate, harnesses settle

The blog opens with the timing argument: a frontier model today might fall behind tomorrow, and building your own harness or model router to keep up is painful, slow, and even harder to maintain. That argument lands with special context on October 28: the same day, GitHub made Copilot Fusion generally available, handing model selection itself to the platform; the same day, the GitHub Copilot SDK began its transition to the Microsoft Copilot SDK, reframing the SDK from "the programming interface for GitHub Copilot" to "the programming interface for the Microsoft Copilot harness". Put together, Microsoft's intent is clear: let the market fight over the model layer, and hold the layer above the models.

For developers, that changes the selection logic. Selection used to start with "which model". It may now start with "which harness". Models can be swapped inside a harness, but once a harness is chosen, skill formats, tool integrations, governance configuration, and observability data all grow around it, and migration costs an order of magnitude more than switching models. So when evaluating a harness, the real questions are not "how many models does it support" but: can my skills and tools move out unchanged? Can governance rules be changed to meet my compliance needs? Can billing be broken down per task? The answers to those three matter more than the "20+" figure.

For enterprise customers, there is a more practical consideration: the Foundry-managed version and the self-run SDK version are two different paths. Managed is less work: Microsoft runs the loop, the sandbox, the optimization, but data and execution also live in Microsoft's cloud. Self-run is more control, but maintenance returns to you. The blog lays out both paths without spelling out how they differ in features, billing, and compliance. Get that comparison table from Microsoft's sales team or documentation before deciding; do not decide from two sentences in a blog post.

Three things not to rush into

First, do not equate "available" with "generally available". Microsoft's blog says the harness is available through Foundry; it does not describe the harness itself as generally available. Same-day Foundry news was reported by third parties as a public preview in Foundry Agent Service, alongside general availability of long-running resilience for hosted agents, but those points come from third-party reporting, not from Microsoft's blog post, and this article marks them as such rather than treating them as official commitments. Public preview means interfaces, billing, and limits can change; before wiring a production system to it, confirm whether the preview terms contain any limitation you cannot accept.

Second, do not be misled by "20+ models". Supporting more than 20 models does not mean all 20 work equally well, and it does not mean free. Each model has its own price and rate limits; the harness routes for you, but the bill is still charged per model. The real test is on your own tasks: run your own set of real tasks for two weeks in two groups, one with a fixed model and one with harness routing, and compare task success rate, token spend, and latency before deciding whether to hand routing over.

Third, do not skip the governance line. The blog repeats that governance is built in from day one. For enterprises that is a selling point; for developers it is a checklist: do tool calls need approval, can approvals be graded by path and risk, does the agent stop or merely warn when it exceeds budget, can the sandbox reach internal network resources? None of these questions are answered in the blog; the answers live in Foundry's documentation and configuration. List the governance checklist before adopting, find each item in the documentation, and plan as if anything you cannot find is unsupported.

The cost of building your own harness: why Microsoft dares to say "don't build one"

To understand the blog's confidence, price out building a harness yourself. On the surface it is three things, call the model, give it tools, run the loop, and an open-source framework gets you running in a week. The expensive parts come later, and none of them can be outsourced easily. First, evaluation: when the model changes, the same prompts and tool combinations behave differently, so you need a fixed task set that you re-run on every model change and every prompt change, or you never know whether things got better or worse. A harness without an evaluation set gambles on every upgrade. Second, cost control: once an agent loop runs, token spend is not as predictable as a single model call; a task might loop three steps or thirty, and without budget caps and circuit breakers, the bill surprises you at month's end. Third, security boundaries: a sandbox is not just "put commands in a container"; tool-call approvals, sensitive path isolation, secret injection, and rollback on error each need separate design and testing.

Added up, that is what Microsoft means by "maintenance is harder than building". Building is one-off; maintenance is continuous: models change monthly, tool interfaces change quarterly, new security threats arrive weekly. A team of three to five people maintaining that stack alone is effectively assigning one person full-time to babysitting the harness. That is the real selling point of a managed harness: it sells outsourced maintenance, not features. For a small team the math is simple: if nobody on your team owns the harness full-time, the labor a managed version saves usually costs more than its fee; if your team already has a mature harness and evaluation set, the migration cost may outweigh the benefit, and there is no reason to move for the sake of a "same as Microsoft" label.

One cost is often overlooked: observability. When an agent goes wrong, you need to answer three questions: which steps did it take, which tools did each step call, and how much did it cost? Without those three records, debugging an agent is pure guesswork. Microsoft mentions governance and optimization built in, and observability should be part of that, but the blog does not detail the granularity: can you break it down by task, by tool, by model? How long is data retained? Can it be exported to your own systems? Confirm each item during evaluation, because once you adopt the managed version, the observability vocabulary is the platform's, and changing it later is hard.

A trial path: one non-critical task, two weeks

If you want to try this harness, take three steps. First, run a minimal task locally with the SDK: give the agent a clear task whose failure would not hurt, such as reading a public document and turning it into a table, and verify the integration cost and basic behavior before touching core business. Second, run the same task on the Foundry-managed version and compare the two paths: how long deployment takes, where governance configuration lives, whether billing breaks down per task. Third, write your governance checklist and find each answer in the documentation: can tool approvals be graded by path, does exceeding budget stop or warn, can the sandbox isolate internal resources, can observability data be exported? After those three steps, your judgment of the harness will be based on your own measurements, not on the blog's impression.

There are also three cases for holding off. First, you already have a harness that runs smoothly, with skills, evaluation, and governance all in place; the benefit of switching does not cover the migration cost, so keep yours and wait another version. Second, your compliance rules require data to stay in your own cloud or data center, which rules out the managed version outright; only the self-run SDK version is in play, and you should first confirm whether its features match the managed version. Third, your task does not need an agent loop at all: a single model call plus a fixed workflow solves it, so do not introduce a whole harness for the word "agent". Simple tasks deserve simple architecture. A harness is built for long tasks, many tools, and repeated decisions, not for every task.

Finally, do not confuse this article with other "harness" stories on this site: the October 8 Harness acquisition of Augment Code is about a company named Harness acquiring another company; the October 21 Vercel durable-harness is about an open-source crash-resilient harness; the mid-October Chainguard Harness is a product that hunts vulnerabilities with AI. They are not the same thing as the Microsoft Copilot harness, and the shared word is a trap. This article is only about Microsoft's harness: built by GitHub's team, adopted company-wide, now open through Foundry. When evaluating, match the full name, not just the word "harness".

In one sentence: Microsoft is not selling a stronger model here, but the promise that models can be swapped freely without rewriting the harness. Whether that promise is worth anything depends on three things: whether your skills and tools can move out, whether governance rules can be changed to your requirements, and whether routing genuinely saves more than choosing yourself. For small teams, trying one non-critical task for two weeks before handing over a core task is the cheapest way to find out.