Microsoft Copilot Harness Opens Through Foundry, Shifting the Build-or-Buy Decision

Microsoft opened its Microsoft Copilot harness through Foundry on October 28, extending an internal execution foundation to developers while retaining control of its operation. A harness is the software surrounding an AI model that organizes instructions, context, tools, and execution. The announcement changes what enterprises can buy instead of building, without removing their responsibility for the resulting work.

The central choice is whether to maintain that execution machinery internally or adopt Microsoft's managed approach. An agent, software that uses models and tools to pursue a task, needs more than access to a capable model. Someone must decide how it continues, handles failures, and stays within business boundaries.

Anthropic already offers a competing managed approach, giving buyers a useful reference beyond Microsoft's product family. Microsoft's distinctive pitch emphasizes access to different model families through shared infrastructure. For development teams, that raises a practical question: which responsibilities become easier to delegate, and which still require application-specific judgment?

Microsoft Copilot Harness Moves Into Foundry Public Preview

Microsoft is turning a shared product foundation into a managed building block for customer applications.

According to Microsoft's multi-model harness announcement, GitHub's engineering team developed the harness before Microsoft adopted it across Copilot experiences. The company identifies Copilot Code, Copilot Studio, the GitHub Copilot app, the command-line interface, and VS Code among its users.

Foundry Agent Service, Microsoft's platform for building and operating agents, now offers the harness in public preview. That status matters because the announcement combines an established internal technology with a newly available managed service. Experience inside Microsoft's products does not automatically establish readiness for every external customer's workload.

Microsoft describes a division of responsibility in which it operates the execution machinery while customers provide their application-specific instructions and connections. That arrangement makes the launch relevant beyond coding assistants. A company developing a research assistant or operational agent can consider buying infrastructure previously treated as internal engineering work.

The announcement also describes a downloadable software development kit, a package developers use to integrate the technology into applications. That route should not be confused with the managed Foundry experience. Choosing a distribution method and choosing who operates a service are related decisions, but they answer different questions.

For an enterprise buyer, the immediate change is an additional implementation option. A team evaluating an agent no longer needs to assume that supporting different models requires maintaining its own surrounding execution system. Microsoft is offering to maintain that shared foundation on the customer's behalf.

That offer deserves a precise reading. Buying a managed harness does not establish that a particular workflow produces correct answers or appropriate actions. It changes who supplies part of the machinery. The buyer still needs evidence that the complete application satisfies its own requirements.

Consider a hypothetical research application that compares supplier announcements and prepares an internal briefing. Its useful outcome includes accurate sourcing, clear dates, and an explicit treatment of conflicting information. A functioning execution system supports that work, but it cannot define those editorial requirements for the organization.

The launch therefore shifts the starting point for architectural discussions. Instead of asking only which model should answer a request, teams can ask which parts of agent execution deserve custom engineering. That is a more consequential question than whether another model appears in a selection menu.

The Pressure Falls on Teams Maintaining Their Own Execution Machinery

Microsoft's offer puts internal infrastructure projects under scrutiny, especially when they reproduce capabilities without creating a business advantage.

The strongest pressure falls on application teams already maintaining the surrounding machinery for agents. Their managers now have an external alternative to examine. Continuing a custom implementation becomes a decision that needs justification, rather than an automatic prerequisite for shipping an agent.

That justification can still be compelling. A business might require unusual execution behavior, specialized integrations, or direct control over how work proceeds. The relevant distinction is whether those requirements materially affect the application. Custom ownership makes more sense when the organization can identify what that control accomplishes.

Buying infrastructure introduces a different obligation: understanding the provider's boundaries. A development team cannot evaluate a managed service solely through the capabilities shown in a demonstration. It must identify where the platform ends and where its own software, procedures, and oversight begin.

Microsoft's managed agent execution announcement outlines skills, connected tools, file and code execution, and bounded delegation. Skills are reusable procedures packaged with instructions and supporting resources. Tools give agents access to external information or actions. These capabilities describe a broader application foundation than text generation alone.

