Agent Harness GA: Microsoft Ships the 2026 Agent Runtime

An agent harness is the runtime wrapped around a language model that turns it into an agent: the tool-calling loop, context management, memory, approvals, and telemetry. Microsoft released a stable one in Agent Framework on July 22, 2026, moving the framework from a build-time SDK toward a supported runtime.¹

TL;DR

Microsoft's Agent Framework harness reached stable release on July 22, 2026, roughly three and a half months after the framework itself hit 1.0.²¹

The harness is not a small piece of the picture. An April 2026 paper from MBZUAI's VILA-Lab classified the leaked Claude Code source and found about 98.4% of it was harness infrastructure and roughly 1.6% was AI decision logic.³

That reframes what an agent framework is for. The model is the cheap part to swap; the loop, the permissions, and the context management are where the engineering lives — and where governance now happens.

Microsoft is not alone or first here. AWS shipped Loom, an open-source agent governance reference platform, on July 9, 2026,⁴ and Databricks published its own harness primer in June, arguing that as models converge, the harness increasingly decides performance.⁵

What You'll Learn

• What an agent harness is, and how it differs from an agent runtime
• Why research suggests the harness is the overwhelming majority of a production agent
• Exactly which harness features shipped stable — and which four did not
• How Foundry hosted agents bill, isolate sessions, and scale to zero
• Why coding-agent connectors are really a governance story
• How Microsoft's approach compares to AWS Loom and other platforms

What is an agent harness?

Microsoft principal software engineer Wes Steyn framed it bluntly in the release announcement: "A model on its own can only generate text."¹

To make that model call tools, work through multi-step tasks, remember what it has done, and keep going until a job is finished, you wrap it in a runtime. That runtime is the harness.

The distinction worth holding onto: a harness is application-layer scaffolding that turns a model into an agent. An agent runtime, in the narrower sense, is the infrastructure-layer environment where the agent actually executes.

In practice the two words get used interchangeably, including by vendors. Microsoft's own framing spans both — the harness runs locally, in containers, and on hosted infrastructure.

The 98.4% finding

The reason a supported harness matters more than it sounds comes from an unusual source: a packaging mistake.

On March 31, 2026, version 2.1.88 of the @anthropic-ai/claude-code npm package shipped containing a source map file that could be used to reconstruct Claude Code's TypeScript source.⁶ An Anthropic spokesperson told CNBC it was "a release packaging issue caused by human error, not a security breach," adding that no customer data or credentials were exposed.⁶

Researchers at MBZUAI's VILA-Lab analyzed the result. In a paper submitted to arXiv on April 14, 2026, Jiacheng Liu, Xiaohan Zhao, Xinyi Shang, and Zhiqiang Shen classified roughly 512,000 lines across about 1,884 files.³

Their split: approximately 98.4% harness infrastructure — permissions, context management, sandboxing, tool routing, recovery — and about 1.6% AI decision logic.³ Applying that 1.6% to the line count puts the actual model-reasoning layer at something on the order of 8,000 lines — our arithmetic, not a figure the authors state.

The figure deserves its asterisk, and the authors give it one. It is a line-count classification of a leak-derived bundle that includes generated and minified code, not a universal audit of all agents.

Even heavily discounted, the direction holds — and Anthropic's own product decisions point the same way. Its Agent SDK documentation describes the product as "Claude Code as a library," giving developers "the same tools, agent loop, and context management that power Claude Code."⁷

That is a harness being sold as the thing of value, separately from the model.

What actually shipped stable

The harness collapses the pipeline into a single call. You supply a chat client, instructions, and tools; the harness supplies the rest.

These features ship enabled by default, each individually customizable or removable:¹

That telemetry default matters more than it looks. If you want to see what tracing an agent loop actually involves, we walked through it in instrumenting the Claude Agent SDK with OpenTelemetry.

What did not ship

This is where secondary coverage has been imprecise, and it's the detail platform teams should care about most.

Four opt-in features were explicitly held back from the stable release. Microsoft lists them under "Coming soon," and they emit a warning when you enable them:¹

• Background agents — delegating sub-tasks to other agents concurrently
• File access — read/write file tools scoped to a working directory
• Looping — automatically re-invoking the agent until a completion condition is met
• Shell tooling — running shell commands, from the alpha-stage tools package

