Microsoft now sells the agent loop itself. The Copilot harness in Foundry makes orchestration a priced service

For two years, the code around a model has been the part of an agent that every enterprise team wrote for itself: the loop that decides the next step, the context it carries, the tool calls, the sandbox where code runs, the subtasks it hands off. On October 28, Microsoft put a price on that layer.

The Microsoft Copilot harness, now in public preview in Foundry Agent Service, is a managed execution system for agents you define declaratively. In Microsoft’s words, “Microsoft runs the agent loop and sandbox.” You choose a supported Foundry model, connect Foundry and MCP tools with their authentication and approvals, add reusable skills and keep the agent definition in source control. The harness coordinates model and tool calls, maintains working context, manages files and code execution, and delegates bounded tasks to built-in subagents.

What it costs, and what is GA

The harness runtime is free until December 1, 2026. After that, billing is by consumption: $0.0994 per vCPU-hour of sandbox compute and $0.0118 per GiB-hour of memory, plus model inference and any separately billed tools. Prices may vary by region and agreement. Supported regions, models, tools and preview limits are listed in Foundry’s documentation, not in the announcement.

Two pieces are generally available alongside the preview. Long-running resilience for hosted agents, for teams that run their own framework in Foundry, is GA. And on GitHub, Copilot Fusion is now GA: it routes coding tasks across models at three effort levels using a single model, a cascade that escalates when a quality check fails, or a critique loop where one model reviews another. It is the production version of what we analyzed as HydraFusion Max. GitHub reports Fusion Max within two points of Claude Code with Opus 5.5 Max on the Artificial Analysis Coding Agent Index at about half the API cost per task; each model used is billed at its own rate.

The harness is the part that used to be yours

We have argued that the harness is what an enterprise should build once and reuse across agents. Microsoft’s offer changes that calculation in a specific way: you can now rent the execution half of the harness and keep the governance half.

• The loop: the harness decides the next step and delegates subtasks; you still decide what the agent is for and when it must stop.
• Context: the harness keeps working memory inside a run; you still decide which data it may see and how long anything is kept.
• Tools: the harness makes the calls; you still decide which tools exist, with which permissions and approvals.
• Code: the harness provides the sandbox; you still decide what may leave it.
• Cost: the harness meters; you still own the budget and who pays it.

That split is reasonable for many teams. A custom loop is expensive to maintain, and model upgrades keep breaking it. The trade is dependency: the agent’s behavior is now partly defined by a runtime you do not version. When Microsoft improves the harness, your agent changes. Ask how harness versions are announced, whether you can pin one, and how your evaluation suite will catch a change in behavior.

Decide by what you need to prove

Use the managed harness when the agent’s value is in its tools and data, and when evidence of what happened can come from Foundry’s traces plus your own logs. Keep a custom loop, or a hosted agent with your own framework, when a regulator or auditor needs you to show exactly how the next step was chosen, or when the loop itself encodes a validated procedure.

Either way, keep the agent definition, the tool permissions and the evaluation set in your repository. Those are the parts that move with you if the runtime ever has to change.