Microsoft has moved its Agent Framework from a developer SDK into a supported production runtime. The Agent Harness and Foundry Hosted Agents have reached general availability, completing a transition that began with the framework's 1.0 release on April 2, 2026.
The open-source Agent Framework consolidates Microsoft's earlier Semantic Kernel and AutoGen projects. Both predecessors moved into maintenance mode after the 1.0 release. The harness now serves as the runtime component that wraps models to enable tool use, multi-step tasks, and persistence. It runs as one binary across local development, containers, and hosted deployment.
The Harness Takes Center Stage
The harness is not a minor piece of plumbing. Microsoft principal software engineer Wes Steyn put it plainly: "A model on its own can only generate text." The harness supplies everything else: function invocation, per-call history persistence, context compaction, a todo list with plan and execute modes, file memory, skills, web search, tool approval, and built-in OpenTelemetry.
All harness features are enabled by default and individually removable. Shell tooling, file access, background sub-agents, and automatic looping are opt-in and emit a warning when enabled. That design gives platform teams a safe default with an explicit path to more powerful behavior.
Foundry Hosted Agents, the managed deployment target for Agent Framework agents, reached GA alongside the harness. The service is billed on consumption. Developers supply a chat client, instructions, and tools, and the harness supplies the rest via a single call. A code example uses FoundryChatClient with AzureCliCredential.
The shift in emphasis is deliberate. Microsoft is telling platform teams that the value of an agent system lives in the runtime that surrounds the model, not in the model's own text generation. The harness handles the repetitive, error-prone work of keeping an agent alive across multiple turns. It tracks what has happened, compacts context when it grows too long, and decides when a task is complete. For teams that have built their own scaffolding to do this work, the GA release offers a supported alternative that runs the same way in every environment.
What the Claude Code Analysis Reveals
The importance of the harness is supported by an external analysis of a different agent. MBZUAI's VILA-Lab produced a paper titled "Dive into Claude Code" analyzing Anthropic's coding agent. The full TypeScript source of Claude Code was exposed on March 31 when Anthropic shipped an npm release with a sourcemap bundle.
The finding matters for teams evaluating agent frameworks. If the largest share of a production agent's code is infrastructure, then the choice of runtime deserves as much attention as the choice of model. The VILA-Lab analysis is a single study of a single agent, and the classification method is coarse. But the pattern it identifies matches what Microsoft is now productizing. The harness is the system, and the model is a component inside it.
Safety Controls Differ Between Runtimes
Aqib Sherwani, Microsoft AI principal architect, ran a benchmark comparing Agent Framework against GitHub Copilot SDK. The benchmark held the model fixed and ran a deterministic mock first. Both runtimes reached identical answers in the same number of steps. Then the test pushed for runaway behavior.
Agent Framework halted its loop after 40 round-trips with a limit-reached message. Copilot SDK, with host-side stopping controls off, ran to 300 without stopping. The difference is structural. Agent Framework has a brake inside the loop. Copilot SDK expects the host to supply it.
This is a vendor-run benchmark comparing two Microsoft-owned runtimes. Still, the method is more disciplined than most vendor benchmarks, and the result illustrates a real design difference in where safety controls live.
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
The benchmark's first phase is worth noting for what it establishes. With the model fixed and a deterministic mock in place, both runtimes produced identical answers in identical step counts. That result suggests the harness does not interfere with the model's reasoning. The second phase shows where the runtimes diverge. A loop that runs 300 round-trips without stopping is a risk in production, especially when an agent has access to tools that can take actions. The harness's built-in limit of 40 round-trips is a conservative default, and it is one that platform teams can adjust to match their own risk tolerance.
Connectors Bring Third-Party Agents Into the Fold
At Build 2026, held June 2-3, 2026, Microsoft announced stable releases for the Agent Harness, the GitHub Copilot SDK connector, the Claude Agent SDK connector, and multi-agent orchestration patterns. The harness and Foundry Hosted Agents have since reached GA.
The connectors allow delegation to GitHub Copilot SDK or Claude Agent SDK without custom adapters. Each connector runs its own autonomous loop. Coding agents compose alongside Azure OpenAI, Anthropic, or custom agents in one workflow. The connectors honor identity, content safety, and observability policies set for the fleet. Coding-agent traffic lands in the same OpenTelemetry traces and Foundry dashboards.
That governance layer matters. The governing question shifts from what an agent can do to who ran it, under which policy, and where the trace lands. AWS Loom, a reference platform from AWS, shows a similar control-layer concern.
For platform teams, the connectors remove a significant integration burden. Building a custom adapter to route traffic between two agent runtimes is a project in itself. The stable connectors mean a team can put a GitHub Copilot SDK agent and a Claude Agent SDK agent in the same workflow without writing that glue code. The governance policies apply uniformly, so a coding agent does not become a blind spot in the observability stack. Every call, from any agent in the fleet, lands in the same trace and the same dashboard.
Orchestration Patterns and the Magentic Legacy
The orchestration patterns cover sequential pipelines, parallel collaboration, and the Magentic pattern. The Magentic pattern derives from Microsoft Research's Magentic-One. In a 2024 evaluation, Magentic-One scored 38% on GAIA, 27.7% on AssistantBench, and 32.8% on WebArena. Those results are statistically comparable to state of the art on GAIA and AssistantBench, and competitive on WebArena. WebArena has no hidden test set, so Microsoft reported results itself.
The patterns share one API. Teams change coordination styles without rewriting agent code. That flexibility is aimed at platform teams who need to support multiple workflows without multiplying maintenance burden.
The Magentic pattern is the most distinctive of the three. It uses a lead agent that orchestrates a team of sub-agents, each with a specific role. The 2024 evaluation numbers give a baseline for what that architecture can achieve. The GAIA and AssistantBench results are statistically comparable to state of the art, which means the pattern is not sacrificing quality for structure. The WebArena result is competitive, though Microsoft's self-reporting on that benchmark is the only source, since the test set is public.
The framework, harness, and connectors are available now in .NET and Python on GitHub. The key takeaway for platform teams is the runtime, not the SDK. The harness is most of the system, and it is now a supported, observable, and governable place to run agents. When asked how to approach the work, Steyn's guidance was direct: "You are a research assistant. Plan your work, then execute it."
That advice captures the intended workflow. An agent should plan before it acts, and the harness gives it the structure to do both. For teams that have been running agents on custom scaffolding, the GA release offers a supported path forward. For teams that have not started, the harness provides a default that is safe, observable, and ready for production.