By The scaffolding every team was building themselves just shipped as a single binary. Microsoft’s Agent Harness — the runtime layer of the Agent Framework — reached general availability this week, alongside Foundry Hosted Agents. Together, they draw a straight line from local development to production deployment without touching your agent’s code. If you’ve been duct-taping together context compaction, tool approval flows, and memory persistence by hand, that work is now a NuGet package.
The Harness vs the SDK: A Distinction Worth Making
Microsoft Agent Framework 1.0 went GA in April 2026 — that was the SDK for building agents. What shipped this week is different: it’s the runtime for running them. The Harness is the execution layer that takes a model API and turns it into an agent capable of working through multi-step tasks without going sideways.
Out of the box, a Harness agent gets the agent loop, plan versus execute modes, session-scoped file memory, automatic context window compaction, human-in-the-loop tool approval with standing rules, and built-in OpenTelemetry. Every one of these is on by default. Every one can be removed. In .NET, you get there from a single extension method on any IChatClient:
dotnet add package Microsoft.Agents.AI
var harnessAgent = chatClient.AsHarnessAgent();Python gets the same through pip install agent-framework and create_harness_agent(chat_client). That’s the entire setup. The framework takes it from there.
What You Get Without Configuring Anything
Six providers ship with the Harness and handle the work most teams were doing themselves:
- FileMemoryProvider — Persists agent notes and learnings across turns, stored in
agent-file-memory/{session}/. The agent can recall what it figured out three tasks ago. - FileAccessProvider — General read/write access to files the agent operates on.
- TodoProvider — Tracks work items across plan and execute modes. The agent knows what it has done and what remains.
- AgentModeProvider — Controls the plan/execute state machine. The agent plans first, executes second, and doesn’t conflate the two.
- AgentSkillsProvider — Skill discovery and execution, so the agent can call into defined capabilities without wiring it manually.
- BackgroundAgentsProvider — Delegates subtasks to child agents, enabling fan-out workflows without custom orchestration code.
Context window overflow is handled automatically. The Harness monitors token usage and compacts history mid-loop so long tool-calling chains don’t blow the context ceiling. This is one of those problems that feels trivial until it silently kills an agent halfway through a real task.
The Numbers That Justify the Architecture
CodeAct — also from Build 2026, still in the alpha agent-framework-hyperlight package — illustrates why the execution layer matters. Instead of chaining tool calls as separate model turns, CodeAct has the model write a short Python program, run it once in a Hyperlight micro-VM, and return a consolidated result.
| Approach | Time | Tokens |
|---|---|---|
| Traditional tool chaining | 27.81 seconds | 6,890 |
| CodeAct | 13.23 seconds | 2,489 |
| Improvement | 52% faster | 64% fewer |
CodeAct isn’t stable yet — keep it out of production for now. But the numbers make the point: how you orchestrate tool calls is as consequential as which model you’re calling. The execution layer is not a commodity.
Multi-Agent Workflows
The Harness ships with four orchestration patterns, all with streaming support: sequential, concurrent, handoff, and group chat. The one worth paying attention to is handoff. You declare your agents and the directed edges between them; the HandoffAgentExecutor automatically injects routing tools into each agent and inspects responses for handoff calls. You define the topology. The framework handles the plumbing.
This is the pattern most teams were writing from scratch when building specialist-agent pipelines — a researcher hands off to a writer, a writer hands off to a reviewer. Declaring edges instead of wiring message-passing code by hand is a meaningful simplification, and it is now stable.
Deployment: Local to Production, Same Code
The Harness runs as one binary across local development, containers, and Foundry Hosted Agents. Your agent code doesn’t change between environments. The connectors enforce identity, content safety, and observability policies defined at the fleet level, and OpenTelemetry traces land in Foundry dashboards automatically.
One thing worth noting: you are not locked into MAF to use Foundry Hosted Agents. The platform also runs LangGraph, Semantic Kernel, and custom Python or C# code. If you’re already running agents with another framework, Foundry as a hosting target is still on the table.
What to Do Now
If you’re building agents in .NET or Python, the path forward is direct. Add Microsoft.Agents.AI via NuGet or agent-framework via pip. Wrap your current agent loop with AsHarnessAgent() or create_harness_agent(). Let the providers handle memory, compaction, and approval flows. The quickstart on Microsoft Learn walks through the first session in detail.
Watch CodeAct on the agent-framework GitHub — it’s the next meaningful performance lever once it graduates from alpha. For now, stable Harness GA is the move. The scaffolding you were building is now the framework. Ship the agent, not the plumbing.
