Microsoft is offering Foundry customers the harness behind its Copilot products as an optional runtime for prompt agents. During the preview, Microsoft manages the approval policy for the harness’s built-in tools, the shell is on by default for new agents, and Microsoft has published no export to framework code like the one AWS ships.
What is Covered in this Article
- What Microsoft announced on October 28, 2026: the Microsoft Copilot harness in Foundry Agent Service in public preview, and general availability of long-running resilience for hosted agents.
- How the harness works, what the preview limits are, and what it costs from December 1, 2026.
- What a Foundry team gives up on approvals, shell access, and export when it puts an agent on the harness.
- How Microsoft’s harness compares with AWS’s AgentCore harness and Anthropic’s Claude Managed Agents.
- What platform engineering leaders, CIOs, Microsoft, and its competitors should do before billing starts.
The News: On October 28, 2026, Microsoft introduced the Microsoft Copilot harness in Foundry Agent Service in public preview and announced general availability of long-running resilience for hosted agents. A companion post from Tina Schuchman, corporate vice president of Microsoft Foundry, and Vladimir Fedorov, CTO of GitHub, says that GitHub engineers built the harness that already powers Copilot Code, Copilot Studio, the GitHub Copilot app, the Copilot command-line interface (CLI), VS Code, and more. Across those products, the post says the harness supports more than 20 frontier models and bring-your-own keys; in Foundry, it runs supported Foundry models that handle reasoning and tool calling.
In Foundry, the harness is an optional runtime for prompt agents. Microsoft runs the agent loop and the sandbox so agents can “reason, use tools, and complete complex, long-running tasks,” and the customer supplies the instructions, skills, tools, and model. The preview bundles four components: reusable skills; connected Foundry and Model Context Protocol (MCP) tools with configured authentication and approvals; file and code execution with built-in subagents; and agent definitions stored in source control. Teams that bring their own framework and loop use hosted agents, where the new resilience feature restarts interrupted work with its original input.
During the preview, the Microsoft Copilot harness is selected when an agent is created and can’t be changed afterward. Like other Azure previews, it has no service-level agreement and isn’t recommended for production workloads. Harness runtime is free until December 1, 2026, while model inference and separately billed tools and connected services remain subject to their applicable charges. From then, sandbox compute and memory are billed at $0.0994 per vCPU-hour and $0.0118 per GiB-hour, and prices may vary by region and agreement, according to Microsoft’s Foundry announcement of the Copilot harness.
Microsoft Copilot Harness Preview Keeps Tool Approval Policy With Microsoft
Analyst Take: The Microsoft Copilot harness is optional in Foundry. For a platform team, two limits in the preview matter more than the fixed harness choice: Microsoft manages the approval policy for the harness’s built-in tools, and it has published no export to framework code like the one AWS ships for its AgentCore harness. What the shared harness means for the CIO choosing a platform is a question we address from the buyer’s vantage point below.
Schuchman and Fedorov are right that building your own harness to keep up with new models “can be painful and slow,” and they promise “the right model for the job without switching the harness or the rest of your tech stack.” The same post says customers “can continue to bring in any harness and framework you want.” During the preview, that freedom applies when a team creates an agent; once the agent is built on the Copilot harness, the choice is fixed.
Model access is a weak reason to choose a platform when most builders already use multiple providers. In Futurum Intelligence’s Enterprise Technology Research (ETR) AI Product Series (March 2026, n=514), 56% of enterprise builders ran more than one foundation model provider in production, and 15% relied on one, figures The Futurum Group cited in The AI Stack (July 2026).
Microsoft Manages the Approval Policy for the Harness’s Built-In Tools
Microsoft’s implementation guide states that “the service manages the approval policy for harness tools,” and that a team’s approval settings apply to the MCP tools it configures. New agents get all five built-in tools unless a team turns them off, and the guide calls shell “the broadest harness tool,” warning that disabling file or web access while shell stays on isn’t a strict security boundary. Network egress controls, also in preview, let teams limit the harness’s outbound requests.
The Microsoft Copilot Harness Enters a Field AWS Already Occupies
Microsoft isn’t first. AWS made its AgentCore harness generally available on June 17, 2026, and says customers can choose any model, switch providers mid-session, and export a harness agent to Strands-based code with one command. Anthropic’s Claude Managed Agents, in beta, list only Claude models as supported.
Microsoft’s documentation, reviewed on October 29, 2026, describes no one-step export from a harness agent to framework code, unlike AWS’s. Within Foundry, Microsoft points teams that need to own the agent loop to hosted agents, and its documentation describes no tool that converts a harness agent into one. Microsoft’s June 2026 Build recap says hosted agents run agents built with the GitHub Copilot software development kit (SDK) without rewrites.
Hosted agents also leave recovery work to the team, and Microsoft’s resilience guide states that the agent “is still responsible for preserving meaningful progress and preventing duplicate side effects.” A team that moves an agent off the harness takes on the agent loop and its recovery, so leaving the harness inside Foundry costs more than the export gap alone suggests.
Microsoft’s advantage is distribution. GitHub Copilot reaches 59% of organizations in Futurum Intelligence’s ETR AI Product Series (January 2026), as cited in The AI Stack, though only about half of its users say it returns more than it costs. Those figures cover GitHub Copilot use in general, and some of those developers already use tools that Microsoft says run on the harness, such as VS Code and the CLI. That reach puts the harness in front of developers, but with users split on value, Microsoft still has to show results before that reach turns into paid harness use.
So far, the published results are based on benchmarks. A June 25, 2026 GitHub post reports that, with the model and task held fixed, the harness “achieves task completion rates on par with other model-vendor harnesses, while showing lower token consumption across most configurations.” Neither the October 28 post nor the two customers quoted, Confluence Technologies and Fashable, report measured results for Foundry agents; they describe a first build in under a week and plans for the harness, not production results.
Skill Files and MCP Servers Can Move Even When the Harness Can’t
Platform engineering leaders should start each Copilot harness agent with the shell turned off and no separately declared shell tool, unless the workflow requires it. During the preview, run the same workflow on the harness and as a hosted agent; compare the accepted results, human interventions, and total cost at the December 1 rates; and ask Microsoft whether approval control and an export path will be available before billing starts.
Teams building on the Microsoft Copilot harness should keep the layers above it portable. Microsoft’s example skill uses the SKILL.md layout of the open Agent Skills format, and its connected tools use MCP.
Skill files and MCP servers written to those standards can be reused by another harness that supports both. The Foundry connections, identities, and their approval settings may need to be reconfigured on the destination platform.
AWS should make its export-to-code the center of its pitch against Microsoft’s distribution. Anthropic has to decide whether a Claude-only harness can compete with multi-model ones from Microsoft and AWS.
Microsoft should give customers approval control over the harness’s built-in tools and publish a switching or export path for agents on the Microsoft Copilot harness, along with results from Foundry customers, before billing starts on December 1, 2026. Until it does, teams on the harness will pay for a runtime whose built-in tool approvals they can’t set.
The Harness Decision Moves to Whoever Builds the First Agent
For CIOs, the Microsoft Copilot harness is a platform commitment made at the moment a builder creates an agent. Because that choice is fixed once the agent exists, the decision about which runtime governs an agent moves from architecture review to the person building it, often outside IT’s line of sight. A platform team that hasn’t set a harness policy before builders start in Foundry has already handed that decision away.
What a buyer adopts with the harness is the runtime Microsoft built for its own products. Microsoft putting Copilot Code, Copilot Studio, VS Code, and the CLI on one shared harness shows it rebuilding its own product engineering around agents. The defaults covered above reflect that origin. They suit a vendor running its own code on its own platform. An enterprise that answers to auditors and regulators carries a different risk posture.
The approval split matters to CIOs because authority over what an agent can reach is where their leverage lies as the business spreads. As agents move from suggesting work to executing it, review and approval become the bottleneck. Accountability for an agent’s actions still lands on IT, whoever built it. A gap in approval control will surface first in an audit request or an incident review, long after the purchase decision.
The comparison recommended above will show what the harness costs per accepted result. It won’t show who pays. Once billing starts, charges are applied to the Foundry subscription owner, while agents start in business units. CIOs should assign cost ownership for each agent before the first invoice arrives.
The questions platform teams put to Microsoft belong in procurement terms. CIOs should make approval control over the built-in tools and export path conditions for production use in the agreement. The portable skill and MCP layer also needs an owner: identity, connector authorization, and the catalog of approved servers and skills should sit with the enterprise. Every harness an enterprise adopts from Microsoft, AWS, or Anthropic adds its own approval model and identity bindings to reconcile. Enterprises that contain that sprawl early won’t have to pay it down later under budget and audit pressure.
See the complete Foundry Agent Service announcement on the Microsoft website.
What to Watch
- Whether Microsoft adds harness switching, customer control over built-in tool approvals, or a code export path like the one AWS already ships before the preview ends.
- Whether Anthropic opens Claude Managed Agents to other model providers, or keeps a Claude-only harness while Microsoft and AWS sell multi-model ones.
- Whether Foundry customers beyond the two Microsoft-quoted report task-completion results for harness agents will be available once billing starts on December 1, 2026.
Sources
1. Introducing the Microsoft Copilot harness in Foundry Agent Service, Microsoft
2. The AI Stack: How Vendors Are Composing AI Strategy
3. Microsoft Build 2026 – The Platform, Integration Plane, and Developer Surface
4. OpenAI Moves Up the Stack and Competes With the Platforms It Powers
5. Docker Reruns the Container Playbook, This Time for Cloud Sandbox Kit
Declaration of generative AI and AI-assisted technologies in the writing process: This content has been generated with the support of artificial intelligence technologies. Due to the fast pace of content creation and the continuous evolution of data and information, The Futurum Group and its analysts strive to ensure the accuracy and factual integrity of the information presented. However, the opinions and interpretations expressed in this content reflect those of the individual author/analyst. The Futurum Group makes no guarantees regarding the completeness, accuracy, or reliability of any information contained herein. Readers are encouraged to verify facts independently and consult relevant sources for further clarification.
Disclosure: Futurum is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this article. The author does not hold any equity positions with any company mentioned in this article.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of Futurum as a whole.
Read the full Futurum Group Disclosure.
Other Insights from Futurum:
Microsoft Q1 FY 2027: Copilot Consumption Expands the AI Business
Want Better MFA Adoption? Look at How Game Studios Do It.
Microsoft Contact Center Intelligence Takes Aim at CCaaS AI
Author Information
Vikram Rathnam is Research Director, Software Lifecycle Engineering at The Futurum Group. His research examines how software is built, tested, secured, and operated as AI agents move from assisting developers to doing the work. His coverage includes observability, platform engineering, and the control planes that govern agents. Before joining Futurum, he spent 24 years on the vendor side: ten in engineering at Silicon Labs and fourteen in product and partner strategy, with roles at Cisco, Secureworks, Dell, and CMIT Solutions. Across those roles, he managed B2B cybersecurity, IoT, and AI products, with partner and channel ecosystems as the common thread. At CMIT Solutions, he led product strategy across a franchise network of 180 locations. He reads a vendor’s roadmap as someone who has had to ship one and take it to market.
Mitch Ashley is VP and Practice Lead for the CIO & Technology Buyers and Software Lifecycle Engineering practices at The Futurum Group. A multi-time CIO and CTO with 30+ years leading technical organizations, Mitch built and operated production systems spanning cybersecurity for the U.S. Department of Defense, PKI services for the broadband and 5G industries, SaaS platforms, large-scale telecom and banking systems, and a national broadband network. His work with AI began early, developing expert systems that diagnosed and repaired complex mainframe environments. That operator foundation grounds his analysis in operational consequence, covering the technology buyer's world of software engineering, cybersecurity, DevOps, cloud, and AI.
