Microsoft offers a shared Copilot harness through Foundry

Microsoft announced that the agent harness developed by GitHub is being adopted across Copilot products and made available through Microsoft Foundry. The company describes it as a managed foundation for agents that reason, use tools, and carry out extended tasks across multiple models.

A harness supplies the instructions, context handling, execution environment, and controls around a model. Microsoft's announcement emphasizes support for open standards such as MCP and Agent Skills, along with plugins. The proposition is that developers can change models without rebuilding all of the surrounding orchestration.

Shared plumbing can reduce duplicated work

Many agent projects need the same basic machinery: manage a conversation, recover from tool errors, retain useful state, and enforce execution limits. Maintaining that infrastructure separately for every application can become a substantial engineering commitment.

A shared managed layer could make it easier to concentrate on the application's own tools and acceptance criteria. It can also create a common place to improve behavior across several products. The value depends on whether those improvements remain compatible with the workflows that already rely on it.

For a team evaluating the offering, the first question should be what remains under its control. Identify how instructions are assembled, where state is stored, how tool access is authorized, and what records are available after a failure. A convenient interface should still provide enough information for an operator to explain an unexpected action.

Model portability needs behavioral tests

Two models can accept the same tool schema and still behave differently. One may ask for clarification earlier; another may make more tool calls or handle ambiguous input differently. The application's important constraints should therefore be tested whenever the selected model or harness behavior changes.

A practical migration trial can replay a small set of representative tasks through the existing system and the managed harness. Compare accepted outputs, intervention frequency, elapsed time, and total cost. Include at least one tool failure and one task that should stop rather than continue.

Teams should also consider the cost of leaving. Exportable task state, understandable tool interfaces, and a record of important decisions can make a managed service easier to adopt without turning every future change into a rewrite.

Microsoft's announcement makes the harness a more explicit enterprise product. The best reason to adopt it is measurable reduction in maintenance and coordination work, supported by enough visibility to keep the resulting agents dependable as models and workflows evolve.