Microsoft is letting outside developers build on the same agent machinery it uses inside its own Copilot products. On October 28, Microsoft announced on its official blog that the Microsoft Copilot harness, built by GitHub engineers, is now available through Microsoft Foundry, Microsoft's platform for building AI apps and agents. A companion post on the Microsoft Foundry Blog says the harness is in public preview in Foundry Agent Service.
The news landed on the same day GitHub made Copilot Fusion generally available, and it is part of the same push: Microsoft wants one shared layer under every Copilot surface, and it now wants customers to build on that layer too.
What a harness is
A model answers a prompt. An agent has to finish a task, which can mean many model calls, tool calls, files and decisions in a row. Microsoft's blog post puts it this way: "If the model supplies the intelligence, the harness is everything around the model." It describes the harness as "the orchestration layer that gives an agent the right instructions, context, execution environment, and controls to accomplish meaningful work," and says a good harness supports open standards such as MCP (the Model Context Protocol, a common way to connect tools to AI models), agent skills and agent plugins. If you are new to the idea, our explainer on what an AI agent is covers the basics.
According to the Microsoft blog, the Copilot harness already powers Copilot Code, Copilot Studio, the GitHub Copilot app, the CLI, VS Code "and more." It became the default for new sessions in VS Code earlier this month, as we covered in our VS Code 1.143 explainer.
What Microsoft says the harness does
The Microsoft blog makes these claims about the harness:
- It is "built to perform across model families, with 20+ frontier models plus bring your own key."
- Microsoft can "intelligently route work to the right model or models based on the task," so customers do not have to evaluate each new model themselves.
- Microsoft "recently ported the harness runtime to Rust," which it says reduced session overhead and time to first token. The post gives no benchmark figures for this.
- "The SDK is available to download, or you can run the harness in the cloud, all managed by Foundry."
- "Microsoft runs the agent loop and sandbox, with governance and optimization built in from day one. You bring the instructions, skills, tools, and model choice."
In a separate GitHub changelog entry the same day, GitHub said the GitHub Copilot SDK is becoming the Microsoft Copilot SDK, "the programmable interface for the Microsoft Copilot harness." GitHub says the move will happen in phases, existing package names may still reference GitHub Copilot SDK for a while, and "No immediate changes are required for existing users."
What you get in the Foundry preview
The Foundry Blog post lists four building blocks in the public preview:
- Reusable skills. Instructions, scripts and supporting files packaged as procedures an agent can apply across tasks.
- Connected tools. Supported Foundry and MCP tools, "with explicitly configured authentication and approvals."
- Execution and delegation. Agents can work with files and code, and hand bounded tasks to built-in subagents while the main agent coordinates the result.
- Source-controlled agent definitions. You can build in the Foundry portal, or keep agent definitions next to your application code.
The post shows an example agent defined in an azure.yaml file with a harness type of microsoft_copilot_preview, then deployed with the Azure Developer CLI (azd). It says you can also start in the Foundry portal, use Foundry Toolkit for Visual Studio Code, or use the Microsoft Foundry plugin in the GitHub Copilot app.
The Foundry Agent Service overview on Microsoft Learn says that when you select the harness, "The resource remains a prompt agent, and you continue to interact with it through the Responses API."
Three ways to build in Foundry
Microsoft now offers three levels of control. The Foundry post sums up when to choose each:
- Prompt agents without the harness: when "Instructions and supported tools are enough for the task."
- Prompt agents with the harness: when "You want skills, managed execution, files, subagents, and more complex tool coordination without owning the harness."
- Hosted agents: when you need to bring or change your own framework, agent loop, middleware or runtime, with Foundry still handling hosting.
The same post says long-running resilience for hosted agents is generally available this week. Foundry detects interruptions and restarts work with its original input, but your own code must save progress and avoid duplicate actions on restart.
Preview limits and regions
The Foundry post lists three limits for the preview: you select the harness when you create the agent, existing agents are unchanged, and "switching the harness after creation isn't supported yet." Foundry also manages the execution environment's CPU, memory and idle settings, so you do not size the sandbox yourself.
The Microsoft Learn limits page adds more detail. During the preview, the harness runs in nine Azure regions: Australia East, Canada Central, Central US, Germany West Central, Japan East, Sweden Central, UK South, West Europe and West US. It needs a model that supports reasoning and tool calling, bring your own model is not supported, and Foundry Memory is not available. Foundry Agent Service itself is generally available; the harness is the preview part.
What it costs
Per the Foundry Blog post, billing for the harness begins December 1, 2026, with consumption-based pricing:
- Before December 1: harness runtime usage is free.
- From December 1: sandbox compute is billed at $0.0994 per vCPU-hour, and sandbox memory at $0.0118 per GiB-hour.
- At all times: model inference and separately billed tools and connected services are charged at their own rates.
Microsoft adds that "Prices may vary by region and agreement." As a rough illustration (our arithmetic, not a Microsoft figure), a sandbox using 1 vCPU and 2 GiB of memory for one hour would cost about $0.12 in harness charges, before any model or tool costs. Since Foundry sets the CPU and memory, the real size of a session is not under your control during the preview.
Why it matters
Most teams that build agents end up writing the same loop: call the model, call a tool, keep the context, decide what to do next. Microsoft is betting that teams would rather rent that loop than maintain it, and that a harness tested across its own products is a strong offer. It is the same pitch Cursor made with its Agent SDK, from a different direction.
Not every user is convinced yet. In a September thread on r/copilotstudio, before the Foundry launch, one user wrote that the harness in Copilot Studio is "ridiculously slow with zero actual optimization or agentic capability happening here, oh yeah, and you're billing at token level rates." That is about Copilot Studio, not Foundry, but it shows billing clarity will matter when the free period ends.
For developers, the practical point is simple: harness runtime is free until December 1 (model and tool charges still apply), and after that you pay by the sandbox hour on top of model costs.
Sources
- Microsoft blog: Introducing the Microsoft Copilot harness
- Microsoft Foundry Blog: Introducing the Microsoft Copilot harness in Foundry Agent Service
- Microsoft Learn: What is Microsoft Foundry Agent Service?
- Microsoft Learn: Foundry Agent Service limits, quotas, and regional support
- GitHub Changelog: GitHub Copilot SDK is becoming Microsoft Copilot SDK
- Reddit r/copilotstudio: Github Copilot Harness is straight up bad
