The harness is the operational product

Microsoft is making the agent harness a first-class design choice in Foundry. A basic prompt agent can move onto the Microsoft Copilot harness to plan, loop over intermediate work, call tools and subagents and continue until it produces a finished result. The announcement focuses on the execution environment around a model, where many production reliability and security decisions now live.

A harness manages expanding context, memory, tools, skills and delegation. Microsoft describes its Copilot harness as model-agnostic and connected to the same approach used behind services such as GitHub and Microsoft 365. The practical distinction is between asking a model for one response and operating a controlled process that can gather evidence, revise work and coordinate specialised agents.

Bring-your-own loops with enterprise controls

Foundry also supports hosted agents that use another harness, including the Claude Agent SDK. Customers can run their own loop while retaining platform controls such as an Entra Agent ID, telemetry and guardrails. Microsoft says the hosted environment can use isolated virtual-machine sandboxes, private networking, a customer container registry, autoscaling and zero idle cost.

That combination matters for organisations with existing agent code. Rewriting a proven loop merely to inherit identity or network controls creates risk and delays. A hosted model lets teams preserve their orchestration logic while giving each agent a distinct identity, limiting outbound connections and tracing activity through enterprise tooling. Portability, however, still depends on the harness interfaces and runtime assumptions.

Tool search trims context overhead

Foundry toolboxes provide a governed, MCP-compatible catalogue that teams can curate once. Tool search retrieves only the capabilities relevant to the current task rather than loading every tool definition into context. This can reduce token consumption and confusion, particularly for agents operating across large estates of internal APIs where similarly named actions may have very different permissions.

Token efficiency is valuable, but the larger gain is policy consistency. A central toolbox can apply review, naming and ownership standards before a tool reaches multiple agents. Platform teams should still version schemas and record which tool definition an agent saw. A changed argument or permission can alter behaviour even when the model, prompt and harness remain unchanged.

Governance must follow every delegated action

Microsoft also highlights Agent Optimizer, which can tune an agent against an organisation’s own benchmark. That is a healthier measure than relying on generic demonstrations, provided the benchmark reflects real failure costs and includes adversarial cases. Teams need held-out evaluation tasks, reproducible traces and human review for high-impact workflows rather than continuously optimising against a small visible test set.

Every delegated action expands the security boundary. Entra identity, egress rules and sandboxes reduce risk only if permissions remain narrow and approval gates sit before irreversible operations. A subagent should not silently inherit broad credentials from its coordinator. Security teams should be able to reconstruct the plan, tools, data access, outputs and confirmations associated with each run.

The Copilot harness announcement gives Foundry customers a clearer progression from prompt experiments to managed execution. The right choice is not automatically Microsoft’s harness or a third-party alternative. Teams should compare completion reliability, isolation, observability, cost and portability, then adopt the smallest execution model that can safely finish the job.

Memory is another design boundary. Retaining context across sessions can improve continuity, but it can also carry stale assumptions or sensitive material into an unrelated task. Foundry teams should define which memory is ephemeral, user-specific or shared, then apply deletion and retention rules outside the model. The harness should retrieve only the minimum context required and record why each memory item was selected.

Operational cost should be evaluated at the run level. Zero idle compute can reduce infrastructure waste, while planning loops, subagents and repeated tool calls can increase token and execution charges. Useful dashboards will show task completion, elapsed time, model tokens, sandbox duration, tool failures and human interventions together. A cheaper model is not economical if the harness repeatedly recovers from its mistakes.

The announcement also reinforces a separation of concerns in agent engineering. Models provide reasoning, harnesses manage process and enterprise controls constrain authority. Treating those layers independently makes replacements and audits easier. An organisation can upgrade a model or try another SDK without silently discarding identity, network and evaluation policy, provided those controls are genuinely enforced by the hosting platform.

A staged rollout should begin with read-only tasks and reversible outputs. Once traces show that planning, delegation and tool selection are stable, teams can introduce approvals for bounded writes. Unattended execution belongs last, after incident response and kill controls are proven. The harness can make an agent persistent, but persistence amplifies both good judgement and unresolved defects.

Change management deserves the same care as initial deployment. A new model, prompt, tool or harness release can alter plans and permissions in combination. Canary runs and replayable evaluation traces should precede broad rollout, with quick rollback when completion or safety metrics regress.