Switching models without rebuilding the entire execution chain becomes a credible architecture choice with the Copilot harness. In Microsoft Foundry, however, this flexibility is still in public preview and brings new rules on versions, data flows and the traceability expected under Law 25.
The harness separates the model from the agent system
A model provides reasoning capabilities. The harness orchestrates what allows it to act: instructions, context, tool calls, the agent loop, the execution environment and operational controls.
This separation reduces the dependency between an agent and a model family. A team can evaluate a different model without systematically rewriting the tools, skills or the application that consumes the agent. The expected benefit is therefore not only model performance, but the stability of the architecture around it.
Microsoft presents this foundation as common to several Copilot and GitHub experiences. This convergence makes it easier to share improvements, but it does not mean that each product offers the same models, options or availability statuses. The map of the Microsoft Copilot ecosystem helps distinguish these different surfaces.
In Microsoft Foundry, formerly Azure AI Foundry, the Copilot harness remains a prompt agent built on the Responses API. Foundry handles the execution environment, the agent loop and the sandbox. The team remains responsible for the instructions, tools, connections, skills and the selected model.
The preview requires irreversible decisions
The Microsoft Foundry technical announcement confirms that the Copilot harness is in public preview. It is selected when creating a prompt agent. Existing agents are not converted automatically.
The harness choice is fixed at creation
It is not possible to replace an agent's harness after it has been created. A pilot must therefore plan for creating a new agent, as well as a procedure to migrate tests, connections and consumers.
The timeline distinguishes three developments that should not be confused:
September 2026
Long-running resilience in preview
Resuming interrupted work for hosted agents was still in public preview.
October 2026
Copilot harness in public preview
The harness becomes selectable in Foundry Agent Service. Long-running resilience for hosted agents separately reaches general availability.
December 1, 2026
Harness billing begins
Sandbox compute and memory become billed on a consumption basis. Model inference and paid tools remain billed separately.
Running the harness is free until December 1, 2026. After that date, Microsoft announces the following rates:
0,0994 USD
per vCPU-hour for sandbox compute
Microsoft Foundry
0,0118 USD
per GiB-hour for sandbox memory
Microsoft Foundry
A cost calculation must therefore add up the sandbox, inference and any billed tools. A pilot run before December 1, 2026 will not on its own reflect the recurring cost.
Three agent architectures to compare
The Copilot harness is not the only option offered by the Foundry ecosystem. The right choice depends on the level of control required, the team's ability to maintain an agent loop and the constraints placed on the model.
| Approach | Execution | Relevant status | BYOM | Governance consequence |
|---|---|---|---|---|
| Prompt agent with Copilot harness | Loop and sandbox managed by Foundry | Public preview | Not supported | Managed foundation, but harness fixed at creation |
| Hosted agent | Agent code hosted by Foundry | Long-running resilience generally available | Depends on the chosen architecture | More freedom and more controls to design |
| Custom harness or framework | Operations defined by the team | Depends on the deployment | Depends on the implementation | Maximum control, with maintenance and evaluations the organization's responsibility |
BYOM, or Bring Your Own Model, is not supported by the Copilot harness in Foundry. An organization that must use a model it brings itself therefore cannot treat this preview as a direct replacement for its current architecture.
Products must also be distinguished. A harness reaching general availability in another surface does not change the status of the Copilot harness in Foundry. This difference is notably visible with the GitHub Copilot harness in Copilot Studio.
For Microsoft 365 teams, the Copilot Managed Runtime addresses a different problem: managed code execution within the Copilot environment. Both approaches reduce the operational burden, without covering the same scenarios or the same data boundaries.
Law 25 shifts the analysis from the model to the whole chain
Multi-model does not reduce governance to choosing a provider or a model. For an organization subject to Law 25, the decision must cover the complete agent: data received, model selected, tools called, external connections, outputs produced and the people authorized to modify its configuration.
The Foundry Agent Service FAQ specifies that data may leave Foundry when a tool, a connection or an external endpoint is configured. Changing the model therefore does not fix a poorly controlled data flow at the tool level.
Illustration: a Quebec team creates an agent responsible for producing a report from internal documents. The agent queries an approved repository, then calls an external service to enrich the result. Even if the model remains unchanged, this second call modifies the processing chain and must be included in the decision file.
Decision file for an agent subject to Law 25
- Define the agent's purpose and designate its operational owner
- Establish the categories of data that are allowed and those that must be excluded
- Document the model, its version and the criteria used to select it
- Inventory every tool, connection and external endpoint
- Define the roles authorized to publish a new version of the agent
- Plan the tests, validation evidence and rollback procedure
This list is a technical governance framework. The legal qualification and the applicable controls must still be validated with the organization's privacy officers and legal teams.
Conversations define the version boundary
Changing an agent version does not automatically interrupt an environment that is already active. The agent configuration documentation indicates that a new conversation immediately uses the selected version, while a running environment may keep the old one until it becomes inactive.
This nuance affects regression testing and traceability. To obtain a clean version boundary, Microsoft recommends starting a new conversation after the change.
Publish the version in a validation environment
Associate the version with its model, instructions, connections and the skill versions used.
Start a new test conversation
Do not use an already active conversation to conclude that the new version is correctly loaded.
Check resumption and duplicate actions
For a long task, verify that the agent saves its progress and does not recreate a report, ticket or other resource that has already been produced.
Long-running resilience for hosted agents has been generally available since October 2026. Foundry can restart interrupted work with its original input, but the code must handle checkpoints and idempotence. Without these safeguards, resilience can repeat an action that has already been executed.
Skills improve reuse, not control automatically
Foundry skills are in preview. They take the form of folders containing a SKILL.md file, following the open Agent Skills format, and are versioned through a dedicated API.
A prompt agent using the Copilot harness can reference these skills. The Microsoft Learn documentation on skills lets you pin a version to keep an immutable snapshot. When no version is specified, Foundry freezes the default version available at the time of the reference.
Pinning simplifies the reproducibility of a test and the analysis of an incident. It does not replace the review of the content of SKILL.md, the tools used or the permissions granted to the agent.
An external tool can move the data boundary
Validate the endpoint, the data transmitted and the access controls before enabling an external connection. The Foundry-managed environment does not guarantee that data stays in Foundry when the agent calls a third-party service.
Frequently asked questions
Is the Copilot harness in Microsoft Foundry generally available?
No. It has been in public preview since October 2026. The general availability of long-running resilience for hosted agents concerns a separate capability.
Can the Copilot harness be added to an existing agent?
No. Existing agents do not change and the harness is chosen while creating a new prompt agent. It is then not possible to replace that harness.
Can you bring your own model to the Copilot harness?
No. BYOM is not supported in this Foundry preview. The choice remains limited to the models offered as part of the service.
Does a new version immediately replace the one in an active conversation?
Not necessarily. A new conversation uses the selected version, but an already active environment can continue with the old version until it becomes inactive. A new conversation provides a more reliable separation for testing.
What costs are added after December 1, 2026?
Sandbox compute is billed at USD 0.0994 per vCPU-hour and its memory at USD 0.0118 per GiB-hour. Model inference and paid tools are added to these amounts.
Three decisions to make before the pilot
The first pilot must validate governance as much as the quality of the answers. A working demonstration is not enough if it ignores versions, external calls or the real cost after the free period.
Before creating the first agent
- Choose between a prompt agent with harness, a hosted agent and a custom architecture
- Confirm that the absence of BYOM is compatible with the model policy
- Select a limited use case with approved data
- Define an evaluation set common to the models being compared
- Pin skill versions and keep the validation results
- Measure the cost of the sandbox, inference and tools separately
- Test a new conversation after each version change
If the organization requires a model it brings itself or full control of the agent loop, it should keep a hosted or custom approach. If it favors managed execution and models supported by Foundry, the Copilot harness deserves a supervised pilot, without being treated as an already stabilized service.
Going further
- Introducing the Microsoft Copilot harness in Foundry Agent Service — the official status, pricing and selection criteria.
- Foundry Agent Service FAQ – Microsoft Copilot harness — the preview's limits, BYOM and external flows.
- Use skills in Foundry — creating, versioning and referencing skills.
- What’s new in Microsoft Foundry | September 2026 — an example of a Copilot SDK harness in a hosted agent.
