AIREITERSwapping models should not force an orchestration rewrite, yet that rewrite is the kind of rework that derails agent timelines. Microsoft Copilot harness in Microsoft Foundry is Microsoft's managed answer: the same execution layer behind Copilot Code, Copilot Studio, the GitHub Copilot app, the CLI, and Visual Studio Code, now in public preview with free runtime until December 1, 2026 (blogs.microsoft.com). Build experiments now, but keep production on your current stack until the preview limits below are resolved.
What the Microsoft Copilot harness actually does
The Microsoft Copilot harness is the managed orchestration layer around the model that turns reasoning into completed work. Microsoft supplies the agent loop, sandbox, governance, and optimization, while the developer supplies instructions, skills, tools, and model choice.
Microsoft's framing is blunt: "If the model supplies the intelligence, the harness is everything around the model" (blogs.microsoft.com). Concretely the harness manages working context as tasks evolve, coordinates model calls and tool calls, runs files and code execution in a sandbox, delegates bounded subtasks to built-in subagents, and enforces configured limits and policy boundaries (devblogs.microsoft.com).
| Responsibility | Microsoft Foundry manages | You provide |
|---|---|---|
| Agent loop and sandbox execution | Yes | No |
| Governance, approvals, optimization | Yes | Configure |
| Instructions and skills | No | Yes |
| Tools, MCP servers, knowledge | No | Yes, with auth you configure |
| Model selection | Supported list | Your deployment choice |
Multi-model routing covers 20+ frontier models plus BYOK
The Microsoft Copilot harness supports more than 20 frontier models across model families with bring-your-own-key (BYOK) configurations, and routes work to the appropriate model or models based on the task (blogs.microsoft.com). Microsoft does not publish the full 20-model list in the announcement, so verify exact model availability for your Foundry region before planning a multi-model design. The pitch is that customers stop maintaining a custom router: "You bring the instructions, skills, tools, and model choice."
One early builder summarized the appeal as not having to rewrite the orchestration layer every time the model changes — @ai_fengshou.
Rust runtime and the products it already powers
The Microsoft Copilot harness runtime was recently ported to Rust, which Microsoft says reduced session overhead and time-to-first-token (blogs.microsoft.com). No percentage improvement or latency table is published, so treat the claim as directional.
Microsoft says the same harness already powers Copilot Code, Copilot Studio, the GitHub Copilot app, the GitHub Copilot CLI, Visual Studio Code, and other Microsoft and GitHub Copilot surfaces (blogs.microsoft.com). Microsoft describes that shared base as tested across millions of users and hundreds of real-world use cases (blogs.microsoft.com).
The harness supports open extensibility through Model Context Protocol (MCP), agent skills, and agent plugins (blogs.microsoft.com).
What changed on October 28, 2026
Microsoft made two linked moves on October 28, 2026: the Microsoft Copilot harness entered public preview in Foundry Agent Service, and long-running resilience for hosted agents became generally available (devblogs.microsoft.com).
Terminology is shifting: what Copilot Studio documentation still calls the GitHub Copilot harness is now the Microsoft Copilot harness across product terminology, though pages transition at different times (microsoft.com).
Foundry Agent Service now offers three abstraction levels: prompt agents without the harness, prompt agents with the Microsoft Copilot harness in preview, and hosted agents where developers control the framework (devblogs.microsoft.com). Long-running resilience, the hosted-agent ability to recover from interruptions during workflows lasting hours or days, is the part that is already GA.
How a harness agent is built in Foundry
A Foundry harness agent is defined declaratively and stored with application code (devblogs.microsoft.com). Developers create and test the agent in Foundry, keep definitions under source control, and deploy with the Azure Developer CLI (azd) or the Foundry portal (devblogs.microsoft.com).
Reusable skills package the method
Reusable skills bundle instructions, scripts, supporting resources, and procedures that agents apply across tasks. The documented example uses a research-brief skill at skills/research-brief/SKILL.md that forces the agent to confirm question, audience, scope, and time period, gather evidence with approved tools, cite sources and dates, distinguish facts from interpretation, and flag conflicting evidence.
Connected tools stay governed
Connected tools let agents use Microsoft Foundry tools and MCP tools with explicitly configured authentication and approvals. That approval step is a governance control, and as Reddit reports below show, it is also where production friction appears when end users face repeated consent dialogs.
Execution, files, and delegation
Agents work with files, execute code, and delegate bounded tasks to built-in subagents while the main agent coordinates results. Copilot Studio's harness comparison adds that the GitHub-lineage harness natively creates and edits Word, Excel, PowerPoint, and PDF files and supports skills plus memory (learn.microsoft.com).
Source-controlled definitions with a one-line harness flag
Agent definitions live alongside code. The Foundry sample declares the harness in azure.yaml (devblogs.microsoft.com):
harness:
type: microsoft_copilot_previewThe sample wires a research-brief prompt agent to a research-brief-skill skill with web search (public-research) and Code Interpreter (research-analysis), using FOUNDRY_PROJECT_ENDPOINT and MODEL_DEPLOYMENT_NAME as environment inputs (devblogs.microsoft.com). Deploy and invoke follow the preview CLI:
azd deploy --all
azd ai agent invoke research-brief \
"Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."Other authoring routes include the Foundry portal, the Foundry Toolkit for Visual Studio Code, and the Foundry plugin for the GitHub Copilot app (devblogs.microsoft.com).
Which Foundry agent path fits your task
There is no single right abstraction level; Microsoft's own guidance is to pick the lowest infrastructure ownership that satisfies the application (devblogs.microsoft.com). The choice locks at creation during preview, so decide before you click create.
| Approach | Use it when | What you gain | What you give up |
|---|---|---|---|
| Prompt agent without harness | Instructions plus supported tools are enough | Simplest, least ownership | No skills, managed files, subagents, or rich orchestration |
| Prompt agent with Microsoft Copilot harness (preview) | You need skills, managed execution, files, subagents, complex tool coordination | Managed loop and sandbox, reusable skills, richer execution | Preview limits apply; Microsoft controls more of the runtime; supported models, tools, and regions apply |
| Hosted agent | You must bring or modify the framework, loop, middleware, or dependencies | Maximum control with Foundry-managed hosting | You own checkpoints, resume logic, and duplicate-action prevention |
Early customer signals cited by Microsoft include Confluence Technologies shipping a solution in under a week by focusing on design rather than infrastructure, and Fashable using the harness for governed sourcing workflows while keeping commercially binding decisions under human control (devblogs.microsoft.com).
What it costs after December 1, 2026
Billing for the Microsoft Copilot harness runtime begins December 1, 2026, on a consumption model. Runtime usage before that date is free, but model inference, separately billed tools, and connected services are charged separately throughout.
| Sandbox resource | Price from Dec 1, 2026 |
|---|---|
| Sandbox compute | $0.0994 per vCPU-hour |
| Sandbox memory | $0.0118 per GiB-hour |
Prices may vary by region and customer agreement (devblogs.microsoft.com). Foundry manages CPU, memory, and idle settings of the execution environment during preview (devblogs.microsoft.com), and points to separate docs for supported regions, models, tools, and preview limits.
In Copilot Studio, agents on the GitHub-lineage harness bill through Copilot Credits on a usage-based model, a separate billing surface from Foundry sandbox metering (learn.microsoft.com). To estimate a pilot, multiply observed sandbox vCPU-hours and GiB-hours by the rates above, then add model-token and tool charges.
Preview limits to check before you build
The fine print decides whether a preview pilot survives contact with production. These constraints come from Microsoft's own Foundry post unless noted as user-spotted.
- Harness choice is one-way for now. Pick the harness when you create the agent; existing agents stay unchanged, and switching the harness after creation is not currently supported. One early reader flagged exactly this: "you pick the Copilot harness when you create the agent. Existing agents stay unchanged, and switching the harness after creation is not supported yet" — @navaneethan_es.
- Regions and models are bounded. Foundry defers the full list to docs on supported regions, models, tools, and preview limits. One user summary reports roughly nine regions with no Middle East coverage and no full bring-your-own-model yet — @HeshamSaadZaki. Treat that as a user reading to verify in docs, not an official region table.
- Long-running recovery is your code's job. Foundry restarts interrupted hosted work and resupplies the original input, but the application must save progress, resume from checkpoints, and guard against duplicate actions such as creating the same external report twice. Conversation history alone does not restore work in progress.
- No benchmark or SLA numbers ship with the launch. Expect qualitative claims like "industry-leading performance" without latency, throughput, or accuracy tables.
What early Copilot-harness users hit in production
Copilot Studio users working on the GitHub-lineage harness point to recurring concerns about preview versus production. These reports describe the Copilot Studio GitHub-harness experience before the Foundry preview, included here as an inference about the shared lineage Microsoft describes (blogs.microsoft.com), not as Foundry measurements.
The god damn connectors wont even stay connected for a day in prod. — u/roberts2727 in r/copilotstudio
Sometimes the flows work; other times the agent doesn't pass anything to them at all. — u/donstazz in r/copilotstudio
business users cannot do these app regs etc. and it is IT admins who need to do it. For each and every agent separately. — u/Teemu_St in r/copilotstudio
Reported issues from those threads:
- Slower answers on SharePoint-backed agents, described as significantly slower than alternatives in r/copilotstudio.
- Agents that work in the Studio test pane but fail after deployment to Teams or M365 Copilot with generic errors in r/copilotstudio.
- Connector and flow instability plus repeated authentication and MCP consent friction in r/copilotstudio.
- Billing confusion over whether an M365 Copilot license covers harness runtime or Copilot Credits still apply in r/microsoft_365_copilot.
None of that invalidates the Foundry preview, but it sets the pilot checklist: test with your real knowledge source, your real channel, and your real end-user consent flow before promising timelines.
FAQ
Is the Microsoft Copilot harness the same as the GitHub Copilot harness?
Yes, same GitHub-built lineage under the new Microsoft name; some Copilot Studio docs still use the old name during the transition.
Which models does the Foundry harness support?
More than 20 frontier models plus BYOK with task-based routing; Microsoft does not publish the full list, so check Foundry docs for your region (see multi-model section above).
Can I migrate an existing Foundry agent to the harness?
No in-place switch during preview. Run a parallel evaluation: inventory prompts, tools, auth, and state needs, recreate the agent with microsoft_copilot_preview in a preview project, then compare quality, latency, sandbox usage, and recovery before cutover.
Does an M365 Copilot license cover harness usage?
Not automatically. Foundry meters sandbox compute and memory separately from model inference, while Copilot Studio bills this harness family via Copilot Credits. Verify the meter for your surface.
Should I use the harness or a hosted agent?
Use the harness for managed loop, sandbox, skills, and subagents without owning orchestration. Use a hosted agent when you must control the framework or runtime and can own checkpointing and idempotency.
Start with the research-brief skill pattern in preview, measure sandbox plus token cost against a no-harness prompt agent on the same task, and keep production on your proven path until migration, regions, and consent behavior are documented for your tenant.