The GitHub Copilot harness is now generally available in Microsoft Copilot Studio. It expands what teams can automate, but it also changes how those solutions are billed and creates a decision that cannot be reversed through a simple configuration change.
Agents cannot be transferred between the GitHub Copilot and standard harnesses. Moving later may therefore require rebuilding or reimplementing the solution. Harness selection should be addressed during architecture and financial planning, not after development begins.
What the new harness changes
A harness is the runtime sitting between your agent design and the model. It decides when to call the model, what context to send, and which tools to fire. The standard harness follows the topics and paths you author, which is predictable but builds into branching logic that grows harder to maintain. The GitHub Copilot harness takes a goal, breaks it into steps, calls tools across connectors, knowledge and MCP, and adjusts when something fails. It also creates and edits Word, Excel, PowerPoint and PDF files natively, and supports memory and skills.
Skills can make agent behavior more modular and maintainable. A skill packages a defined capability through a name, description, instructions, and, when needed, supporting scripts, references, or templates. The runtime uses the description to determine when the skill applies. This structure can give process owners a more accessible way to review behavior, but production changes still require ownership, testing, and change controls.
The cost model changes as well
Agents on the new harness bill through Copilot Credits on a usage basis, regardless of Microsoft 365 Copilot licensing. Two details matter for budgeting. Billing starts when you begin building rather than after you publish, so previewing, testing and generating evaluations all consume credits. And credits cover model tokens, tools including knowledge and MCP, and the harness itself.
The licensing comparison requires more nuance. Some standard and Copilot Chat harness usage is included when appropriately licensed users access agents in covered Microsoft 365 scenarios. Other channels, features, or unlicensed usage can consume Copilot Credits. By contrast, creation and runtime activity on the GitHub Copilot harness use consumption-based billing regardless of a user’s Microsoft 365 Copilot license.
Choose a harness for your workload
Harness selection happens when an agent is created, and it stays put. Agents cannot move from the GitHub Copilot harness to the standard one later, or the other way around, so switching means rebuilding. Worth knowing before a project starts, though less limiting than it sounds. Existing agents keep running, and Microsoft has committed to supporting the standard and Copilot Chat harnesses for current agents and new authoring, so there is room to be deliberate.
In practice the choice usually resolves on the nature of the work. Processes spanning multiple steps, tools and documents suit the new harness. Rule-based conversations, where consistency matters more than flexibility, remain well served by the standard one. It helps to model expected credit consumption before committing rather than assuming license coverage carries over, and to agree early on how much development and testing is reasonable, so those costs stay visible.
Before making your selection, consider these three questions:
- Does the process require adaptive reasoning, or should it follow controlled paths?
- What level of execution variability can the business tolerate?
- Who owns credit consumption during development, evaluation, and production?
If your organization is expanding its Copilot Studio portfolio, treat the harness as a documented architecture decision. Before development begins, identify the required behavior, test the choice with a representative workload, estimate build and runtime consumption, and assign ownership for monitoring. That discipline will do more for cost predictability than choosing a harness from a feature comparison alone.
RSMUS.com