Microsoft's Copilot Harness Gets the Architecture Right. It Gets the Exit Wrong.

What Microsoft Has Launched

On 28 October Microsoft put its Copilot harness into Foundry Agent Service as a public preview. Microsoft describes it as part of a unified harness strategy: one shared execution layer across its agent experiences, now opened up for enterprises to build on.

In plain terms, the harness is everything around the model that turns it into an agent that finishes a job. Microsoft runs the agent loop, decides the sequence of model calls and tool calls, manages the working context as the task evolves, and gives the agent a sandbox to work in. Out of the box that means file read and write, a shell, web access and subagents for delegated work. You add reusable skills (packaged instructions, scripts and resources), MCP and other tools with explicit authentication and approvals, and keep the whole agent definition in source control next to your application code.

The commercial terms are simple enough. Harness runtime is free until 1 December 2026, then billed at roughly $0.0994 per vCPU-hour and $0.0118 per GiB-hour of memory, with model inference charged separately throughout. UK South and West Europe are among the nine supported regions. It is a preview with no SLA, and Microsoft does not recommend it for production yet.

Why the Harness Matters More Than the Headlines Suggest

Most of the attention in AI goes to the models. In practice, the harness decides whether an agent completes a multi-step task or wanders off halfway through. How context is managed over a long job, how tools are called and checked, how work is broken down and handed to subagents: that is where agents succeed or fail in real workflows. It is a large part of why Claude Code pulled ahead in agentic coding, and why Copilot has spent the last year playing catch-up.

So in principle this is a real step forward for Copilot. And the enterprise controls are valuable in their own right. Agents defined declaratively and versioned in source control. Tool access that has to be explicitly authenticated and approved. Network egress controlled through policy. For organisations moving from experiments to agentic workflows that touch real systems, that is exactly the kind of governance you want baked in rather than bolted on.

The architecture is right. The problem is the exit.

Read the Limits Page Before You Commit

The detail that matters is not in the launch post. It is in Microsoft's quotas and limits documentation:

• No bring-your-own-model. You can only use models deployed in your Foundry project that support reasoning and tool calling and are available to prompt agents in your region. The model catalogue is Microsoft's to curate.
• No changing harness. You choose the harness when you create an agent, and you cannot switch it afterwards, not even by creating a new version. Moving means rebuilding.
• A sandbox you do not control. CPU, memory and lifecycle settings are service-managed and not configurable.
• Fewer dials. You cannot set temperature, maximum output tokens, tool choice, parallel tool calls, truncation or prompt caching options. Foundry Memory is not supported.

None of these is unreasonable for a managed preview. Together, they describe a system where the agents you build are welded to Microsoft's runtime and Microsoft's model shelf.

Why That Is a Strategic Warning Sign

The model market is moving month by month. Over the last year we have watched cheaper models match or beat their own flagships on agentic benchmarks, and the cost of a completed task fall faster than the price per token. The most cost-effective option for a high-volume workflow is increasingly a smaller model, an open-weight model you host yourself, or one fine-tuned on your own data. That is exactly what bring-your-own-model is for, and exactly what this harness rules out.

An agent platform is not a one-year decision. The workflows you build now will run for years, accumulate skills and integrations, and become part of how the business operates. If you cannot move them to a more capable model, or a far cheaper one, when the market shifts, you have handed your unit economics and your capability ceiling to your platform vendor. If the harness itself falls behind, the only way out is to rebuild.

That is the critical flaw. Not the quality of the harness today, which may well be good, but the inability to swap out the parts that will change fastest.

How to Build for the Future Instead

Take the architecture and keep the exit. Declarative agents, reusable skills, MCP tools, sandboxed execution and explicit approvals are the right pattern, wherever you run them. The trick is to own the pieces that carry the value:

• Keep skills and tools portable. Write skills as plain instructions and scripts in your own repository, and expose your systems as MCP servers you control. Those move between harnesses. A platform-specific agent definition does not.
• Measure cost per completed task, not cost per token. Run the same workflow on at least two models, and ideally two harnesses, and compare what it costs to get the job done. Re-run it every time a major model ships.
• Separate the runtime from the model. If a workflow needs model choice or a custom loop, Microsoft's own hosted agents option lets you bring your own framework while Foundry handles hosting. Use the managed harness where convenience matters more than control, not as the default for everything.
• Pilot, do not standardise. Use the free preview to learn, on non-production work. Do not make it the foundation of your agentic estate until model choice and harness portability are on the roadmap.

Four Questions to Ask Before You Commit to Any Agent Platform

1. Can we change the model behind an agent without rebuilding it, including to a model the vendor does not sell?
2. Can we move the same agent to a different runtime, and what would we have to rewrite?
3. What is our cost per completed task today, and what levers do we have to bring it down?
4. Who owns the skills, tools and integrations we are building, and where do they live?

If the answers are no, everything, not many, and the vendor, you are not building an agentic capability. You are renting one.

We work with frontier models every day across paid media, search and measurement, from automating performance optimisation through ad platform CLIs to agentic advertising. If you are weighing up where to build your agentic workflows, the QueryClick team is happy to share what we have learned.