A harness in Microsoft Copilot Studio is the runtime layer between your agent's configuration and the AI model. It decides when to call the model, what context to send, how to interpret the result, and which tool to call next. Copilot Studio now offers three: the Copilot chat harness, the standard harness, and the GitHub Copilot harness, which reached general availability on August 3, 2026. Choose the standard harness for bounded, predictable, process-driven agents that are covered by existing Microsoft 365 Copilot licensing. Choose the GitHub Copilot harness for long-running, reasoning-heavy work that needs planning, file creation, memory, and recovery - and accept that it is always billed on Copilot Credits, regardless of what licenses your users hold.
The part most organizations miss: you cannot convert an agent from one harness to the other after you create it. That makes harness selection an architecture decision made at minute zero, with consequences you live with for the life of the agent.
A harness is the orchestration runtime that equips and directs the model. The model supplies reasoning. The harness supplies context, instructions, tools, and control flow, then interprets what comes back.
This is the cleanest mental model Microsoft has offered in a while. You design the agent. The model reasons. The harness is the operating layer in between that determines how far the agent can actually get before it needs a human.
Microsoft published a white paper, Choosing the correct Copilot Studio harness, alongside the September 2 Copilot Studio monthly update that announced GA. It is worth reading in full. It is also worth reading with a governance lens Microsoft does not apply for you.
Everything you build runs on one of three harnesses:
One naming clarification, because it trips up nearly every steering committee: the GitHub Copilot harness is a Copilot Studio authoring and orchestration framework. It is not the GitHub Copilot developer service. If your CFO hears "GitHub" and assumes a developer seat licence, correct that early.
If you are still framing agents as a low-code side project rather than a governed portfolio, start with our view on what an Agent PMO looks like in practice for Copilot Studio governance.
Choosing a Copilot Studio harness is an architecture decision with billing, capability, and governance consequences.
The GitHub Copilot harness became generally available on August 3, 2026, turning Copilot Studio into a multi-harness platform. The release is additive. No existing agent was modified, migrated, or moved to a different harness.
That reassurance is real, and it is also the source of a quiet risk. Because nothing was forced, nothing was reviewed. Makers in your tenant have had a materially different runtime available to them since early August, with a different cost model, and most governance teams have not updated a single policy to reflect it.
What the GitHub Copilot harness adds over the standard harness:
Microsoft's own example is an accounts payable agent that reads invoices, matches them to purchase orders, gathers missing information, and routes exceptions for approval. That is a good test case. If your scenario does not look roughly that shaped, you probably do not need this harness yet.
Microsoft has also been explicit that it remains committed to the standard harness as a supported, actively maintained option, with ongoing investment in quality, reliability, security, and new capabilities that fit its strengths. Existing agents do not need to migrate simply because the GitHub Copilot harness exists.
Read that twice. It is the single most useful sentence in the white paper, and it is the opposite of what most vendors and a fair number of internal champions are currently telling your leadership team.
The GitHub Copilot harness charges Copilot Credits from the moment you start building, not after publish. Creating an agent from natural language, previewing it, testing it, and generating evaluations all consume credits.
This is the most consequential change and the least discussed one.
Under the standard harness, the economic clock starts at publish. Under the GitHub Copilot harness, it starts at the first keystroke in the maker experience. Credits cover large language model tokens, tools including knowledge and MCP servers, and the harness itself. Any experience that touches one of those consumes credits.
Three consequences follow directly, and none of them are theoretical:
1. Exploration environments now generate spend. A sandbox where makers experiment can incur consumption even if nothing is ever published to production. Your existing environment strategy almost certainly assumes the opposite.
2. Licensing does not shield you. Agents on the GitHub Copilot harness are always billed on usage, regardless of Microsoft 365 Copilot licensing. The billing exception available to licensed Microsoft 365 Copilot users in authenticated employee scenarios does not apply here. If your business case assumed "we already pay for Copilot," rebuild it.
3. Capacity is an enablement gate. Credits are allocated and monitored through the Power Platform admin center. Administrators assign them to environments and set caps. Which means the first person who can stop a runaway agent bill is an admin, not a maker.
The practical baseline we recommend to clients: find the GitHub Copilot harness agents and the environments containing them, classify each environment as maker development or funded production, review allocations and pay-as-you-go enforcement rules, apply agent-level limits where a single agent needs a tighter boundary, and repeat the review on a schedule.
For the discovery step, the September 2026 Copilot Agent Kit release matters: Agent Inventory V2 now extends governance coverage to GitHub Copilot harness agents and adds relationship metadata including MCP lists, connected agents, evaluations, and agent owner IDs. See our breakdown of what the Copilot Agent Kit September 2026 release means for governance.
DimensionStandard harnessGitHub Copilot harnessDesign modelRule-based: topics, triggers, nodes, branching, agent flowsGoal-based: natural-language instructions, skills, tools, workflowsExecutionFollows the paths you authorPlans steps, calls tools, adapts and re-plans toward the goalBest forBounded, short, predictable multi-step processes over a known set of data and toolsLong-running, coordination-heavy, reasoning-intensive work needing iterative refinementFile handlingNot native to the harnessNative creation and editing of Word, Excel, PowerPoint, PDFSkillsNot availableNative skills framework, portable and reusable across agentsMemorySession contextMemory that persists across interactionsBilling triggerStarts after publishStarts when you begin building, including preview, test, and evaluationsLicensingIncluded with Microsoft 365 Copilot and Copilot Business licenses, or consumption on the existing rate cardAlways usage-based billing on Copilot Credits, regardless of Microsoft 365 Copilot licensingPortabilityCannot be converted to the GitHub Copilot harnessCannot be converted to the standard harnessReasoning modelsNot availableReasoning models and emerging agentic capabilities available here only
Both harnesses can deliver predictable, deterministic responses - through pre-defined topics in the standard harness or workflows in the GitHub Copilot harness. Determinism is not the dividing line. Scale, duration, and adaptive recovery are.
Both harnesses can deliver predictable, deterministic responses - through pre-defined topics in the standard harness or workflows in the GitHub Copilot harness. Determinism is not the dividing line. Scale, duration, and adaptive recovery are.
Start with the business process and the behaviour the agent must exhibit, not the feature list. Run the scenario through five questions in order and stop at the first one that forces a harness.
Question 1 - Are you extending Microsoft 365 Copilot for employees, grounded in enterprise content?Yes, and nothing more: use the Copilot chat harness. Included with Microsoft 365 Copilot licensing. Do not spend credits on a Q&A experience.
Question 2 - Is the process fully known in advance, with a bounded set of data, documents, and tools?Yes: use the standard harness. This is the right home for FAQ agents, helpdesk routing, approval flows, and form-fill scenarios. You get explicit control, established channels, and licensing coverage.
Question 3 - Does the task run long, coordinate across many systems, or require the agent to iteratively evaluate and refine its own work?Yes: use the GitHub Copilot harness. This is its design point, particularly when the process is not yet optimized and you want AI to surface improvement opportunities.
Question 4 - Does the agent need to natively produce Word, Excel, PowerPoint, or PDF output, use skills, or carry memory across interactions?Yes: GitHub Copilot harness. These capabilities are harness-bound, not model-bound.
Question 5 - Do you have Copilot Credits allocated to the target environment, a named owner, and a consumption cap?No: stop. Do not start building. Resolve capacity, ownership, and enforcement first, because building itself consumes credits.
That fifth question is the one 2toLead adds. Microsoft's guidance covers capability fit well. It does not gate the decision on whether your organization is financially and operationally ready to absorb it. That gate belongs to you.
If your environment strategy is not yet ready to support this, our guidance on building enterprise agents with Copilot Studio, Agent 365, and Power Platform governance is the right starting point.
Answer block: Inventory GitHub Copilot harness agents, classify the environments hosting them, set credit caps and ownership, and publish an internal harness decision standard before makers set precedent for you.
Five actions, in order:
1. Discover. Identify every GitHub Copilot harness agent and the environments containing them. Agent Inventory V2 now discovers and governs harness agents, not just standard-harness ones.
2. Classify environments by purpose. Maker development and funded production need different controls. The same controls are available in both, but how you apply them should reflect what the environment exists to support.
3. Set the financial guardrails. Review allocations, tenant-pool access, pay-as-you-go billing, and enforcement rules in the Power Platform admin center. Apply agent-level limits where an individual agent needs a tighter boundary.
4. Gate who can build on the expensive harness. Not every Copilot licence holder needs Copilot Studio, and not every Copilot Studio maker needs the GitHub Copilot harness. Pair access with training and a cohort model. Then reinforce it with sharing controls - see the Copilot Studio sharing controls every organization should enable.
5. Publish the decision standard. One page. The five questions above, the approved use cases per harness, the named approver, and the credit threshold that triggers review. Circulate it before your makers invent their own.
Join Our Newsletter
