Microsoft Corporation (Nasdaq: MSFT) has made the orchestration layer behind several Copilot products available through Microsoft Foundry, giving enterprises a managed way to build agents that can use tools and work across more than one model family. The move shifts a difficult piece of agent infrastructure—deciding how a model receives context, invokes tools and completes a task—from an internal platform project to a service customers can adopt.
Microsoft calls that layer the Copilot harness. The company said it already powers Copilot Code, Copilot Studio, the GitHub Copilot app, the command-line interface and Visual Studio Code. In Foundry, the harness is intended to let developers build agents without changing the surrounding runtime each time a team evaluates or adopts a different model.
That matters because the model is only one part of a production agent. Microsoft describes the harness as the component that supplies instructions, context, an execution environment and controls. It also supports open standards including Model Context Protocol, agent skills and plugins, according to the company. For an enterprise team, those functions determine whether an agent can connect to approved systems, preserve context across a task and operate inside the guardrails required for a business workflow.
The company said the harness works with more than 20 frontier models as well as bring-your-own-key options, and can route work to an appropriate model or models based on the task. That architecture can reduce the engineering burden of maintaining separate model adapters and routing logic. It does not remove the need for customers to evaluate model quality, cost, data handling and reliability for their own use cases.
Microsoft said GitHub engineers built the harness and that it has been adopted across the company’s Copilot experiences. The runtime was recently ported to Rust, which Microsoft said reduced session overhead and time to first token. The company did not provide independent benchmarks, service-level commitments or pricing in the post, so IT buyers will need to validate performance, availability and commercial terms before treating those operational claims as deployment results.
Foundry customers can use a software development kit or run the harness as a managed cloud service, Microsoft said. In that model, Microsoft operates the agent loop and sandbox while customers provide instructions, skills, tools and model choices. The division of responsibility is significant: a managed runtime can centralize common platform work, but it leaves each organization responsible for access design, tool permissions, data classification and the business controls around an agent’s actions.
The practical appeal is consistency. An organization that builds separate agent stacks for coding, customer-service, operations and internal knowledge work can accumulate duplicated routing, tool-integration and observability work. A common harness may make those shared controls easier to standardize while allowing teams to vary the model selected for a given workload.
Compared with the legacy approach of treating each model change as a new integration project, Microsoft is positioning the harness as a durable control plane around agent workloads. The competitive question is no longer only which model performs best; it is whether an enterprise can change models without rebuilding the runtime, governance and tool connections that make an agent usable in production.