The same announcement offers an early customer perspective. Confluence Technologies' chief technology officer, Chris Evans, says the company had a solution running in less than a week. That is a useful implementation anecdote, although it does not establish a typical deployment schedule or long-term operating result.

For buyers, the important distinction is between reaching an initial working state and maintaining a dependable service. An internal prototype can tolerate assumptions that an operational application cannot. A managed foundation can shorten some engineering work while leaving integration reviews, acceptance criteria, and ownership decisions unresolved.

A useful financial comparison would therefore examine the complete workflow rather than a single model response. Relevant considerations include engineering maintenance, investigation of failures, human review, and changes to connected systems. No universal calculation follows from the launch because those responsibilities differ across organizations.

The pressure also reaches infrastructure vendors whose products surround models. Microsoft's distribution gives customers another reason to question which separate components they need. That does not establish that independent products become unnecessary. It raises the standard for explaining the additional control, visibility, or specialization they provide.

For knowledge workers, the stakes appear in a different form. They experience whether an agent completes a usable deliverable, preserves the right evidence, and escalates uncertainty appropriately. An architectural change matters to them when it reduces incomplete work or makes mistakes easier to identify and correct.

This is why the build-or-buy discussion belongs with product owners as well as engineers. The organization must define a satisfactory result before deciding which infrastructure arrangement delivers it. Otherwise, a technically successful deployment can leave the actual business problem largely untouched.

Model Choice and Runtime Control Are Separate Decisions

Access to different models does not give customers unlimited control over how the managed service executes their work.

Microsoft's harness availability FAQ draws boundaries around the preview. Bring-your-own-model support is unavailable. Customers select the harness when creating a new prompt agent and cannot subsequently switch it. Availability can also differ by region, client, tools, networking, and quotas.

Those restrictions clarify the meaning of multi-model support. A customer can evaluate supported choices within the service's boundaries. That is different from assuming that any model, connection, or deployment arrangement will work simply because the broader strategy emphasizes choice.

The distinction matters during procurement. A model's presence elsewhere in a vendor's portfolio does not answer whether it is supported in a particular managed experience. Buyers need to assess the combination they intend to use, including the relevant deployment location and connected systems.

There is also a distinction between changing a model and preserving an application's behavior. Even if an interface stays consistent, a different model can produce different decisions or outputs. Application owners should treat a model change as something to evaluate against business requirements, rather than an administrative substitution.

Consider a hypothetical procurement assistant reviewing a supplier proposal. One task involves extracting delivery dates. Another involves interpreting an ambiguous cancellation clause. The organization might prefer different model characteristics for those activities, but it still needs a consistent definition of acceptable evidence and escalation.

A shared execution foundation can make that comparison easier to organize. It does not establish that the same instructions work equally well across all supported models. The useful outcome is a controlled opportunity to compare results, with clear records of what changed and why.

Anthropic's managed agent architecture provides a relevant competitive comparison. Its April 2026 engineering account describes separating the model and harness from execution environments and durable session records. The stated aim is to let implementations evolve behind stable interfaces.

That comparison shows why the industry competition extends beyond model selection. Providers are also competing over which execution responsibilities they can absorb while preserving an interface customers can rely on. Microsoft's emphasis on multiple model families addresses one dimension of that broader purchasing decision.

Neither architectural description establishes a universal winner. An enterprise choosing between managed approaches needs to compare its actual workflow, required integrations, and operational constraints. A service that fits one application well can impose unsuitable assumptions on another.

The deeper tradeoff concerns where flexibility resides. A team can retain choices among supported models while accepting the provider's execution design. Alternatively, it can preserve more execution control and take responsibility for maintaining it. Those are distinct forms of flexibility, with different engineering consequences.

For the Microsoft Copilot harness, the strongest practical interpretation is therefore bounded choice. Customers gain an additional managed route for agent development. They should evaluate that route on its documented capabilities, rather than treating the broader branding as a promise of universal compatibility.

Microsoft's Evaluation Gains Need Careful Interpretation

