Copilot Studio: the "harness" gets a new name, your agents stay

You may have heard of the "GitHub Copilot harness" in Copilot Studio. On 28 October 2026, Microsoft announced that it is becoming the Microsoft Copilot harness.

If you're not in the trade, the question is simple: does this change anything for me? The short answer: not right away, but the post contains figures that need to be read with some distance.

What it is, in plain terms

Copilot Studio is Microsoft's tool for building agents, meaning assistants that don't just answer but act: look up a file, call a tool, chain steps together.

The "harness" is the layer that drives all of this. It decides how the agent reasons, which tools it uses and how it organizes itself. The AI model provides the intelligence. The harness organizes the work.

Microsoft wants to use this same foundation across several Copilot products. Hence the new, broader name.

What doesn't change

According to Microsoft, your existing agents keep working as they do today. No change in capabilities, no change in billing. The new vocabulary will appear in the product over the coming weeks.

If someone on your team tells you that "the engine has changed", don't panic. It's first and foremost a question of name.

The announced figures, and why I read them with caution

Microsoft compares this harness with the old one, called "Standard", in internal evaluations. Here is what the post claims:

• On the same tasks, the success rate rises by 10.8 points with one AI model and by 22.1 points with another. Changing the model matters little, changing the harness matters a lot.
• When a tool fails, the agent keeps trying in 84 to 91% of the cases evaluated, versus less than 7% with the old harness.
• The cost of processing input data drops by 15 to 21%, thanks to better memorization, even though the agent makes almost twice as many calls to the model.

I owe you an admission: these figures are Microsoft's, measured by Microsoft. The post's notes state that they can vary by day, version, model and configuration. They also state that continuing to try after a failure doesn't mean the whole task succeeded.

For executives, the right reflex is simple. Remember the trend, not the percentages. And measure on your own data.

A real example at Microsoft

The post cites an internal Microsoft customer support team. It built an agent that analyzes support cases using existing knowledge and tools. In August 2026, it resolved more than 35% of cases without human intervention.

It's a support case, not a month-end close or a supplier reminder. But it gives an idea of what can be delegated: repetitive work, where the agent relies on rules and documents you already have.

Microsoft also announces, for this same harness, persistent and proactive agents: agent accounts, business process memory, triggers. The idea is to give an agent ongoing responsibilities while keeping important decisions in human hands. The post gives no date and no availability details. So I won't speculate.

If you want to see what this looks like in practice, look at an AI agent that answers questions on the workshop's orders. To scope a project, the Copilot AI agents service is the starting point.

What it changes for you

Let's take an imaginary case: an industrial SME with 120 employees. Its purchasing department has built an agent in Copilot Studio that answers buyers' questions about the status of supplier orders. To do so, it queries the management software.

One morning, the management software connection stops responding. According to the Microsoft measurements quoted above, an agent on the old harness, "Standard", almost always gives up when faced with such an outage: the buyer redoes the search by hand. On the renamed harness, the agent keeps trying in the vast majority of cases, for example by retrying the tool later. Nothing guarantees the right answer, but it no longer gives up at the first obstacle.

Assumption for this example: 200 questions a month, one in ten of which runs into an unavailable tool. That's up to twenty or so manual searches avoided each month, if the agent eventually finds the answer. It's an order of magnitude to reason with, not a measured result.

First step, starting next week: if an agent is already in service in your company, ask which harness it runs on. Then, for a month, write down the questions where it gave up, and why.

What this means for you

What you can do starting Monday:

• Let your teams know that the name is changing, not how their current agents work.
• Pick a repetitive process, for example a purchase request or a compliance check, for a measured test.

What you need to check:

• Microsoft's figures come from internal evaluations. Don't put them in a budget without testing them in your own company.
• Your Copilot Studio license and your agents' billing, even though Microsoft says they don't change.

What you can ask your IT department or your provider:

• Which agents are already running in your company, and on which process?
• Which decisions are still approved by a person?
• How do you measure an agent's success: share of cases resolved on its own, errors, manual rework?

If you're unsure where to start, a consulting and audit engagement helps you choose a simple case before building anything.

Based on Microsoft

Based on: The GitHub Copilot harness in Copilot Studio is now the Microsoft Copilot harness, Microsoft, 28 October 2026, https://www.microsoft.com/en-us/copilot/blog/copilot-studio/the-github-copilot-harness-in-copilot-studio-is-now-the-microsoft-copilot-harness/