Azure AI · Copilot Studio · LLMs
TL;DR – Microsoft has taken the GitHub Copilot harness in Copilot Studio to general availability after a two month preview. A harness is the runtime that sits between your agent design and the model: it decides when to call the model, what to send it, how to read the response, and which tools to fire. Copilot Studio now has three of them. The standard harness follows the topics and paths you author. The Copilot chat harness extends Microsoft 365 Copilot Chat with your enterprise knowledge. The new GitHub Copilot harness takes a goal, plans its own steps, calls tools across connectors, MCP and connected agents, recovers when something fails, and natively produces Word, Excel, PowerPoint and PDF output from a sandboxed runtime. It bills on Copilot Credits rather than standard licensing, and the harness choice is a one way door at agent creation. If you build agents on Power Platform, this is the most consequential change to the product in a while.
Most of the Copilot Studio conversation over the last two years has been about the bits you can see. Topics. Knowledge sources. Connectors. Which model you picked in the dropdown. Almost nobody talks about the component that actually decides whether your agent works, and Microsoft has just made that component a first class, user selectable decision.
Let me break it all down.
What Is a Harness, Actually?
Here is the thing that gets lost in the marketing. A large language model does exactly one thing. Text goes in, text comes out. It cannot read your SharePoint library, it cannot call your API, it cannot write a file to disk, and it has no memory of what it did thirty seconds ago. On its own it is an extremely well read component with no hands.
Everything else is scaffolding. Something has to assemble the prompt, send it, parse what comes back, work out that the model has asked for a tool, go and execute that tool, feed the result back in, and loop until the job is done or something breaks. That scaffolding is the harness.
Microsoft’s own definition is refreshingly blunt: the harness is a runtime sitting between your design and the model, and it determines when to call the model, what components to send it, how to interpret what comes back, and which tools to call.
If you have ever written an agent loop by hand in Python, you have written a harness. You just did not call it that. What is new is that Copilot Studio now exposes the choice of runtime as a product decision rather than hiding it behind the canvas.
The Three Harnesses
Every single thing you build in Copilot Studio runs on one of three harnesses. Two of them you have already been using without thinking about it.
1. The Standard Harness
This is the classic Copilot Studio experience and it is not going anywhere. You define topics, trigger phrases, conversation paths, branching logic and business rules, and the harness executes exactly what you built. It draws on your prompt library and enterprise knowledge, and it publishes to internal teams or external customers.
The trade is predictability for flexibility. Given the same input it does the same thing every time, which is precisely what you want for an internal help desk agent that answers common questions and routes simple requests. Agent flows also run on this harness. Billing follows the existing Copilot Studio licensing model.
2. The Copilot Chat Harness
This one is not for building standalone agents at all. It is for extending Microsoft 365 Copilot Chat with your own knowledge, so that people get grounded answers inside the experience they already have open. The classic use case is an onboarding agent answering questions from SharePoint content, or a subject specific assistant with specialised vocabulary and its own knowledge base.
It runs on current chat models, publishes to internal teams only, and is billed either on consumption or as part of Microsoft 365 Copilot user subscription licences. If your goal is connecting people to information rather than automating a process, this is your harness.
3. The GitHub Copilot Harness
This is the new one, and it is a genuinely different beast. Rather than executing a script you authored, it takes a goal, decomposes it into steps, selects tools, executes, evaluates the result and adapts. Microsoft describes authoring on it as natural language first: you describe what the agent should do and the platform generates the underlying configuration, instead of you hand building topics and branches.
The capability list is where it gets interesting for anyone building real automation:
- Agentic orchestration across everything. Connectors, knowledge, MCP servers and connected agents are all callable within a single reasoning loop.
- Failure recovery. It retries and finds alternative paths automatically rather than dead ending on the branch you forgot to build.
- Native file handling. It creates, edits and reasons over Word, Excel, PowerPoint and PDF. Not “generates a link to a template”. Actually produces the artefact.
- Skills and memory. Both are first class here and explicitly listed as not a focus on the other two harnesses.
- Sandboxed execution. Each task runs in a secure sandbox governed by Copilot Studio, which is what makes large file processing and code execution tenable in an enterprise context.
- Frontier reasoning models. Microsoft lists Opus 5, GPT-5.6 Sol and Fable 5 as the models behind it, aimed squarely at long horizon work.
Microsoft’s stated benchmark position is that internal evals against real world business processes show significant performance and quality gains, particularly in multi tool use, file analysis, code analysis and knowledge quality. Treat vendor evals with the usual scepticism, but the architectural claim is coherent and the capability list is verifiable in the product.
The canonical example Microsoft uses is accounts payable: an agent reads invoices, matches them against purchase orders, and routes the exceptions for approval. That is a genuinely useful shape of problem, because the happy path is easy and the value is entirely in handling the mess.
The Comparison, Side by Side
| Consideration | GitHub Copilot harness | Standard harness | Copilot chat harness |
|---|---|---|---|
| Best for | Complex, multi step business processes | Rule based agents and structured conversations | Extending M365 Copilot Chat with enterprise knowledge |
| How it works | Reasons through a goal on its own, step by step | Follows the topics and rules you define | Connects enterprise knowledge to M365 Copilot Chat |
| Recovers from problems | Retries and finds alternative paths automatically | Follows the paths you built | Not a focus |
| Works with files | Creates, edits and reasons over Office and PDF files | Not a focus | Not a focus |
| Skills and memory | Yes | Not a focus | Not a focus |
| Publishing | Internal teams or external customers | Internal teams or external customers | Internal teams |
| Billing | Copilot Credits | Standard Copilot Studio licensing | Consumption or included in M365 Copilot USLs |
The One Way Door Nobody Is Flagging Loudly Enough
Here is the detail that deserves more attention than it is getting. You choose the harness when you create the agent, and agents built on the GitHub Copilot harness cannot be transferred to the standard harness. It does not work in the other direction either.
That makes agent creation an architectural decision rather than a click through. If you build six months of investment on the wrong runtime, the migration path is a rebuild. In practice I would treat this the same way you treat picking a database: cheap to decide up front, expensive to revisit.
Existing agents are unaffected and continue on the standard harness. If you want to keep building the old way, the Homepage has a New experience toggle you can turn off, and standard harness agents and agent flows remain available under Other ways to build. Nothing is being taken away from you.
The Billing Shift Is the Real Governance Story
Moving to Copilot Credits and usage based billing is not a footnote. It changes how you have to think about cost control, because the meter runs on using, building, testing and evaluating agents. Your dev loop now has a unit cost attached to it.
For anyone who has managed Copilot Studio capacity packs across environments, this is a different discipline. Predictable per tenant capacity becomes variable consumption driven by how much reasoning your agents do, and a goal driven agent that decides to take fourteen steps instead of four costs proportionally more. My honest advice is to instrument this from day one in DEV rather than discovering the shape of your spend in PRD. Build the cost model before you build the agent fleet.
That is not a criticism of the pricing model. Usage based billing is the correct model for variable workloads, and it is the only sane way to charge for something whose work is genuinely open ended. It just needs a governance posture that most Power Platform teams have not had to build yet.
Why This Matters More Than the Feature List Suggests
Step back from the specifics and the strategic move is clear. Microsoft is taking the runtime behind its most advanced agent experiences, the same lineage as Copilot Cowork and the GitHub Copilot coding agent, and dropping it under a low code authoring surface.
The significance is that the capability gap between “what a developer can build with an SDK” and “what a maker can build in Copilot Studio” just narrowed considerably. Sandboxed code execution, MCP integration, persistent memory, native document generation and self directed tool orchestration were, until very recently, things you built yourself in Python and hosted on your own infrastructure. Now they are a radio button at agent creation.
Microsoft is also explicitly rejecting the one size fits all approach. Different harnesses optimise for different outcomes, and keeping three of them alive in the same product is a defensible engineering position rather than a transitional state. Deterministic workflows genuinely are better served by deterministic runtimes. Not every problem wants a reasoning loop, and it is good to see that acknowledged in the product architecture rather than papered over.
The Honest Caveat
Two things to go in with your eyes open about.
First, autonomy and auditability pull against each other. An agent that plans its own steps produces execution traces that vary run to run, and if you work in a regulated environment your assurance approach has to account for that. This is the same non determinism problem I have written about before, just with a much larger action surface attached to it. Test coverage for a goal driven agent looks nothing like test coverage for a topic tree.
Second, natural language authoring is fantastic for velocity and slightly uncomfortable for change control. If the platform is generating the underlying configuration from your description, you need to be deliberate about how you version, review and promote agents across environments. The ALM story is there, but the discipline is on you.
Neither of these is a reason to avoid the harness. They are reasons to pilot it properly rather than putting it straight into a customer facing process.
The Bottom Line
The GitHub Copilot harness is the most capable thing Microsoft has shipped into Copilot Studio, and the fact that it went from preview to general availability in roughly two months tells you how much confidence they have in it. Goal driven orchestration, sandboxed execution, native Office output, MCP and connected agents, all governed inside the Power Platform model you already run.
My recommendation is straightforward. Keep your rule based agents exactly where they are on the standard harness, because there is no reason to move them and predictability is a feature. Pick one genuinely messy process, something with many steps, several systems and real ambiguity in the middle, and build it on the GitHub Copilot harness. That is where the new runtime earns its keep, and that is where you will learn what the Copilot Credit consumption actually looks like on your workload.
The organisations that build institutional understanding of agentic runtimes now will be the ones running them at scale in twelve months. Everyone else will be reading the case study.
If you are piloting the GitHub Copilot harness or working through the Copilot Credits cost model, I would genuinely like to hear how you are finding it.
