In AI agent development, the execution environment that connects a model's capabilities to real work matters as much as the model's reasoning performance. No matter how capable the model, an agent cannot finish its tasks as expected unless prompt and context management, external API calls, file operations, and execution state are all handled properly.
On October 28, 2026, Microsoft released the "Microsoft Copilot harness," the agent execution mechanism behind GitHub Copilot, Copilot Studio, and other products, as a public preview in its cloud service "Microsoft Foundry Agent Service." Microsoft says developers can build AI agents that handle complex work using multiple tools without building and maintaining their own orchestration infrastructure from scratch. However, this is a preview, and not every service guarantee or feature needed for production use is in place. Teams adopting it need to determine what they can hand off to Microsoft and what they must still manage themselves.
What the "Harness" Around an AI Model Is, and the Limits of the Preview
In AI agents, a "harness" is the mechanism that operates around the AI model and lets it work while interacting with external environments. It includes system prompt and context management, calls to external tools via MCP (Model Context Protocol) and similar mechanisms, sandboxes for running code, and the agent loop that manages the model's repeated cycle of decisions and actions. Separate from the model's own reasoning ability, it turns the model's output into concrete operations and controls how the overall work proceeds.
When an agent runs, the necessary context and prompts are prepared in response to user input, and the model decides what to do next. Based on that decision, the agent reads and writes files, runs shell commands, fetches web content, or delegates work to sub-agents. Code and commands are executed in sandboxes with managed resources such as CPU and memory. The harness coordinates this entire sequence and mediates between the model and the external environment.
What Microsoft has released is this execution mechanism, developed by GitHub's engineering team, offered as an additional runtime that can be selected for Microsoft Foundry "prompt agents." This lets developers reduce the burden of deploying and maintaining the agent loop and execution infrastructure themselves, and focus on the knowledge given to the agent, its work procedures, the tools it uses, and model selection. A key feature is that complex workflows involving file operations and code execution become easier to build in a managed environment.
However, the Copilot harness in Foundry is currently offered as a public preview. It carries no service level agreement (SLA), and Microsoft's official documentation does not recommend using it for commercial production workloads. Because it is a preview, features and limitations may change, so careful judgment is needed before adopting it for core business operations.
It is also necessary to distinguish this harness from the general availability (GA) of "long-running resilience," which Microsoft announced around the same time. That GA feature, which recovers interrupted processing, targets "hosted agents," where developers build their own runtime. The Copilot harness itself has not moved to general availability, and this does not mean a production SLA applies to the preview.
How agents are invoked is largely unchanged from existing Foundry prompt agents. Agents using the Copilot harness also run through the Responses API, so they combine easily with development approaches built on existing APIs. But a shared invocation method is a separate matter from whether the underlying runtime offers equivalent operational quality.
Built-in Tools and Sub-agents Combined, but Multi-model Support Has Limits
Foundry's Copilot harness provides an execution environment that integrates reusable skills, connections to external tools, file operations and code execution inside a sandbox, and delegation of work to sub-agents. In newly created agents, five built-in tools are enabled by default: file reading, file writing, shell command execution, web content retrieval, and delegation to sub-agents.
| Built-in tool | Main role | State on new agents |
|---|---|---|
| File read | Retrieve and reference file contents | Enabled |
| File write | Create and modify files | Enabled |
| Shell execution | Run commands and scripts | Enabled |
| Web fetch | Retrieve content from the web | Enabled |
| Sub-agent delegation | Hand work off to another agent | Enabled |
Combining these, an agent can, for example, investigate source code, run the scripts it needs, and, if an error occurs, analyze the cause and attempt a fix. Developers no longer have to implement every tool call and the iterative control of the work themselves, which is a significant advantage in reducing development effort. However, the availability of standard tools does not mean that integration with external systems is unconditionally possible.
External tools connected through MCP and the various services Foundry supports each have their own authentication methods, network requirements, and approval policies. The available models and Azure regions are also restricted, so not every external integration can be handled the way the built-in tools are. Enterprises adopting it should check that it fits their existing access controls and security policies.
Model selection also requires separating Microsoft's announcement as a whole from what is available in the Foundry Copilot harness preview. Across its product line, the company touts support for more than 20 frontier models, BYOK (Bring Your Own Key) using one's own API keys, and automatic routing of models according to the task. But not all of these features are available in Foundry's Copilot harness.
In particular, BYOM (Bring Your Own Model) is not supported in Foundry's Copilot harness. Agents must specify a model that supports reasoning and tool calling and is available for prompt agents in the Azure region being used. The wide range of models Microsoft is supporting company-wide cannot simply be used freely in the Foundry preview environment.
Although Microsoft has promoted a mechanism for routing work to the appropriate model by task, the materials published this time do not confirm that automatic routing across multiple models is uniformly enabled in Foundry's Copilot harness. The reduced session overhead and shorter time to first token from the move to a Rust-based runtime, as well as usage by millions of people, are also descriptions of Microsoft's product line as a whole. They are not performance figures measured by an independent third party in the Foundry preview environment, so the same results are not guaranteed in an actual deployment.
How the Local SDK Differs from Foundry's Managed Version
There are broadly two ways to use the Microsoft Copilot harness. One is the "Microsoft Copilot SDK," which developers control in their local environment or on their own infrastructure; the other is the "Foundry Agent Service," which Microsoft manages in the cloud. Both use the same harness technology, but they differ in who manages the execution environment, in authentication methods, and in the division of operational responsibility. Foundry also offers another option, "hosted agents," which host a developer's own agent code.
| Approach | Who manages the execution environment | Main uses | Availability and constraints | Cost and authentication considerations |
|---|---|---|---|---|
| Microsoft Copilot SDK (local / own environment) | Developer manages local environment, containers, etc. | Development environment automation, CI/CD integration, custom execution control | Available on GitHub. In the middle of a name transition, so package names and other details still differ | GitHub Copilot subscription, or BYOK with an API key from a supported provider |
| Foundry Copilot harness (managed version) | Microsoft manages the cloud sandbox | Rapid development of agents using standard tools, reduced burden of managing the execution environment | Public preview. No production SLA. Existing agents cannot be switched over | Usage-based sandbox billing from December 1, 2026. Model inference costs are charged separately |
| Foundry Hosted Agents | Developer owns the agent code and execution logic; Foundry manages the hosting environment | Cloud operation while keeping your own frameworks and middleware | Long-running resilience and other features for hosted agents are generally available | Infrastructure costs for running containers, plus model inference costs |
GitHub is in the process of renaming the interface previously called the "GitHub Copilot SDK" to the "Microsoft Copilot SDK." As a result, some documentation and package names still use the old name, and users should watch for differences in names and configuration methods when adopting it. Supported languages are broad, including Node.js/TypeScript, Python, Go, .NET, Rust, and Java, making it easy to fit into existing development environments.
The SDK communicates over JSON-RPC with a Copilot CLI server that the application starts in the background. Normally the SDK manages starting and stopping the CLI process automatically, but behavior varies by language environment. The CLI executable is bundled for Node.js, Python, and .NET, whereas for Go, Java, and Rust, developers must install the CLI separately or set the path to the executable.
Authentication also differs. Using the SDK in the standard way requires an active GitHub Copilot subscription. With BYOK, which uses an API key from a supported provider, it can be used without GitHub authentication, but current BYOK authentication is limited to API keys. Authentication and access control using Microsoft Entra ID, managed identities, or external identity providers are not directly supported by the SDK's BYOK feature.
In Foundry's managed version, by contrast, management of the CLI process and sandbox is left to Azure. Developers no longer need to manage the execution environment directly, but they become subject to the resource and approval-policy constraints set by the service. The SDK's flexible local integration and the cloud management features Foundry provides suit different requirements. Even under the same name, Copilot harness, the two should not be treated as the same operating model.
What Remains the Developer's Responsibility in Long-running Work and Failure Recovery
When entrusting long, complex work to an AI agent, how to recover when processing is interrupted matters as much as managing the execution environment. The long-running resilience feature Microsoft provides restarts the agent when it detects an interruption and resumes processing using the original input. But even with such a feature, it is not guaranteed that the agent can accurately restore how far it had progressed before the interruption.
For example, even if conversation history is retained, the state of files in progress or of external systems may not be automatically restored. Without a mechanism to save processing checkpoints and intermediate outputs, the agent may have to start over from the beginning. To reliably continue long tasks, it is important for developers to persist progress and results so they can be referenced on re-execution.
Of particular concern is the risk of duplicate updates to external systems. Suppose, for example, processing is interrupted right after an agent updates a database via an API or creates a pull request on GitHub. If the restarted agent repeats the same operation, the update could be applied twice or the same pull request could be created more than once. Preventing this requires checking whether the processing has already been completed before performing the operation.
This property, in which repeating the same operation does not change the result, is called idempotency. If an external API provides idempotency keys or similar, they can be used, but not every external service supports them. Designing so that re-execution by the agent does not duplicate side effects remains an important responsibility on the developer's side, even when the execution infrastructure is left to Microsoft.
In addition, the Foundry Copilot harness public preview has the following limitations.
- Existing agents cannot be switched over: The Copilot harness must be selected when creating a new agent; existing prompt agents cannot be switched to it afterward.
- Sandbox resources are fixed: Execution resources such as CPU, memory, and idle time are set by Microsoft and cannot be freely changed by users.
- Approval policies for built-in tools are managed by Microsoft: The
require_approvalflag that users can set applies to additional MCP tools, and the approval policies of built-in tools cannot be changed arbitrarily. - Sending data to external services requires separate caution: When connected to external tools or endpoints, data leaves Foundry's managed scope and is processed under the terms of the connected service.
The Azure regions, clients, network configurations, and available quotas supported in the Copilot harness preview are also more limited than for Foundry Agent Service as a whole. Enterprises considering adoption must confirm whether the service is available in the regions they need and whether it fits their existing network configurations and security requirements. Even with a managed service, Microsoft will not resolve every failure arising from external integrations and business processing.
Sandbox Billing Starts December 1; Effective Cost Is the Key Adoption Question
Another important factor in deciding whether to adopt the Copilot harness is the pricing structure. Microsoft has announced that usage-based billing for the Copilot harness sandbox in Foundry Agent Service will begin on December 1, 2026. From the start of the preview through the end of November, harness runtime usage is free, but model inference costs and fees for separately billed connected services are incurred even during the preview.
From December 1, sandbox compute costs will be charged on top of these. The published standard rates are US$0.0994 per vCPU-hour and US$0.0118 per GiB-hour of memory. Actual rates, however, vary with the Azure region and each company's contract terms.
| Billing item | Published standard rate |
|---|---|
| vCPU | $0.0994 / vCPU-hour |
| Memory | $0.0118 / GiB-hour |
Source: Microsoft Foundry official announcement. Standard rates applicable from December 1, 2026; they vary by region and contract terms.
Under this pricing, not only the tokens the AI model consumes but also the sandbox's running time affects cost. For example, if an agent sits idle for long periods or repeats inefficient loops, compute costs during that time can accumulate. To estimate actual costs, one must consider not only the number of tokens used for inference but also the CPU and memory allocation, sandbox running time, and fees for external services.
Nor does every agent need the Copilot harness. For answering simple questions or calling a single search tool, a conventional prompt agent without the harness may be sufficient. For such uses, adopting the Copilot harness can complicate the execution infrastructure and add compute costs, so it is not necessarily a rational choice.
On the other hand, where you need your own framework or specialized middleware, or for core business operations that require fine-grained control of the execution process, Foundry hosted agents may be a better fit. They let developers maintain the agent's execution logic while using a cloud hosting environment. Such a setup gives you a wider range of control, but it also means greater responsibility for maintaining the execution logic and related components.
The Copilot harness is a strong option for uses that fall in between. It suits cases where you want to build autonomous workflows that combine multiple standard tools, such as file operations, code execution, and delegation to sub-agents, while keeping the operational burden of the execution infrastructure low. For tasks involving multiple stages of operations, such as development support, research, and file processing, using the existing harness features may reduce the need for custom implementation.
However, how much development effort and operating cost adoption actually saves depends on the actual workload. A wide choice of models and a rich set of standard tools alone cannot establish the economic case for adoption. What should be compared is the completion rate of the target tasks, how often human correction or approval is needed, the time the whole process takes, and the effective cost combining inference and sandbox expenses.
The external release of the Microsoft Copilot harness shows that, in AI agent development, the execution foundation that lets teams use model capabilities reliably is becoming as important as model performance. Being able to use the tool integration and agent loops that developers have implemented individually as a managed service could reduce development and maintenance burdens. But the current Foundry version is a public preview, and constraints remain around the production SLA, resource settings, model selection, and migration of existing agents.
Going forward, attention will be on how much actual operating costs come to after billing starts on December 1, and how far automatic routing across multiple models becomes available on Foundry. Whether migration of existing agents and production-grade service guarantees are put in place will also influence enterprise adoption. The value of the Copilot harness will be determined not only by how much of the agent's processing can be left to Microsoft, but by whether, with the areas developers must still manage made clear, it can improve reliability and cost-effectiveness in real business use.