For most of 2026, the agent conversation has been about models: which one reasons best, which one is cheapest, which one tops this week’s benchmark.

On October 28, Microsoft made a quieter but more important statement. It took the harness GitHub built for Copilot, renamed it the Microsoft Copilot harness, standardized its Copilot products on it, and made it available to developers through Microsoft Foundry.

That’s Microsoft saying, in product form, what practitioners have been saying for months: the harness is the product.

What actually changed

There are two announcements here, and they mean different things depending on where you build.

In Copilot Studio, it’s mostly a rename. What makers knew as the “GitHub Copilot harness” is now the “Microsoft Copilot harness.” According to the Copilot Studio team, existing agents keep working with no changes to capabilities or billing, and the new name shows up in the product over the coming weeks.

In Microsoft Foundry, it’s new. The official announcement by Tina Schuchman (CVP, Foundry) and Vladimir Fedorov (CTO, GitHub) says the same harness now powers Copilot Code, Copilot Studio, the GitHub Copilot app, the CLI and VS Code, and is now offered through Foundry, either as a downloadable SDK or run in the cloud and managed by Foundry.

In Microsoft’s own words: “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.”

What a harness is (in plain terms)

Microsoft’s definition is a good one: “If the model supplies the intelligence, the harness is everything around the model.”

That means the loop that decides the next step, the context the agent sees, the tools it can call, the sandbox it runs in, how it recovers when something fails, and the controls around all of it. Microsoft also lists support for MCP, agent skills and agent plugins as table stakes.

According to the announcement, the harness works across 20+ frontier models plus bring-your-own-key, can route work to the right model for the task, and its runtime was recently ported to Rust to cut session overhead and time-to-first-token.

The numbers worth paying attention to

The Copilot Studio post includes evaluation results. These are Microsoft’s own evaluations, so treat them as a vendor claim, not an independent benchmark. Still, the pattern is the interesting part:

  • The harness moved results more than the model did. Microsoft says changing models had little impact on pass rates, while changing harnesses made a substantial difference. Compared with the Standard harness, the Copilot harness improved pass rates on the same tasks by 10.8 percentage points with an OpenAI model and 22.1 points with an Anthropic model.
  • Agents stopped giving up. When a tool call failed, agents on the Copilot harness kept trying to solve the problem in 84–91% of evaluated cases, versus fewer than 7% on the Standard harness, and were more than 7 times more likely to successfully retry the failed tool later.
  • More calls, lower input cost. Even while making nearly twice as many model calls, better caching cut the net cost of processing input by 15–21%.

If you’ve ever watched an agent hit one failed API call and immediately apologize its way out of the task, the second number is the one that matters.

The fine print for Foundry

A few practical details from early coverage, like this breakdown on Exchange Anywhere, are worth knowing before you plan around it:

  • The Copilot harness in Foundry Agent Service is in public preview, not GA.
  • You pick the harness when you create the agent. Existing agents stay as they are, and switching harness after creation isn’t supported yet.
  • Harness runtime usage is free until December 1, 2026. After that, consumption-based runtime billing starts. Model inference and separately billed tools can still cost money during the free period.
  • Long-running resilience for hosted agents is GA, but your app still has to manage its own checkpoints and avoid duplicate actions on restart.

The other side of the debate

Not everyone agrees on how much harness you need. On X last week, a thread on harnesses versus prompts had builders arguing both ways: some say a model’s stock harness plus strong behavior prompts beats custom control layers, while others insist production needs custom retries and safety rules.

Microsoft’s move lands in the middle. You get a managed, opinionated harness, and Microsoft says its platforms “remain open and interoperable, so you can continue to bring in any harness and framework you want.”

What this means if you build agents for a business

No hype, just the practical read:

  1. Stop picking the model first. If Microsoft’s numbers hold up even partly, your harness choice affects reliability more than the model swap you were debating.
  2. In Copilot Studio, check which harness your agents use. If you’re on the Standard harness for agents that call tools and APIs, test the same agent on the Copilot harness and compare pass rates and retries on your own scenarios.
  3. In Foundry, treat it as a pilot. It’s preview, the harness is fixed at creation, and billing changes on December 1. Build a new agent, measure it, and don’t migrate anything critical yet.
  4. Watch Ignite. Microsoft Ignite runs November 17–20, 2026, and agent platform and governance are major tracks. Expect more on this.

The model race isn’t over. But the competitive edge for most businesses won’t come from which model they picked. It’ll come from what surrounds it.