Read that list again. It is precisely the set of capabilities that make an autonomous agent genuinely autonomous — and genuinely dangerous.

Microsoft's stated reason is that it wants more customer feedback before releasing them. The practical effect is that the stable harness is the well-behaved subset, and the parts that touch your filesystem and your shell remain flagged.

Note also that Microsoft's Build 2026 recap described shell execution as shipping in the harness and .NET-only.⁸ The July release post moved it to the alpha tools package.¹ If you are planning around shell access, check the current package state rather than the June announcement.

Foundry hosted agents: the deployment half

The second half of the story is where these agents run. Hosted agents in Foundry Agent Service take your own code, packaged as a container image, onto Microsoft-managed infrastructure.⁹

The isolation model is per-session rather than per-replica. Every session gets its own VM-isolated sandbox with a persistent filesystem, and state is restored automatically when a session resumes.⁹

Concrete numbers from Microsoft's documentation: idle timeout is 15 minutes, maximum session lifetime is 30 days, and a session is permanently deleted after 30 days of inactivity. Each session gets up to 20 GiB of disk at 1 vCPU or larger, with about 20% reserved for system use.⁹

Sandbox sizes are fixed at three combinations — 0.5 vCPU/1 GiB, 1 vCPU/2 GiB, and 2 vCPU/4 GiB.⁹ Several secondary write-ups have reported a wider configurable range; the official documentation does not support that.

Billing is consumption-based on the underlying container compute, charged per vCPU-hour and per GiB-hour, with rates varying by region.¹⁰ Because every session runs in its own sandbox, the CPU and memory you set describe a single session — so oversizing multiplies cost by your concurrency.

Idle agents scale to zero and cost nothing, then scale back up on the next request, with the filesystem intact.⁸ That combination — stateful resume plus zero idle cost — is what makes long-running agents economically viable rather than a standing compute bill.

The runtime is framework-agnostic. Microsoft explicitly supports Agent Framework, LangGraph, Semantic Kernel, or custom code, in Python and C#.⁹ That is a notable choice: the deployment target does not require you to adopt Microsoft's SDK.

One limitation worth flagging: you cannot add tools directly to a hosted agent's definition. Tools come through a Toolbox MCP endpoint provisioned in your Foundry project.⁹ Traffic splitting between versions is also unsupported — an endpoint serves one immutable version at a time.

Hosted agents are listed as available across 31 Azure regions.⁹ On release status, the sourcing deserves care rather than a confident one-liner.

Microsoft's Foundry Agent Service GA post, dated March 16, 2026, listed hosted agents as preview in six new regions.¹¹ InfoQ reported in August that they had since reached general availability.² Microsoft's hosted-agents documentation, last updated July 21, flags only the A2A protocol endpoint as preview.

The likeliest reading is that the March post is simply out of date and hosted agents have since graduated. But if GA status gates a compliance sign-off, confirm it for your region rather than trusting any of the three.

Coding-agent connectors are a governance play

Agent Framework can delegate to the GitHub Copilot SDK or the Claude Agent SDK without custom adapters. Each runs its own autonomous loop, wrapped so it composes alongside Azure OpenAI, Anthropic, or custom agents in one workflow.²¹²¹³

Microsoft is specific about how far that goes: Claude agents implement the same BaseAgent interface as every other agent type, so they compose with Azure OpenAI, OpenAI, or GitHub Copilot agents in sequential, concurrent, handoff, and group-chat workflows without restructuring code.¹³

Worth noting the maturity gap, though. The Claude integration ships as a Python-only package still installed with a prerelease flag, while the GitHub Copilot SDK integration graduated to 1.0 at Build.⁸¹³

The interesting part is not the integration. It is that the connectors honor the identity, content safety, and observability policies already set for the fleet.

Coding-agent traffic lands in the same OpenTelemetry traces and Foundry dashboards as everything else, rather than becoming a separate integration with its own access model.

That is the same control-layer concern visible in AWS's Loom, released in July 2026 as an open-source reference platform on AWS Labs for governing agents on Bedrock AgentCore Runtime and Strands Agents.⁴ Loom's approach is stricter still: it prohibits runtime code generation, injecting configuration into pre-written, scanned harness code instead.

Two large clouds arriving at the same framing in the same quarter is a signal. The governing question is shifting from what an agent can do to who ran it, under which policy, and where the trace lands.