Microsoft's internal results support further evaluation, but they do not establish equivalent gains for every Foundry application.

In its agent evaluation results, Microsoft compares the Copilot harness with the Standard harness in Copilot Studio. It reports pass-rate improvements of 10.8 percentage points with an OpenAI model and 22.1 percentage points with an Anthropic model.

Microsoft also reports continued attempts after failed tool calls in 84–91% of evaluated cases, compared with fewer than 7% using the Standard harness. Its accompanying notes explicitly distinguish continued tool use and successful retries from successful completion of the overall task. These are company-reported findings, without independent validation established here.

That qualification is central to interpreting the announcement. Persistence describes behavior after something goes wrong. Completion describes whether the requested outcome was reached. A system can continue working and still misunderstand the task, use unsuitable evidence, or produce an unacceptable result.

The difference becomes concrete in a hypothetical customer-service workflow. An agent might successfully retry access to a case record but still recommend the wrong resolution. Measuring recovery from the failed connection helps explain execution behavior. It does not settle whether the customer received an accurate answer.

Similarly, a higher evaluation pass rate depends on what the evaluation asks. Buyers need to understand the relevant tasks, acceptance criteria, and configurations before transferring a result to their own environment. A percentage-point improvement is informative only in relation to the test it measures.

This does not diminish the importance of the surrounding execution system. Microsoft's reported comparison is consistent with the argument that model capability alone does not determine agent outcomes. It gives customers a reason to test execution choices alongside model choices, while keeping attribution and limitations explicit.

Microsoft also describes an internal support application that exceeded a 35% fully autonomous resolution rate in August 2026. The company defines that measure as resolving cases without human intervention. It is a concrete reported deployment, but its suitability as a comparison depends on the cases and operating conditions.

For an enterprise evaluating a similar application, autonomy should be considered alongside correctness and consequences. A case resolved without intervention can be useful evidence when the resolution is accurate and appropriate. The absence of intervention alone cannot establish that the outcome met the organization's standard.

Evaluation should also account for the work transferred to reviewers. If an agent produces more material but requires substantial correction, output volume can misrepresent its practical contribution. The business question concerns completed, acceptable work and the effort required to obtain it.

The same logic applies to failures that remain invisible until later. A polished briefing with an unsupported claim can appear successful at delivery. An evaluation that checks evidence and attribution would expose a different outcome. Acceptance criteria should reflect how the result will actually be used.

For now, Microsoft's numbers are useful evidence about its own tested environments. They justify investigation without replacing customer-specific testing. Buyers should resist converting a vendor comparison into a forecast for workloads that were not part of the reported evaluation.

Managed Execution Still Leaves Business Responsibility With the Customer

Delegating infrastructure does not transfer responsibility for deciding what an agent is allowed to do.

The clearest boundary concerns consequential actions. An agent that prepares a recommendation and an agent that commits the organization to that recommendation require different controls. A managed execution service can support either design, but the organization must decide where authority begins and ends.

Fashable offers a customer perspective within Microsoft's launch material. Chief executive Orlando Ribas Fernandes describes opportunities involving sourcing workflows, while keeping commercially binding decisions under human control. That is an intended operating boundary, rather than evidence that every proposed capability has already delivered a measured outcome.

The example illustrates why accountability cannot be inferred from automation. A sourcing assistant might compare specifications, identify missing information, or prepare negotiation material. Authorizing a purchase introduces a different responsibility. The distinction should remain visible even when those activities appear within a single conversation.

Long-running work introduces another boundary: remembering what happened versus knowing what remains valid. An agent can retain a previous result without knowing that circumstances have changed. Application owners need to determine when earlier information requires rechecking and which decisions depend on current evidence.

Anthropic's long-running agent research describes failures involving incomplete work and premature declarations of completion across sessions. Its proposed approach uses explicit progress records and incremental work. The broader lesson is that continued execution requires a reliable account of unfinished obligations.

For enterprises, that lesson suggests treating completion as a business condition. A task is finished when its acceptance criteria are met, including any required review or confirmation. A confident final message cannot substitute for evidence that those conditions hold.

