Copilot Studio has swapped the engine

Open copilotstudio.microsoft.com right now and you land in an interface you probably do not recognise. A different left-hand menu, a different structure, workflows instead of flows. This is not cosmetic. A different runtime is running underneath, and since 3 August 2026 it is generally available.

What a harness is

The term is new in Copilot Studio, and Microsoft defines it unusually precisely. A harness is the runtime between what you design and the model that does the reasoning work. It decides when the model gets called, which components go along, how the response is interpreted, and which tool is next.

That is the part you never see in demos and that nonetheless decides whether an agent sees a multi-step process through or goes off the rails after step three.

Copilot Studio now has three of them.

Three harnesses, three billing models

GitHub Copilot harness

Standard harness

Copilot chat harness

Made for

complex, multi-step business processes

rule-based agents, structured dialogue

extending Microsoft 365 Copilot Chat

How it works

breaks a goal into steps itself

follows the topics and rules you define

connects company knowledge to M365 Copilot Chat

On failure

retries, looks for alternative routes

follows the paths you built

not a focus

Files

creates and edits Word, Excel, PowerPoint, PDF

not a focus

not a focus

Skills and memory

yes

not a focus

not a focus

Billing

Copilot Credits, consumption-based

licence model as before

consumption, or included in the M365 Copilot licence

The interesting part is the last row. On the standard harness, billing starts after publishing. On the GitHub Copilot harness, from the moment you start building. Prototyping, testing in the preview panel, generating evaluations: all of it consumes credits. I am writing a separate dispatch on that, because a table does not do it justice.

Skills replace topics

The second big change concerns how you teach an agent what to do.

A skill is a capability made of a name, a description and a set of instructions in Markdown. The orchestration runtime loads the skill when the request matches its description. Skills are reusable across multiple agents and can be exported as a Markdown file or a ZIP package.

Anyone who has been building topics has to rethink. A topic is a flow you drew: trigger, branches, nodes, deterministic. A skill is an instruction the orchestrator reads and then decides for itself how to follow.

For most scenarios this is a gain. The difference between "where is my order" and "why has my order from last week still not arrived, I paid for express" has been taking topic trees apart for years. That is exactly what an orchestrator is better at.

For strictly regulated dialogue paths it is a risk. If an advisory sequence has to run exactly as approved for legal reasons, then "the orchestrator usually follows the instruction" is not an acceptable statement. This is where the standard harness belongs, or a deterministic workflow alongside the agent.

That is the line you have to draw: the agent takes the judgement, the workflow takes whatever must run identically every time. Where exactly the line sits is your call. That it has to exist is no longer decided for you by the product.

The catch almost nobody mentions

Agents cannot be moved between harnesses. What was built in the classic experience stays there. What you build in the new one stays there.

That sounds like a detail and is the most important sentence for your planning. If you have a grown Copilot Studio estate, with topics, autonomous triggers and publishing to channels beyond Teams, then switching is not a toggle, it is a rebuild. Existing agents keep running, and there is no cut-off date at which something gets turned off. But every new platform capability, skills, memory, working natively with files, hangs off the new harness.

Practically that means you will run both worlds for a while. Plan for it instead of discovering it.

What else belongs here

Two things that landed in the same period and influence the decision.

Microsoft IQ connects agents in the new experience to organisational data: emails, calendar entries, files, Teams messages, people information. That is the context whose absence has been the most common reason an agent convinced in testing and disappointed in daily use.

Memory gives the agent persistent context across interactions, stored per user. That is powerful and governance-relevant. Before you switch it on, you should be able to say what gets stored, for how long, and what happens when someone requests deletion.

On top of that comes model selection: Claude Sonnet 5 and GPT-5.5 Chat are generally available as primary models. That model choice is now a configuration field was unthinkable two years ago.

My assessment

The direction is right. An orchestrator that breaks a goal down itself solves exactly the problems topic-based bots have been failing at for years. And putting Copilot Studio agents on the same harness line as the GitHub Copilot coding agent is strategically consistent.

I am keeping two reservations.

The first is instruction adherence over long runs. That is precisely where agents drift, and the preview window between June and August was short for a change of this magnitude. If you go to the new harness, invest the build time you saved into evaluations. Copilot Studio has had GA tooling for this since March, including multi-turn tests. Use it before you go to production, not after.

The second is commercial. Moving to Copilot Credits from the first build step changes how experimenting feels. A maker who spends three afternoons trying variants now generates an invoice. That is manageable when somebody knows in advance. It is a breach of trust when the business department finds out afterwards from the Power Platform Admin Center.

What I would recommend

1. Leave existing agents alone. They run, they are paid for, they do their job.
2. Choose the GitHub Copilot harness for the next build with genuine process character. Invoice intake, contract review, anything spanning multiple systems with exceptions.
3. Understand the cost model and set budgets in the Power Platform Admin Center before the first maker gets access.
4. Keep strictly scripted dialogue on the standard harness and document the decision, so that in a year nobody mistakes it for laziness.
5. Take an inventory. Which agents run on which harness, who owns them, what do they cost. You will need that table at the next audit at the latest.

Sources

• Choose a harness, Microsoft Learn, as of 3 August 2026
• Skills overview for agents, Microsoft Learn, as of 3 August 2026
• Overview of billing for agents powered by the GitHub Copilot harness, Microsoft Learn, as of 3 August 2026
• What's new in Copilot Studio, Microsoft Learn
• Copilot Studio Harnesses: Understanding the GitHub Copilot Harness, Rajeev Pentyala, 5 August 2026