The runaway-loop difference

One benchmark illustrates why harness choice has safety consequences. It comes with caveats that need stating before the numbers.

As reported by InfoQ, Microsoft AI principal architect Aqib Sherwani compared Agent Framework against the GitHub Copilot SDK, publishing the results on LinkedIn.² Both are Microsoft-owned runtimes and Sherwani is a Microsoft employee, so this is vendor-run testing. We were not able to retrieve the original post to verify it independently, so the figures below rest on InfoQ's reporting rather than on the primary source.

With that stated: the method was more disciplined than most vendor benchmarks. The model was held fixed and a deterministic mock was run first, so variance traces to the harness rather than to model sampling.²

InfoQ summarizes his finding as "same reasoning, different engineering." Both runtimes reached identical answers in the same number of steps, and the differences lived in the runtime.

The most consequential one: Agent Framework halted its own loop after 40 round-trips and returned a limit-reached message.² The Copilot SDK, with host-side stopping controls off, ran to 300 without stopping on its own.²

One harness keeps the brake inside the loop. The other expects the host to supply it. If you have thought about what happens when an agent doesn't stop, that distinction is the whole ballgame — see our earlier look at agent kill switches and containment.

Orchestration and the CodeAct wildcard

The orchestration patterns reached stable release alongside the harness, covering sequential pipelines, concurrent collaboration, handoff, group chat, and the Magentic pattern.⁸

Magentic derives from Microsoft Research's Magentic-One, published in November 2024. Its evaluation reported 38% on GAIA, 27.7% on AssistantBench, and 32.8% on WebArena — statistically comparable to the state of the art on the first two and competitive on WebArena, which Microsoft scored itself because that benchmark has no hidden test set.¹⁴ Those are 2024 numbers, not current leaderboard positions.

Separately, Microsoft introduced CodeAct at Build 2026, in the alpha agent-framework-hyperlight package.⁸ Instead of chaining many small tool calls as separate model turns, the model writes one short Python program that calls tools, runs it once in a Hyperlight micro-VM, and returns a consolidated result.⁸

On Microsoft's own representative multi-step workload, the traditional wiring took 27.81 seconds and 6,890 tokens; CodeAct took 13.23 seconds and 2,489 tokens — 52.4% faster and 63.9% fewer tokens.⁸ It is a single vendor-run workload, and CodeAct is alpha, so treat it as directional.

Where agent code executes is becoming its own contested layer. Cloudflare has made a different bet, letting agents choose isolates or containers per command — we covered that in Cloudflare's agent runtime play.

What this means if you build agents

If you have written your own agent loop, the useful question is no longer whether your harness works. It is whether you want to keep maintaining it.

The 98.4% figure, caveats included, suggests most of the code in a serious agent is infrastructure that independent teams keep rebuilding in roughly the same shape. The VILA-Lab analysis compared Claude Code against OpenClaw, and coverage of the work notes that Claude Code, Codex CLI, Aider, and OpenClaw converged on similar harness patterns — which points to a constraint of the problem rather than a shared design fashion.²³

If you are on Semantic Kernel or AutoGen, the migration question is settled. Both predecessors sit in maintenance mode — bug fixes and security patches, no new features — following Agent Framework's introduction in October 2025, and Microsoft ships migration assistants for each.¹⁵¹⁶

If you are evaluating hosted deployment, the framework-agnostic runtime is the genuinely interesting part — you can deploy LangGraph agents without adopting Microsoft's SDK.

And if you are shipping autonomous agents, note what stayed behind the warning flag. Shell access, file writes, background sub-agents, and automatic looping are still the sharp edges, at Microsoft as everywhere else.

The bottom line

The headline is a stable harness. The actual story is that the agent framework wars moved down a layer.

Choosing an SDK was the 2025 question, and for Microsoft's ecosystem 1.0 settled it. The 2026 questions are where agents execute, what they are permitted to touch, and whether their behavior shows up in the observability and policy systems you already run.

Microsoft's answer bundles a supported harness, a consumption-billed hosted target, and a policy model that treats third-party coding agents as governed members of the fleet. AWS answered the same question two weeks earlier with different mechanics.

Worth remembering what the 98.4% number is really telling us. If the overwhelming majority of a production agent is permissions, context management, and recovery, then the interesting competition was never about models at all.