Microsoft Copilot harness across Foundry and Copilot Studio

~ Vesa Nopanen

The model gets the headlines. The harness does the work.

For the last couple of years, most AI conversations have been about which model is the smartest this month. A model can reason, but it can’t finish a long task by itself. To get real work done, an agent also needs instructions, context, tools, a place to run code and files, controls, and a loop that ties it all together. That surrounding layer is the harness, and this week Microsoft made a clear move: one harness across its Copilot experiences, now also available to developers in Microsoft Foundry.

Three announcements landed together, and they make more sense read as one story. Let’s take a closer look.

  • The Microsoft Copilot harness: the big-picture announcement
  • Microsoft Copilot harness in Foundry Agent Service: public preview
  • Copilot Studio: the GitHub Copilot harness gets a new name

What is a harness – and why does it matter?

If the model supplies the intelligence, the harness is everything around it. It’s the orchestration layer that gives the agent its instructions, context, execution environment and controls. A good harness also supports open standards such as MCP, agent skills and agent plugins.

Why does this matter? Because models change all the time. Today’s frontier model can be yesterday’s news in a few months. If your agent’s orchestration is tied to one model, every model change turns into rework. If the harness stays the same and the model is something you pick, you can change models without rebuilding everything around them.

That’s the main point of this announcement: the harness becomes the stable layer, and the model becomes a choice.

Born in GitHub – now Microsoft-wide

The harness wasn’t built from scratch for this launch. The GitHub engineering team built it, and Microsoft has now adopted it across the company. It already powers Copilot Code, Copilot Studio, the GitHub Copilot app, the CLI, VS Code and more. It’s designed to be fast, token-efficient and predictable.

Copilot Code on that list is a clear signal. The Copilot family now spans Chat, Cowork, Code and Autopilot, and Microsoft is standardizing its Copilot experiences on this same foundation.

A few points from the announcement:

  • Multi-model by design: 20+ frontier models plus bring-your-own-key, so you can use the right model for each job.
  • Routing: Microsoft can route work to the right model, or models, based on the task.
  • Rust runtime: the runtime was recently ported to Rust, which reduced session overhead and time-to-first-token.
  • Scale: it already runs across Microsoft surfaces with millions of users.

The most interesting part is the compounding effect. When Microsoft improves the harness, every surface that uses it benefits, including the agents you build on it in Foundry. You get the improvements without having to maintain the harness yourself.

The platforms also stay open. You can still bring your own harness and framework if you need to. This isn’t a lock-in move. It’s a strong default.

Microsoft Copilot harness in Foundry Agent Service

This is the main news for builders. The Microsoft Copilot harness is now in public preview in Foundry Agent Service. It gives developers a fully managed way to build agents that reason, use tools and handle complex, long-running tasks.

The split of responsibilities is simple:

  • Microsoft runs the agent loop and the sandbox.
  • You bring the knowledge, procedures, tools and model choice.

The public preview has four building blocks:

  • Reusable skills: package instructions, scripts and resources into procedures an agent can apply across tasks.
  • Connected tools: supported Foundry and MCP tools, with authentication and approvals configured explicitly.
  • Execution and delegation: the agent works with files and code and hands bounded tasks to built-in subagents while the main agent coordinates the result.
  • Source-controlled agent definitions: build and test in Foundry, or keep agent definitions next to your application code.

Many teams building agents have written the same plumbing again and again: coordinating model and tool calls, keeping working context, handling files and deciding what to do next. That work is necessary, but it rarely sets your solution apart. Now it comes ready.

Skills define the method

The Foundry announcement shows a pattern that’s useful well beyond developer work. Instructions define the outcome, skills define the method, and tools provide the evidence. Its example is a research-brief agent: a SKILL.md describes how to produce an evidence-backed brief, the agent definition selects the Copilot harness and a model, and the tools are web search and Code Interpreter.

The same pattern works for market research, operational analysis or internal planning. If you have already worked with skills in Copilot experiences, this will feel very familiar, and that’s the point of a shared harness.

