For the same intelligent agent task, today a model that is good at coding may be suitable, while tomorrow it might be necessary to switch to a cheaper model or one that requires a longer context. What is truly troublesome is not so much changing the name of the model, but rather the entire set of systems surrounding its execution: how instructions are loaded, how context is organized, how tools are invoked, where the code runs, how failures are recovered, and how permissions are managed. On October 28th, Microsoft announced that it would make available to developers and enterprises Copilot harness, which was developed by the GitHub team and has already been uniformly adopted within the company.
Microsoft explains harness as an orchestration layer outside of the model. The model provides inference capabilities, while harness is responsible for combining instructions, context, execution environment, and control measures into a task that can be completed in one go. It supports MCP, agent, skills, and plugins, and is also in charge of agent loops and sandboxes. This definition is broader than just “another model router”: routing is about deciding who will perform the task, but harness also determines how the task should be carried out, within what boundaries, and how the results should be returned to the application.
This system has been used in products such as Copilot Code, Copilot Studio, GitHub Copilot, command lines, and VS Code. The current change is that Microsoft has transformed the internally shared execution foundation into the managed capabilities within Foundry. Developers can download SDK and also run it in the cloud, without having to maintain a separate set of loops, tool integrations, and sandboxes for each model individually.
Multi-modeling doesn't involve making the dropdown list longer.
According to the official statement, this harness supports more than 20 cutting-edge models and also allows customers to bring in their own keys. It may seem like there are more model options available, but what enterprises actually gain is the ability to maintain the upper-level processes as much as possible during switching. Tasks can still use the original instructions, skills, and tools, while the underlying models can be adjusted based on quality, cost, or type of work.
This does not mean that different models have become completely interchangeable. The output formats of the models, tool usage habits, delays, and failure modes may still vary. Microsoft is responsible for continuous evaluation, routing, and optimization at the execution layer, while application teams still need to set acceptance criteria for their own business results. Hosting harness reduces maintenance work, but it cannot replace the business side's judgment of correctness and permissions.
Microsoft also revealed that the runtime has recently been ported to Rust, with the goal of reducing session overhead and the waiting time for the first token. This change occurs at the execution layer, not within the model itself. For tasks that run for long periods and frequently invoke tools, the peripheral overhead is amplified repeatedly; making the runtime lighter may have a greater impact on the overall experience than speeding up single model generation by just a few tens of milliseconds. However, the announcement did not provide a unified reduction in latency, nor can it be inferred from this that all tasks will become faster as a result.
What enterprises purchase is the responsibility for management, not a guarantee of results.
In Foundry, Microsoft is responsible for running the agent loops and sandboxes, while governance and optimization are placed in the foundational layer; customers provide instructions, skills, tools, and model selections. This division of labor is important. It hands over the responsibility of "who maintains the execution engine" to the platform, but it does not also hand over details such as "what data the tools can access," "whether a single write requires approval," and "whether the output conforms to business facts."
A unified base also brings new centralized risks. Multiple products share the same harness; improvements can be disseminated simultaneously, but defects may also affect more tasks across various aspects. Therefore, enterprises need to keep models, harness versions, tool permissions, and records of key actions; it's not enough to only record which model was ultimately used. The continuous improvement mentioned in the announcement is a direction promised by the platform, but it does not mean that customers do not need to perform regression testing.
For the development team, the most practical change is that the agent architecture has begun to shift from "building an application around a single model" to "first establishing a stable execution layer, and then integrating different models." The model still determines the upper limit of capabilities, while harness determines whether these capabilities can be constrained, observed, and reused in a real system. What Microsoft has made available is not a new "brain," but rather an exoskeleton that allows multiple "brains" to collaborate on the same platform.
For teams that have already integrated multiple models, this has also changed the unit of cost accounting: it is no longer sufficient to compare the price per million tokens; the total costs of evaluation, routing, sandboxing, session recovery, and tool maintenance also need to be calculated. harness can turn a portion of these costs into platform services, but the more options there are, the higher the requirement for documenting each actual choice and its outcome.
