Microsoft is selling the harness behind GitHub Copilot as a managed Foundry service

Microsoft has made the agent harness behind its Copilot products available to outside developers. In an announcement on Oct. 28, the company said Foundry customers can now build agents on the same multi-model harness that GitHub engineers created and Microsoft has adopted company-wide.

One harness across Microsoft’s Copilot surfaces

Microsoft describes a harness as everything around the model: the orchestration layer that supplies instructions, context, an execution environment and controls. The company says the Microsoft Copilot harness already powers Copilot Code, Copilot Studio, the GitHub Copilot app, the CLI and VS Code, among other products.

Through Microsoft Foundry, it is now offered as a fully managed way to build agents that reason, use tools and finish long-running tasks. According to Microsoft, the harness supports open standards such as MCP and agent skills, as well as agent plugins.

The model side is a central selling point. Microsoft says the harness works across model families, with more than 20 frontier models plus bring your own key, and that it can route work to suitable models by task so customers do not have to evaluate every new release themselves. The post does not name the models or explain how the routing decides.

Microsoft also says it recently ported the harness runtime to Rust, which it credits with lower session overhead and a faster time to first token. No figures were given. The company describes the result as “industry-leading performance”, a claim that has not been independently verified.

On delivery, there are two routes: an SDK to download, or running the harness in the cloud with Foundry managing it. In the managed setup, Microsoft says it runs the agent loop and the sandbox with governance and optimization built in, while customers supply instructions, skills, tools and the choice of model. Microsoft adds that its platforms stay open, so other harnesses and frameworks can still be brought in.

What developers can actually use today

The announcement post itself gives no pricing, regions or preview status. Those details are in our earlier report on the Foundry Agent Service version, based on Microsoft’s developer blog: it is a public preview, runtime is free until Dec. 1, 2026, and after that sandbox compute is billed at $0.0994 per vCPU-hour and memory at $0.0118 per GiB-hour, with model inference and separately billed tools charged on top. That report also notes that the harness must be chosen when an agent is created, and that switching an existing agent is not yet supported.

For readers who already use GitHub Copilot, the change is less about a new product than about access. Until now the engine was something they used inside Microsoft’s tools. Now it can be the base for their own agents, for example for internal workflows that need long-running tasks and a sandbox.

Why a maintained harness matters more than the model

The technical argument in the post is that the model is only part of what makes an agent work. Context handling, tool calls, permissions, recovery after failures and token efficiency all sit in the harness, and each model family behaves differently inside it. A team that supports several models must tune and test all of that for each one, and redo it whenever a better model appears. Microsoft’s pitch is that it absorbs this work, and that improvements made for one surface carry to the others.

The idea of a shared harness also fits the company’s wider direction. Microsoft said in a June 2 post, as summarized in our earlier report, that Foundry accepts agents built on rival SDKs and frameworks, including the Claude Agent SDK and LangGraph. The Copilot harness therefore sits alongside those options rather than replacing them, and Microsoft describes it as a step toward a stronger system around the model that preserves choice.

It also connects to other recent changes in the Copilot family. GitHub’s Copilot app has just gained multi-repo Projects and a computer use mode, one of the surfaces Microsoft lists as running on this harness. That illustrates the point of the standardization: a change to the shared layer can reach products at once, though Microsoft has not said how quickly.

What the announcement leaves unanswered

Much of the post rests on Microsoft’s own statements. It offers no benchmarks, no latency or cost comparison with other harnesses, no list of supported models and no detail on how routing works. The claims that the harness is battle-tested at the scale of millions of users, and that it had the highest satisfaction among developers, come from the company and are not backed by published data in the post.

It is also unclear how the SDK differs from the managed Foundry option in features and licensing, or whether bring your own key is available in both. Teams considering a move will need those answers, along with the post-December pricing, before judging whether handing the agent loop to Microsoft is cheaper than maintaining their own.