Microsoft introduced the Copilot harness in Foundry Agent Service in public preview on October 28, 2026. The service gives developers a Microsoft-managed execution loop and sandbox for agents that use tools, work with files, execute code and delegate bounded tasks to built-in subagents.
The announcement also sets a budgeting deadline: harness runtime billing begins December 1, 2026. Until then, Microsoft says the runtime is free, although model inference and separately billed services still cost money. Microsoft separately announced general availability of long-running resilience for hosted agents. That GA milestone does not change the Copilot harness’s preview status. (Microsoft announcement)
For enterprise developers, the consequential change is how much execution machinery they need to own. Foundry already supported hosting agents built with other frameworks. This preview adds a managed option in which Microsoft runs the agent loop, while developers supply procedures, tools, instructions and evaluation criteria.
One preview restriction deserves attention before any migration planning: developers choose the harness when creating an agent, and switching it afterward is not yet supported.
What Microsoft’s Managed Harness Handles
An agent harness is the software surrounding the model. It coordinates model requests and tool calls, maintains working context and manages the steps needed to complete a task. A capable model still needs this execution layer to turn a request into a sequence of actions.
Microsoft’s preview packages that layer around four building blocks:
| Building block | What the announcement describes | Practical consequence |
|---|---|---|
| Reusable skills | Instructions, scripts and supporting resources packaged as procedures | Teams can maintain a shared method for recurring work |
| Connected tools | Supported Foundry and Model Context Protocol, or MCP, tools with explicitly configured authentication and approvals | Tool access needs deliberate configuration |
| Execution and delegation | File operations, code execution and bounded tasks assigned to built-in subagents | The main agent can coordinate work that needs more than a model response |
| Source-controlled definitions | Agent definitions and supporting resources managed alongside application code | Changes can go through the team’s normal review process |
The harness also manages working context as a task develops and coordinates steps within configured limits and policy boundaries. Developers can select a supported Foundry model without rebuilding the surrounding orchestration, according to Microsoft’s description.
A skill is particularly useful to distinguish from a prompt. It can contain a procedure plus scripts and other resources the agent needs to follow that procedure. Packaging those together gives a team a concrete artifact to review and reuse. It does not train the underlying model.
Configured approvals matter just as much. MCP provides a way to connect tools, but connecting an endpoint does not by itself define what an agent should be authorized to do. Authentication and approval settings remain part of the developer’s setup.
I’d treat those settings as part of the application’s behavior, alongside its instructions. An agent that can retrieve a purchase order and one that can authorize payment have very different consequences, even if both use the same model.
How the Published Setup Fits Together
Microsoft illustrates the preview with a research-brief agent built through the preview Azure Developer CLI, or azd, interface.
The example separates three pieces:
- A skill directory containing a
SKILL.mdprocedure. - An
azure.yamldefinition connecting the Foundry project, skill and agent. - Agent instructions and tool declarations for web search and Code Interpreter.
Within the agent definition, the relevant selection looks like this:
harness:
type: microsoft_copilot_preview
model: ${MODEL_DEPLOYMENT_NAME}
skills:
- research-brief-skill
This is an excerpt from Microsoft’s published configuration, not a complete deployment file. It selects the preview harness, references a model deployment and attaches the declared skill. The surrounding example also requires a Foundry project endpoint, a skill resource and tool configuration.
The research procedure tells the agent how to scope a question, gather evidence, distinguish findings from interpretation and use calculations when useful. The agent definition then connects that procedure to the execution environment.
That separation is worth preserving in a prototype. Put reusable methods in skills, task-specific goals in instructions and access decisions in tool configuration. Combining all three into one large prompt would make it harder to review a change or identify why behavior shifted.
Source control helps make these components inspectable. It does not guarantee reproducible outputs: model responses, retrieved evidence and external tool results can still vary. Teams still need representative evaluation tasks and checks for acceptable behavior.
The Preview Constraint Changes Migration Planning
Microsoft says existing agents remain unchanged. Developers select the Copilot harness when creating a new agent, and changing the harness after creation is not supported during preview. (Preview details)
That makes this a new-agent evaluation decision, not an in-place runtime toggle.
A practical comparison would create a separate Copilot-harness agent and give it the same representative workload as an existing implementation. Compare task completion, tool permissions, failure handling, output quality and total cost before deciding whether to move application traffic.
Source-controlled definitions help preserve the configuration used in that comparison. They do not remove the creation-time restriction or prove that a definition will behave identically under another harness.
Microsoft limits the offering to supported models and tools. Regional availability, supported combinations and preview limits need checking for the intended deployment; the supplied announcement does not provide a complete availability matrix. The evidence here describes published capabilities, with no independent performance measurements.
My view is that teams should create an evaluation agent early, while keeping their current deployment intact. That approach tests the managed loop without making a preview limitation part of the production migration path.
Long-Running Resilience Has a Separate GA Milestone
The October announcement gives long-running resilience for hosted agents a different release status from the Copilot harness: resilience is generally available, while the harness is in public preview.
Microsoft’s earlier April 22 hosted-agents announcement described per-session, VM-isolated sandboxes, persistent filesystems and scale-to-zero behavior. Microsoft said files, disk state and session identity survive those scale-to-zero events.
Those infrastructure properties address a different problem from choosing the agent’s execution loop. Persistent files can preserve work across a suspended session; they do not determine whether an agent chooses the right next action.
The practical reading is to assess the layers separately. A generally available resilience capability is useful infrastructure news, but it is not evidence that every behavior of the new managed harness has reached the same maturity.
December 1 Pricing: Compute Is Only Part of the Bill
Microsoft lists two sandbox resource rates beginning December 1, 2026:
| Sandbox resource | Published rate |
|---|---|
| Compute | $0.0994 per vCPU-hour |
| Memory | $0.0118 per GiB-hour |
Microsoft says prices are subject to region and customer agreement. Before December 1, harness runtime is free, while model inference and separately billed services retain their normal charges. (Pricing announcement)
Frequently Asked Questions
3 questions
1Is the Copilot Harness Generally Available?
No. Microsoft announced the Copilot harness in public preview. Long-running resilience for hosted agents reached general availability separately in the same announcement.
