Microsoft brings Copilot harness to Foundry to build multi-model agents

What is the Copilot harness

The model provides the ability to reason and generate responses. The harness coordinates the rest of the cycle: which instructions the agent receives, what context and tools it can use, where it executes actions and what limits apply. That is why two agents based on the same model can behave differently when they use different harnesses.

Microsoft describes the Copilot harness as an orchestration layer with support for patterns like MCP and Agent Skills, plus plugins. The idea is to improve or maintain this layer without requiring each team to build its own model router, execution environment and controls.

What Microsoft announced

According to the official announcement, the harness already powers experiences like Copilot Code, Copilot Studio, the GitHub Copilot app, the CLI and VS Code. The news is offering it also through the Microsoft Foundry Agent Service, as a managed option to build agents that use tools and run long tasks.

Microsoft says the harness works with more than 20 frontier models and accepts bringing your own key. It also describes model routing based on the task, instead of requiring the team to choose and maintain a model manually for each step. The company runs the agent loop and the sandbox in Foundry; builders provide instructions, skills, tools and the model choice.

For those who prefer to integrate the capability into an application, Microsoft points to the GitHub Copilot SDK. The SDK and the managed service are different paths: one lets you integrate Copilot capabilities into software; the other hosts agents in Foundry.

What changes for teams building agents

The announcement reinforces that the value of an agent does not depend only on the model. Context, tools, isolation, model selection and execution policies also influence the outcome. A team that today maintains each part on its own can evaluate whether it makes sense to delegate that work to a managed service, provided it meets the project's data, governance and cost requirements.

In practice, it is worth testing the harness with representative tasks from your product, not just a short demo. Compare the results in real work steps, log when the agent calls tools, examine the data sent and check how the solution handles failures and retries. To plan roles and reviews between agents, see our guide to multi-agent workflows on bridgecode. And compare this discussion with a benchmark of agents on real repository tasks.

What the announcement does not yet demonstrate

Microsoft's publication describes the architecture and availability, but it does not offer, in this announcement, an independent comparison that proves the harness will perform better in any project. The complete list of models, region-specific availability and costs also need to be checked in the current Foundry configuration. Terms like "faster" or "more efficient" should be evaluated with metrics from your own workload, not inferred from the announcement alone.