Restarting interrupted work creates a related concern. Imagine a hypothetical agent that prepares a report and submits it to another system. If the submission succeeds but confirmation is lost, repeating the action can create duplicate records. The application needs a way to distinguish an unfinished action from an unconfirmed one.

Microsoft separately announced general availability of long-running resilience for hosted agents, where customers bring their own execution logic. Its documentation places responsibility for saved progress and duplicate prevention on application code. That separate feature should not be treated as a blanket guarantee for the new harness preview.

Information quality creates a further responsibility. An agent connected to outdated guidance can execute its instructions consistently and still produce unsuitable work. Teams considering a searchable knowledge base should treat source organization and maintenance as part of the application.

That relationship makes knowledge management relevant to the launch without implying a particular integration. Infrastructure determines how work proceeds; the available evidence constrains what the agent can reasonably conclude. Improving one does not eliminate weaknesses in the other.

Organizations should therefore assign ownership across the complete workflow. Someone needs responsibility for source material, permissions, acceptance criteria, and correction when outcomes fail. Managed execution can change the engineering burden, but it does not remove these organizational decisions.

The most credible adoption case identifies both the work the provider absorbs and the obligations the customer retains. That clarity makes it easier to judge whether the service reduces complexity overall. It also prevents a successful prototype from becoming an application nobody fully owns.

Three Signals Will Show Whether the Managed Approach Delivers

The next useful evidence concerns service maturity, comparative outcomes, and customer operations rather than additional launch claims.

The first signal is how Microsoft develops the Foundry preview over the coming months. Buyers should watch for clearer availability, supported configurations, migration options, and production guidance. Broader documented support would strengthen the case for adopting a common managed foundation across more applications.

The most meaningful expansion would address a requirement currently blocking a real deployment. Another supported configuration matters when it lets an organization operate within its technical and business constraints. A longer feature list, by itself, says less about whether a particular application becomes viable.

If preview restrictions remain significant for a customer's intended environment, the case for immediate adoption weakens for that customer. This is a workload-specific judgment. A limitation can be irrelevant to a research prototype and decisive for an application connected to sensitive operational systems.

The second signal is comparative evidence that separates model changes from execution changes. Evaluations should make clear which component changed and how success was measured. That would help buyers determine whether the reported benefit comes from the harness, the model, or their interaction.

Independent assessments would add confidence, particularly when they disclose failure categories and review requirements. A comparison focused on completed work would strengthen Microsoft's argument more directly than one focused only on activity. Results showing substantial configuration dependence would narrow how broadly the claim should be applied.

Competitive developments matter within that same comparison. Changes to Anthropic's managed offering, or another provider's execution approach, can alter the available alternatives. Buyers should compare services against a stable application requirement so that a changing market does not turn evaluation into an endless feature chase.

The third signal is customer reporting beyond initial deployment speed. Useful accounts would describe sustained operation, acceptable outcomes, correction effort, and the responsibilities retained by the customer. Evidence of lower maintenance alongside dependable results would strengthen the argument for purchasing the shared execution layer.

Accounts of extensive custom work would require a more careful reading. Customization can reflect valuable business specialization or gaps in the managed service. Understanding which explanation applies matters more than simply counting how much code a customer wrote.

These signals also provide a practical way to revisit an earlier decision. A team can reasonably build its own execution system today and adopt a managed service later. Another can begin with managed infrastructure and retain it only while the arrangement continues meeting its requirements.

Evaluate the Microsoft Copilot harness against a workflow your organization understands well. Define an acceptable result, identify which actions require approval, and record where human correction remains necessary. Compare the managed option with your existing approach using the same evidence and completion criteria. Include source quality, recovery behavior, and the effort required to investigate mistakes. Keep the decision tied to responsibilities your team can actually delegate, then revisit it as documented support and customer evidence develop. Microsoft's launch creates a concrete alternative to maintaining the entire execution foundation internally. The useful next step is to establish which parts of your own workflow that alternative improves, and what evidence would change your decision