You can build in several ways: the Foundry portal, the Azure Developer CLI (azd), Foundry Toolkit for VS Code, or through the Microsoft Foundry plugin and skill in the GitHub Copilot app. The harness SDK is also available to download if you want to run it yourself instead of in the Foundry-managed cloud.

Long-running resilience for hosted agents – now GA

Alongside the preview, long-running resilience for hosted agents is now generally available. Hosted agents let you bring your own framework, agent loop, middleware and runtime while Foundry manages the hosting.

With resilience, Foundry detects interruptions and restarts the work with its original input. Your code still decides what to save and how to resume. One practical caveat is worth noting: if your agent updates other systems, make sure a restart doesn’t create duplicates, like the same report twice. Conversation history alone isn’t enough to restore work in progress.

Which approach to choose?

Foundry now offers three levels:

  • Prompt agents without the Copilot harness: when instructions and supported tools are enough.
  • Prompt agents with the Copilot harness: when you want skills, managed execution, files, subagents and more complex tool coordination, without owning the harness.
  • Hosted agents: when you need your own framework, agent loop or runtime behavior, with Foundry-managed hosting.

Start with the level your requirements actually need. Don’t take on infrastructure that won’t set your solution apart.

Preview notes and pricing

A few things to know before you start:

  • You select the Copilot harness when you create the agent. Existing agents are unchanged, and switching the harness after creation isn’t supported yet.
  • Foundry manages the execution environment’s CPU, memory and idle settings.
  • Harness runtime usage is free until December 1, 2026. Model inference and separately billed tools still have their normal charges.
  • From December 1, 2026, sandbox compute and memory are billed by consumption: USD 0.0994pervCPU−hour∗∗and∗∗0.0118 per GiB-hour. Prices may vary by region and agreement.

That makes November a good month to experiment.

Copilot Studio – a new name for a familiar harness

Copilot Studio makers are already using this harness. Until now it was called the GitHub Copilot harness. To reflect its wider role across Microsoft, it’s now the Microsoft Copilot harness.

For makers this is mostly good news without extra work. Existing agents keep working as before, with no changes to capabilities or billing. The new name will show up in the product over the coming weeks.

The Copilot Studio team also shared internal numbers, from evaluations and production telemetry, comparing the Copilot harness with the Standard harness:

  • Better results across models: changing the model had little impact on pass rates, but changing the harness made a big difference, with +10.8 percentage points using an OpenAI model and +22.1 using an Anthropic model.
  • Resilience: after a failed tool call, agents on the Copilot harness kept trying to solve the problem in 84–91% of evaluated cases, compared with fewer than 7% on the Standard harness.
  • Efficiency: despite nearly twice as many model calls, better caching cut the net cost of processing input by 15–21%.

These are Microsoft’s internal numbers, so results will vary by scenario, model and configuration. The direction is still clear. The harness can matter more than the model. That should change a lot of “which model should we use?” conversations.

The Copilot Studio post also mentions recent additions built on this harness: agent accounts, business process memory and triggers for persistent, proactive agents.

The harnesses are uniting

Put the three announcements together and the picture is clear:

  • GitHub built the harness.
  • Copilot experiences, including Copilot Code, are standardizing on it.
  • Copilot Studio makers have been using it, now under its new name.
  • Foundry opens it to pro developers as a managed service.

For organizations, a shared harness should make it easier for skills, tools, MCP connections and agent patterns to carry over between Copilot itself, low-code and pro-code. A maker in Copilot Studio and a developer in Foundry are increasingly building on the same engine that runs Microsoft’s own Copilot experiences, and improvements to that engine reach all of them.

The model is still a choice, and it should stay that way. What’s changing is that the layer around it is becoming the real platform for agentic work.

This is a direction worth following closely. The next step is testing it in Foundry while the runtime is still free!

Sources

Unknown's avatar

Published by Vesa Nopanen

Vesa "Vesku" Nopanen, Principal Consultant and Microsoft MVP (Microsoft 365 and Azure AI Foundry) working on Future Work at Sulava MEA. I work, blog and speak about Future Work : AI, Microsoft 365, Copilot, Loop, Azure, and other services & platforms in the cloud connecting digital and physical and people together. I have 30 years of experience in IT business on multiple industries, domains, and roles.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.