The harness is the system around a model
Microsoft announced the Copilot harness in Foundry Agent Service as a public preview on October 28. In this context, a model interprets instructions and generates responses; the harness coordinates the surrounding work: context, tools, execution, state and the loop that decides what happens next. Microsoft says the same broad harness strategy underpins several Copilot experiences, and that developers can now use a managed version through Foundry.
That distinction matters because changing a model does not automatically supply reliable permissions, recovery or workflow logic. An agent that researches a request and prepares a brief needs approved evidence sources, a controlled runtime and a way to review its output. The harness is the operational layer that joins those pieces; it is not itself a new foundation model or a guarantee that an agent completes every task correctly.
What the Foundry preview includes
Microsoft lists reusable skills, connected Foundry and Model Context Protocol tools, execution over files and code, bounded built-in subagents, and source-controlled agent definitions. The managed service runs the agent loop and sandbox while the developer supplies knowledge, procedures and tools. A supported model can be selected without rebuilding the orchestration around every model change.
The company says tool authentication and approvals are explicitly configured, and that policy boundaries govern the task. Microsoft separately announced general availability for long-running resilience in hosted agents; that status should not be confused with the Copilot harness itself, which remains a preview. Microsoft says harness runtime billing begins December 1, 2026; before then the runtime is free, while model inference and separately billed tools remain chargeable. Access, regional support, billing and supported models should be confirmed in the current Foundry documentation and tenant.
Why multi-model operation may help — and complicate things
A team may want to route a structured extraction task to a faster, lower-cost model, but use a stronger reasoning model for a difficult exception. Keeping orchestration separate can make that choice less disruptive. It can also reduce some model-specific coupling if the agent definition, tools and evaluation set are portable. Microsoft describes a choice of supported Foundry models, not an unrestricted promise that every model can be swapped into every workflow.
Routing introduces new questions: what evidence determines the model choice, how are costs measured, and what happens when two models return incompatible results? Teams should test each supported configuration against the same task set, monitor tool failures and preserve human approval for consequential actions. Model choice is only one factor; the harness version, tool definitions, context and safety policy also shape the result.
A governance review before a pilot
Start with a narrow, low-impact workflow and give the agent only the data and tools it needs. Inspect authentication scopes, approval settings, file handling, logs, task duration, subagent boundaries and the process for stopping or resuming a run. For MCP-connected services, review each server and tool as an integration with its own permissions and failure modes rather than assuming the protocol itself supplies governance.
The preview may lower the amount of orchestration infrastructure a team must build, but it creates a platform dependency that should be evaluated alongside the convenience. Document which agent definitions and skills can be exported, how model choices affect behavior, what the managed runtime costs after any preview terms, and how to move the workflow if requirements change. Treat Microsoft Copilot products, Foundry Agent Service and the harness as related but distinct surfaces.
A useful pilot should define the handoff contract between the model and each business system: what evidence is required before a tool runs, which actions need approval, what is recorded in audit logs, and who owns a failed or partial run. Record the selected model, harness and skill versions with test results. This makes cost and performance routing measurable and helps separate a model limitation from a tool, permission or orchestration failure. Portability should be checked at the configuration level rather than inferred from a multi-model label.
Sources & further reading
Have a factual correction or a source to suggest? Contact the editorial desk.
