Cover image for The GitHub Copilot Harness Is Now the Microsoft Copilot Harness
,

The GitHub Copilot Harness Is Now the Microsoft Copilot Harness. Here Is What Admins Should Update.

On October 28, the Copilot Studio team announced that the GitHub Copilot harness in Copilot Studio is now the Microsoft Copilot harness. Microsoft says the new name reflects the harness’s broader role across Microsoft, as it extends a shared foundational harness across Copilot experiences. The same day, GitHub announced that the GitHub Copilot SDK is becoming the Microsoft Copilot SDK.

Microsoft is clear about what this is not. In its own words, “Your existing agents will continue working as they do today, with no changes to capabilities or billing.” No admin action is required. A rename still has governance consequences, though, because the old name is now written into cost reports, inventory queries, security reviews, and maker guidance across your organization. This article covers what actually changed, what did not, and the short list of things admins should update.

What changed and what did not

AreaStatus
NameChanged from GitHub Copilot harness to Microsoft Copilot harness
Product labelsUpdated terminology appears in Copilot Studio “over the coming weeks”; no specific date
Existing agentsContinue working as they do today
CapabilitiesNo change
BillingNo change
SDKGitHub Copilot SDK is becoming the Microsoft Copilot SDK in phases; no immediate changes required for existing users
Microsoft Learn documentationStill uses the GitHub Copilot harness name as of November 3, 2026

What the harness is, in one paragraph

A harness is the operating layer between the model and the agent’s configuration. It decides how the model receives context, uses instructions and tools, and moves through a task. Microsoft’s harnesses overview lists three in Copilot Studio. The Standard harness is for rule-based agents built from topics, prompts, and defined paths. The Customer Conversation harness is for customer-facing voice and chat with escalation to human representatives. The harness now called the Microsoft Copilot harness is for reasoning-heavy, multi-step work: it breaks a goal into steps, calls tools across connectors, knowledge, MCP servers, and connected agents, and adjusts when a step fails.

The three Copilot Studio harnesses: Standard, Microsoft Copilot (formerly GitHub Copilot), and Customer Conversation, with what each is best for and how it is billed
Only the middle harness was renamed. Its billing model is unchanged.

The rename fixes a real misunderstanding

The old name caused a predictable question in security and privacy reviews: does an agent built on the GitHub Copilot harness send business data to GitHub? Microsoft’s documentation already answered it. The harness is a Copilot Studio authoring and orchestration framework, not the GitHub Copilot service, and customer data is not sent to the GitHub Copilot service when agents run in Copilot Studio.

The new name removes the confusion, but only for people who see it. If your data protection impact assessments, vendor risk entries, or architecture decision records name GitHub as a processor because of the harness label, correct them now and record why. The reason is the documented architecture, not the rename.

The cost model behind the name did not change

“No changes to billing” is good news and a reminder. Microsoft’s usage-based billing overview says that for experiences on this harness, “Copilot Credits are charged for large language model (LLM) tokens, tools (including knowledge and MCPs), and the harness itself.” It also says that, unlike the Standard harness, which starts billing after publish, this harness “charges credits from the moment you start building.” Design, preview, testing, and evaluation all consume credits, including in environments whose agents are never published.

Microsoft’s announcement also cites internal evaluations from October 2026. Compared with the Standard harness, it reports pass rates 10.8 percentage points higher with an OpenAI model and 22.1 points higher with an Anthropic model. It reports that agents continued after a failed tool call in 84 to 91 percent of cases, against fewer than 7 percent on the Standard harness. And it reports net input processing cost 15 to 21 percent lower through caching, despite nearly twice as many model calls. Microsoft notes that results vary by day, build, model, and configuration. Treat these figures as a reason to run your own evaluation, not as a budget input. The Harness Is the Price Tag covers how to cost an agent on each harness.

The controls that apply, under either name

Microsoft’s guidance, Govern Copilot Credit consumption for agents powered by the GitHub Copilot harness, sets out layered controls. None of them change with the rename.

LayerControlWatch for
TenantAdd-on capacity assignment setting, which decides who can allocate creditsEnvironment admins with allocation rights can allocate across every environment; keep it with tenant admins
EnvironmentPrepaid allocation, with “Draw from the available capacity in my tenant” turned offThis is the only environment-level hard boundary
EnvironmentPay-as-you-go billingAzure budgets and alerts warn but do not stop consumption
AgentMonthly consumption limit, notification threshold, and hard stop in Manage AgentsNo tenant-wide default limit; agent limits do not cap environment totals
Microsoft 365 admin centerCopilot Cost Management spending policiesPrepaid credits can be shared across products, so review both admin centers

If those controls are not in place yet, the rename is a good prompt to put them in. Draw from Tenant Credit Pool and Zero Credits Allocated Does Not Mean Zero Spend walk through the allocation settings in detail.

What admins should update

Inventory queries and automation

Microsoft’s governance guidance tells admins to find these agents in Power Platform Inventory by filtering on properties.harness equal to GitHub Copilot. If you have built that filter into scripts, scheduled reports, or a Power Automate flow, check whether the value changes as the new terminology rolls out. Microsoft has not said. A filter that silently returns zero agents looks exactly like a tenant with no harness spend, which is the worst kind of failure for a cost control. Add a test that alerts when the count drops to zero unexpectedly.

Cost reports and chargeback

If finance or your FinOps team reports harness consumption under a “GitHub Copilot” label, rename the category and add a note mapping old to new. Otherwise someone will eventually reconcile a GitHub invoice against Copilot Studio credits that were never billed by GitHub.

Policies, standards, and maker guidance

Update internal standards that tell makers when to choose this harness, and any approval workflow that asks for it by name. Microsoft’s harness comparison guidance is a sound basis: the Standard harness for short, bounded, high-traffic tasks with a stable set of actions, and this harness for long-running, multi-system, adaptive work. The same guidance warns that a more capable harness can overwork a simple problem, adding cost and latency without a better outcome, and that moving an agent between harnesses is re-architecture rather than conversion.

Security reviews

Correct any record that lists GitHub as a data processor for Copilot Studio agents because of the harness name, and cite Microsoft’s statement that customer data is not sent to the GitHub Copilot service. While you are there, note which harness-only capabilities your agents use. Hooks, which can inspect, modify, or block tool calls, are available only on this harness, and so are triggers that start agents from an incoming email or a schedule. Both are worth naming in a security review.

Four things admins should update after the harness rename: inventory queries, cost reports, policies and maker guidance, and security reviews
Nothing about your agents changed. These four places still carry the old name.

Why the name matters beyond Copilot Studio

The more significant signal is the direction. Microsoft describes the harness as a shared foundation across Copilot experiences, and the SDK is moving with it. As covered in PPCC 2026: Every Announcement, and the Governance Decision Behind Each One, agent accounts, business process memory, and triggers are arriving on this harness. Expect more agent experiences to run on the same engine, and expect the governance questions to converge with them: who can build on it, what it may do autonomously, and who pays.

That makes it worth settling your harness policy once, under the new name, rather than separately for each product that adopts it.

A short checklist

  1. Find every script, report, and flow that filters on the harness name, and add an alert for an unexpected zero count.
  2. Rename harness cost categories in chargeback and FinOps reports, with an old-to-new mapping.
  3. Update maker standards, harness selection guidance, and approval forms.
  4. Correct security and privacy records that list GitHub as a processor because of the old label.
  5. Confirm that tenant, environment, and agent credit controls are in place for every environment that uses this harness.
  6. Tell makers what changed and, just as important, that nothing about their agents did.

Sources