Microsoft Makes Copilot Harness Available Through Foundry

Microsoft on October 28, 2026 made the Microsoft Copilot harness — the multi-model orchestration layer that already powers Copilot Code, Copilot Studio, the GitHub Copilot app, the Copilot CLI, and VS Code — available to developers and enterprise customers through Microsoft Foundry, in an announcement on the Official Microsoft Blog.

Microsoft describes a harness as everything around the model: the orchestration layer that gives an agent the right instructions, context, execution environment, and controls to accomplish work, with support for open standards such as the Model Context Protocol plus agent skills and agent plugins. The GitHub engineering team built the Copilot harness, and Microsoft has adopted it company-wide. A companion Microsoft Foundry Blog post the same day introduced the harness in Foundry Agent Service in public preview and announced general availability of long-running resilience for hosted agents.

Microsoft said the harness is built to perform across model families, with support for more than 20 frontier models plus bring-your-own-key, and that it routes work to the right model or models based on the task. The company said it runs the agent loop and sandbox with governance and optimization built in, while customers supply the instructions, skills, tools, and model choice. The Copilot SDK is available to download, and the harness can also run in the cloud managed by Foundry; Microsoft said its platforms remain open to other harnesses and frameworks.

Managed Execution in Foundry Agent Service

The public preview combines four building blocks, according to the Foundry Blog post. Reusable skills package instructions, scripts, and supporting resources into procedures an agent can apply across tasks. Connected tools span supported Foundry and Model Context Protocol tools with explicitly configured authentication and approvals. Execution and delegation let agents work with files and code and hand bounded tasks to built-in subagents while the main agent coordinates the result. Source-controlled agent definitions can be managed alongside application code. The harness manages working context as tasks develop and coordinates model and tool steps within configured limits and policy boundaries, and customers can choose a supported Foundry model without rewriting the orchestration around it.

Developers can author agents through the preview Azure Developer CLI (azd) surface, the Foundry portal, the Foundry Toolkit for Visual Studio Code, or the Microsoft Foundry plugin and skill in the GitHub Copilot app. The post includes statements from two companies. Confluence Technologies CTO Chris Evans said his team had a solution running in less than a week, letting it focus on design and capabilities rather than the infrastructure underneath. Fashable CEO Orlando Ribas Fernandes said the harness gives the company a foundation for turning complex sourcing processes into governed, measurable agent workflows while keeping commercially binding decisions under human control.

Preview Limits and December Billing

During the preview, customers select the Microsoft Copilot harness when creating an agent. Existing agents are unchanged, switching the harness after creation is not yet supported, and Foundry manages the execution environment’s CPU, memory, and idle settings.

Billing for the Copilot harness in Foundry Agent Service begins December 1, 2026 on a consumption basis. Harness runtime usage is free before that date, while model inference and separately billed tools and connected services remain subject to their applicable charges. Starting December 1, sandbox compute is billed at $0.0994 per vCPU-hour and memory at $0.0118 per GiB-hour, with prices varying by region and agreement.

The post also lays out three approaches in Foundry Agent Service: prompt agents without the harness when instructions and supported tools are enough for the task; prompt agents with the Copilot harness for managed execution with skills, files, and subagents; and hosted agents when teams need their own framework, agent loop, middleware, dependencies, or runtime behavior while retaining Foundry-managed hosting.

Long-Running Resilience for Hosted Agents

Long-running resilience for hosted agents is generally available, aimed at work that takes hours or days. Foundry detects interruptions and restarts the work with its original input, while the customer’s code saves progress and intermediate results so the agent can resume where it left off. When an agent updates another system, the workflow must also prevent duplicate actions on restart. Microsoft noted that conversation history alone is not enough to restore work in progress.

Built at GitHub

Microsoft said the harness was built by the same GitHub engineers behind its multi-model orchestration work, and that it is standardizing its Copilot experiences on that foundation. On September 4, 2026, GitHub introduced Project HydraFusion, a research preview that builds an execution plan across models from multiple providers using three patterns: single, in which one model solves the task directly; cascade, in which an efficient model drafts a solution and a quality gate decides whether to escalate to a stronger model; and critique, in which an independent read-only critic from a different model family reviews a draft before the drafting model revises it. GitHub reported that in offline evaluations HydraFusion improved verified task quality by 4.9 percentage points at 67% lower estimated cost than Claude Opus 5 on TerminalBench 2.1, came within 1.5 points on DeepSWE at 36% lower cost, and came within 0.1 points on its internal CheckpointBench at 65% lower cost.

GitHub had also disclosed on September 16, 2026 that it ported the Copilot agent runtime from TypeScript to Rust in place, reaching 832,378 lines of production Rust by August 21, 2026 across 128 incrementally shipped pull requests, with the Copilot SDK exposing the runtime to six language front-ends. Microsoft attributes industry-leading performance and reductions in session overhead and time-to-first-token to the port. In benchmarks that Microsoft Distinguished Engineer Stephen Toub ran through the C# SDK, the time to create a client and session and complete one turn fell from 5.25 seconds before the port to 292 milliseconds with the Rust runtime loaded in-process, and peak added memory in a ten-client batch fell from 1,383 MB to 126 MB.