Microsoft’s new Copilot harness makes agents easy — until you want to switch

Microsoft’s Copilot harness is a managed runtime for autonomous agents. It provides the orchestration infrastructure used across Microsoft’s Copilot products and is now available to outside developers through Foundry Agent Service. Microsoft runs the agent and manages its execution environment, while developers choose a supported model and configure instructions and tools.

The harness manages model and tool calls, tracks context, and keeps the agent within configured policies. Developers can add reusable skills containing instructions, scripts, and resources. Agents can work with files, run code, use authenticated MCP integrations, and delegate tasks to subagents. The main agent coordinates their results.

This makes agent deployment easier because much of the runtime work is managed for the developer. However, the convenience comes with limits. Microsoft controls resources such as CPU, memory, and idle time, and the chosen harness cannot later be changed for that prompt agent.

Microsoft is extending one shared Copilot harness across several products and developer tools. The same infrastructure now supports Copilot Code, Copilot Studio, GitHub Copilot, the CLI, and VS Code. That gives Microsoft a common foundation for orchestrating agents across coding, development, and other Copilot experiences.

The harness is not limited to Microsoft’s internal products. Through Foundry Agent Service, outside developers can use the managed service to build and deploy autonomous agents. They select a compatible model, write instructions, configure tools, and let Microsoft operate the runtime.

This shared approach is part of Microsoft’s broader Foundry strategy, outlined at Build 2026. The strategy aims to make agents easier for companies to run, manage, and control. It also means the same orchestration patterns can appear across Microsoft’s Copilot products and developer workflows, rather than each tool using an entirely separate agent infrastructure.

During execution, Microsoft’s harness coordinates the moving parts of an agent. It manages model calls and tool calls, tracks context, and keeps activity within configured policies. This reduces the amount of runtime orchestration developers must build themselves.

A skill can package instructions, scripts, and supporting resources for a particular job. An agent can also use files, run code, and connect to MCP integrations. Those integrations require authentication and approval. When a task is divided, the agent can delegate work to subagents. The main agent then coordinates and uses their results.

A research agent shows the mechanism in practice. Its Markdown skill describes how to collect evidence, analyze data, and write a report. An azure.yaml file defines the model deployment, tools, instructions, and harness. Developers keep these files in source control, deploy with Azure Developer CLI, and invoke the agent through that same CLI.

The managed Copilot harness offers choice, but not complete control. Developers can select compatible models deployed through Microsoft Foundry. However, the managed service does not support bringing a developer’s own model. Microsoft therefore controls an important part of the model environment.

Microsoft also decides how much CPU and memory an agent receives and how long it may remain idle. Developers configure the agent’s instructions, tools, and behavior, but they do not set these runtime limits. The harness runs the agent inside an environment managed by Microsoft.

These restrictions simplify operations because Microsoft handles hosting and execution. They can also matter for workloads with unusual performance or infrastructure needs. Teams that require more control can use Foundry’s hosted agents instead. Hosted agents let teams use their own frameworks and customize how agents operate, while Microsoft still handles hosting.

Microsoft does not let developers change the harness after creating a prompt agent. The selected harness remains fixed even when the agent receives a new version. The article does not give a reason for this restriction; it presents it as a product limitation of the managed Copilot harness.

That permanence matters because the harness determines the agent’s managed execution environment. It also affects available model choices, since the Copilot harness supports compatible Foundry models but not developers’ own models. Microsoft controls CPU, memory, and idle time as well.

The result can be lock-in. A team that later needs different runtime resources, a custom framework, or its own model cannot simply switch the existing agent’s harness. It may need to redesign or redeploy the workload using Foundry hosted agents, which allow teams to use their own frameworks and customize agent operation.

Foundry hosted agents are Microsoft’s alternative for teams that need more control than the managed Copilot harness provides. They still run on Microsoft’s hosting, but teams can build and operate agents with their own frameworks. This separates hosting from the exact way an agent works.

That flexibility addresses several managed-harness limits. Developers can customize how hosted agents operate instead of accepting the Copilot harness’s fixed execution model. The article also reports general availability for long-running resilience, which helps hosted agents recover from interruptions during tasks lasting hours or even days.

The trade-off is straightforward. The managed Copilot harness offers built-in orchestration, sandboxing, skills, MCP integrations, and subagents with Microsoft handling the runtime. Hosted agents give teams more operational control and framework choice. Microsoft still handles hosting, so teams do not have to manage every infrastructure task themselves.

In general, an autonomous AI agent is a software system that pursues a goal by choosing and coordinating actions while it runs. It can use a model, tools, files, code, and sometimes other agents. The article presents Microsoft’s harness as infrastructure for building and deploying these systems, but it does not provide a formal definition of autonomy.

A traditional application usually follows a predefined sequence written by its developers. An agent can instead interpret instructions, decide which available tool to use, track context, and adjust its next step based on results. In Microsoft’s example, a research agent collects evidence, analyzes data, and writes a report. It can also delegate tasks to subagents.

Autonomy does not mean unlimited independence. The harness still applies configured policies, requires authentication and approval for MCP integrations, and operates within Microsoft-controlled resource limits. Developers define instructions and tools, while the agent coordinates actions during the task.