NEW DELHI, October 29, 2026, 7:50 PM IST — Microsoft has opened the agent orchestration layer behind several Copilot products to developers through Microsoft Foundry, giving teams a managed way to run long-lived, tool-using AI agents without building the surrounding execution harness themselves.
The Microsoft Copilot harness entered public preview in Foundry Agent Service on Wednesday. Microsoft says the same shared foundation now powers Copilot Code, Copilot Studio, the GitHub Copilot app, Copilot CLI and Visual Studio Code. The release matters because it shifts a difficult part of agent engineering — context management, tool coordination, sandboxed execution and recovery across long tasks — from application code into a managed cloud service.
A shared agent runtime reaches Microsoft Foundry
A model can decide what to do next, but production agents also need an execution loop, files, tools, credentials, limits and a way to recover when steps fail. Microsoft describes the harness as that surrounding orchestration layer. In Foundry, developers define an agent and choose a supported model while Microsoft operates the agent loop and sandbox.
The public preview combines four main components: reusable skills that bundle instructions and supporting resources; connected Foundry and Model Context Protocol tools with configured authentication and approvals; file and code execution with bounded delegation to built-in subagents; and agent definitions that can be kept in source control beside application code.
Microsoft also made long-running resilience for hosted agents generally available. That capability is separate from the Copilot harness preview, but the two announcements point in the same direction: agent tasks are being treated more like durable workloads that need resumability and operational controls, rather than single chat requests.
“The model supplies the intelligence” while the harness provides the instructions, context, execution environment and controls, Microsoft executives Tina Schuchman and Vladimir Fedorov wrote in the company announcement.
What is confirmed in the preview
Developers can create a Copilot-harness agent in the Microsoft Foundry portal or use the preview Azure Developer CLI surface so the definition remains with the rest of an application. Microsoft says users can change among supported Foundry models without rewriting the orchestration around the agent.
The service supports skills, managed files, connected tools, code execution and subagents. Tool connections can carry explicit authentication and approval settings, while the harness coordinates model and tool steps within configured policy boundaries. Those controls are important, but they do not remove the need for application-level authorization, audit logging and tests for destructive actions.
The preview has material constraints. Existing agents are not changed automatically, and Microsoft says a team cannot switch an agent’s harness after creation during the preview. Foundry also manages the execution environment’s CPU, memory and idle settings, limiting infrastructure-level tuning. Supported regions, models, tools and preview quotas vary and should be checked before production planning.
Harness runtime usage is free until December 1, although model inference and separately billed tools still incur their usual charges. Microsoft says consumption pricing will then begin at $0.0994 per vCPU-hour for sandbox compute and $0.0118 per GiB-hour for memory, subject to region and commercial agreement.
The SDK is moving beyond GitHub
GitHub separately said the GitHub Copilot SDK is becoming the Microsoft Copilot SDK. The repository and branding will move in phases, so package names, namespaces and documentation may continue using the GitHub name for a period. GitHub says existing users do not need to take immediate action.
The change is more than a rename. Microsoft is positioning the SDK as the programmable interface to a shared agent foundation across its developer and business products. VS Code’s October 28 update also made the new Copilot harness the default for new sessions in the editor and Agents window, while allowing developers to run Claude and Codex harnesses through the open Agent Host Protocol.
That distinction matters for platform teams evaluating portability. A shared Microsoft harness may reduce duplicated integration work across Copilot surfaces, but individual provider harnesses still have different runtimes, permission models and capabilities. Model portability does not automatically mean behavioral parity.
Microsoft reports better recovery, but evidence remains internal
Microsoft says its internal evaluations found that the Copilot harness improved task pass rates by 10.8 percentage points with an OpenAI model and 22.1 points with an Anthropic model compared with its Standard harness. It also reported that agents continued working after a failed tool call in 84% to 91% of evaluated cases, versus less than 7% for the Standard harness.
The company further said more efficient caching reduced net input-processing costs by 15% to 21% even when the harness made nearly twice as many model calls. Those figures are useful signals, but they come from Microsoft’s internal analysis and production telemetry. The company cautions that results vary by model, build, configuration and scenario, and continued tool use does not necessarily mean the overall task succeeded.
Teams should therefore reproduce the comparison with their own workloads. A harness that retries more aggressively can improve completion rates, but it can also amplify cost, duplicate side effects or extend a bad plan unless tools are idempotent and permission checks are enforced at every boundary.
What developers and platform teams should do now
The immediate opportunity is to test whether a managed harness removes undifferentiated orchestration work. A useful evaluation should include multi-step tasks with injected tool failures, expired credentials, partial outputs, cancellation, retry storms and human-approval gates. Teams should measure successful completion, not just the number of steps attempted.
Production controls should remain outside the model’s discretion. Use short-lived workload identities, narrowly scoped tool permissions, tamper-resistant audit trails and explicit approval for high-impact actions. Put budgets around model calls, sandbox runtime and external services, and trace the full path from user request to tool side effect. GravityDevOps’ guides to LLMOps, prompt engineering for developers and CI/CD tooling provide useful background for building those evaluation and release controls.
The broader shift is clear: agent quality increasingly depends on the runtime around the model, not only the model selected. Microsoft’s release gives developers another managed option, but the public-preview label, vendor-controlled sandbox settings and internally reported performance claims make disciplined testing essential before critical workflows move onto it.
Sources
Microsoft’s Copilot harness announcement; the Foundry Agent Service technical release; GitHub’s SDK transition notice; Microsoft’s Copilot Studio evaluation disclosure; and the VS Code GitHub Universe update.
