Source: InfoQ — 2026-08-03
Summary
InfoQ reports that Microsoft's Agent Framework Harness — the execution runtime for the converged AutoGen/Semantic Kernel SDK that reached 1.0 GA in April 2026 — has moved to general availability alongside Foundry Hosted Agents, giving platform teams a supported way to run and govern production agents rather than just a library to build them with. The harness handles shell and filesystem access, human-in-the-loop approval, and context management across long sessions as a single runtime binary spanning local development, containers, and hosted deployment; Foundry Hosted Agents packages an agent as a container and deploys it onto Foundry-managed infrastructure with built-in identity, autoscaling, managed session state, observability, and versioning. Both are available now for .NET and Python, and third-party connectors — including for GitHub Copilot SDK and Claude Agent SDK — inherit the identity, content-safety, and observability policies already governing the rest of the agent fleet.
Key Takeaways
- Agent Framework Harness moves from library to governed runtime: it now runs as one binary across local dev, containers, and hosted deployment, with shell/filesystem access, human-in-the-loop approval, and long-session context management built in.
- Foundry Hosted Agents gives an agent a production home by packaging it as a container and deploying it onto Foundry-managed infrastructure, complete with built-in identity, automatic scaling, managed session state, observability, and versioning.
- Both the harness and Foundry Hosted Agents share the same concepts and APIs across .NET and Python, continuing the framework's converged-SDK approach since its April 2026 1.0 release.
- Third-party coding-agent connectors — including GitHub Copilot SDK and Claude Agent SDK — inherit the identity, content-safety, and observability policies already set for the rest of the fleet, rather than requiring a separate integration and access model.
- Coding-agent traffic lands in the same OpenTelemetry traces and Foundry dashboards as every other workload, giving platform teams one observability pane instead of agent-specific tooling bolted on the side.
Reel Script
Hook: Microsoft just turned its AI agent SDK into something platform teams can actually govern in production — one runtime binary, one identity model, one observability pipeline, whether the agent is built in-house or borrowed from GitHub Copilot or Claude's own SDK.
Core Concept: Building an agent SDK is only half the problem — the other half is what happens when that agent needs to actually execute: touch a filesystem, run a shell command, pause for human approval, or keep context alive across a session that runs for hours. That execution layer is what Microsoft calls the harness, and until now it existed but wasn't a governed, supported production target — it was closer to a library you wired in yourself. GA changes that: the harness now ships as a single runtime binary that behaves identically whether it's running on a developer's laptop, inside a container, or hosted in production, which matters because "works differently once it's deployed" is exactly the class of bug platform teams fear most. Foundry Hosted Agents is the deployment half of that story — instead of self-managing infrastructure for an agent, you package it as a container and hand it to Foundry, which takes care of identity, scaling, session state, and observability for you.
Hands-On: Picture the deployment pipeline as five stages, each one worth a box in a diagram. Stage one: you write an agent using the Agent Framework's shared .NET or Python APIs, same concepts either language. Stage two: the harness wraps it with shell access, filesystem access, a human-in-the-loop approval hook, and context management that survives a long-running session — and this exact same binary is what you ran locally during development, so there's no behavior gap between laptop and production. Stage three: you package that agent as a container and hand it to Foundry Hosted Agents. Stage four: Foundry deploys it onto its own managed infrastructure, and four things come free — built-in identity so the agent has a real, auditable service identity instead of a shared API key; automatic scaling; managed session state so a long conversation survives across instances; and versioning so you can roll an agent back. Stage five is the governance payoff: every action the agent takes emits OpenTelemetry traces that land in the same Foundry dashboards as the rest of your fleet's telemetry — not a separate agent-specific dashboard. That last stage is also why the third-party connectors matter: when you wire in the GitHub Copilot SDK or the Claude Agent SDK through this harness, that coding agent's traffic inherits the exact same identity, content-safety, and observability policies you already set for everything else, and its traces show up in the same place. A platform team auditing agent behavior doesn't need a special case for "agents built with someone else's SDK" — they're governed members of the same fleet.
Takeaway: GA here is the real signal: Microsoft is betting platform teams want one governed runtime for every agent touching production, not a pile of bespoke deployment scripts per SDK. If you're running agents with real filesystem or shell access today, put them through the harness and Foundry Hosted Agents before you build your own identity and observability layer from scratch.