Agent Framework Harness GA: build or buy your agent loop

On 3 August 2026, InfoQ reported that Microsoft's Agent Framework Harness and Foundry Hosted Agents have reached general availability. This closes a rollout that started with Agent Framework 1.0 on 2 April 2026 and continued through the Agent Harness preview at Build 2026 in early June. The harness is a production runtime that wraps a model with everything an agent needs beyond text generation: function invocation, context compaction, todo-list planning, file-based memory, skills, web search, OpenTelemetry tracing and tool-approval workflows. It runs as one binary on a laptop, in a container, or fully managed on Foundry Agent Service, where Hosted Agents bill on consumption. For any Swedish or EU team that has spent the past year hand-rolling an agent loop on Azure, the question has changed. It is no longer "how do we build this?" but "should we still be building this at all?"

What actually shipped, and when

The timeline matters because it tells you how much of this is stable versus fresh. Microsoft Agent Framework hit 1.0 GA on 2 April 2026, unifying Semantic Kernel's enterprise foundations with AutoGen's multi-agent orchestration in Python and .NET. At Build 2026 on 2 and 3 June, Microsoft previewed the Agent Harness and announced that Hosted Agents in Foundry Agent Service would reach GA within 30 days, alongside stable releases of the GitHub Copilot SDK connector, the Claude Agent SDK connector and the Handoff orchestration pattern. The August GA completes the set: the harness itself and the hosted runtime are now supported production surfaces, not previews.

Microsoft principal engineer Wes Steyn framed the motivation bluntly in the GA coverage: "A model on its own can only generate text." Everything else that makes an agent useful is infrastructure. InfoQ cites research analyzing Claude Code v2.1.88 which found that roughly 98.4 percent of that agent's codebase is harness infrastructure rather than AI decision logic. Whether the exact figure generalises, the direction is clear from anyone who has built one: the model call is the easy part.

What the harness gives you for free

The Agent Harness is the layer where model reasoning meets real execution. Concretely, the GA release includes:

Function invocation and tool execution with per-call history persistence, so the loop survives restarts.
Automatic context compaction that monitors token usage and compresses history before long tool-calling sequences overflow the context window.
Todo-list planning with distinct plan and execute modes via the AgentModeProvider, so an agent can be forced to propose before it acts.
File-based memory and skills: session-scoped persistent learnings plus modular capability injection through the AgentSkillsProvider.
Built-in web search, which can be disabled where policy requires it.
Tool-approval middleware with "don't ask again" rules, giving you a human-in-the-loop gate without writing one.
OpenTelemetry observability wired in by default, flowing into Application Insights on Azure.
Optional, explicitly flagged extras: shell tooling (.NET only), file access, background sub-agents for delegating subtasks, and automatic looping. Microsoft ships these behind warnings because each one widens the blast radius of a misbehaving agent.

One performance feature deserves its own mention. CodeAct collapses multi-step agent loops by letting the model write a single Python program that calls tools through a call_tool() function, then executing that program in a sandboxed Hyperlight micro-VM. Microsoft's own benchmarking claims a 52.4 percent latency reduction and 63.9 percent token savings on representative workloads. Treat vendor benchmarks as vendor benchmarks, but the mechanism is sound: one round trip instead of N, and token spend that scales with the program rather than with the transcript.

What rolling your own actually costs

Most DIY agent loops on Azure start as forty lines of code: call the model, check for tool calls, execute them, append results, repeat. That version demos well. The production version is where the engineering months go, and it is worth being honest about the inventory before comparing it to a supported runtime:

Context management. Long tool sequences blow past context windows. You need summarisation or compaction, and you need it to preserve the facts the agent still depends on.
Durability. A loop that dies mid-task loses work unless you persist per-call history and can resume. That means a state store, a schema and replay logic.
Approvals and guardrails. Legal and security will not sign off on an agent that executes arbitrary tools unsupervised. Approval gates, allowlists and audit trails are table stakes in an enterprise.
Observability. When the agent does something strange in production, you need the full trace: model calls, tool invocations, sub-agent hops. Wiring OpenTelemetry through a custom loop correctly is real work.
Memory. Cross-session preferences and learned procedures need storage, retrieval and expiry policies.
Hosting. Containerisation, web server, health checks, session routing, scaling, identity, secret handling and version rollbacks. None of it is agent logic. All of it is on your on-call rota.

Every one of those bullets is now a checkbox in the harness or the hosted runtime. That does not automatically make the harness the right answer, but it moves the burden of proof. A custom loop now has to justify itself against a supported alternative that costs nothing extra to adopt at the framework level.

Hosted Agents: what the managed runtime looks like

Foundry Hosted Agents are the deployment target for the harness (and for LangGraph, the GitHub Copilot SDK, or fully custom code; the runtime is framework-agnostic). The model is straightforward: you package your agent as a container image, push it to Azure Container Registry, and deploy. The platform pulls the image, assigns the agent a dedicated Microsoft Entra agent identity, and exposes a dedicated endpoint.

The runtime characteristics that matter for architecture decisions:

Per-session VM-isolated sandboxes. Each session gets dedicated compute, memory and a persistent filesystem. Sessions are isolated from each other, and state under the home directory survives idle periods.
Scale to zero with stateful resume. After a configurable idle timeout (5 to 60 minutes, default 15), the platform deprovisions compute and persists session state. The next request restores it onto fresh compute.
Two primary protocols. Responses is OpenAI-compatible and platform-managed: conversation history, streaming and background execution come for free, and any OpenAI-compatible SDK works as the client. Invocations is schema-free JSON in, JSON out, for webhooks, batch processing and custom streaming. A single agent can expose both.
Sandbox sizes. 0.5 vCPU / 1 GiB, 1 vCPU / 2 GiB, or 2 vCPU / 4 GiB per session.
Immutable versions. Each deployment is a snapshot of image, resources, environment variables and protocol configuration. The endpoint serves exactly one version at a time; there is no traffic splitting.
Built-in tracing. The platform injects an Application Insights connection string into the container, and the protocol libraries emit OpenTelemetry traces by default.

The consumption cost model, and where it bites

Billing is based on CPU and memory consumed during active sessions, metered against the sandbox size you chose. Current rates are on the Foundry Agent Service pricing page; model inference is billed separately through your model deployments. Three consequences follow from the per-session design:

Oversizing multiplies by concurrency. The vCPU and memory you set describe one session, not the agent. Fifty concurrent sessions at 2 vCPU is one hundred vCPUs on the meter. Right-size against observed usage in Application Insights, not against instinct.
Idle timeout is a cost dial. A 60-minute timeout keeps sessions warm and responsive; a 5-minute timeout minimises billed idle compute at the price of more cold resumes. For internal tools with bursty usage, shorter timeouts usually win.
Scale to zero changes the baseline. Unlike an always-on AKS deployment or a minimum-replica Container App, an idle hosted agent costs nothing for compute. For agents with low or spiky traffic, that alone can beat a self-managed deployment on price.

The comparison to run yourself: take your current agent's Container Apps or AKS cost (including the replicas you keep warm for latency), add the engineering time spent on session routing and state persistence, and put it next to a consumption estimate built from your real concurrency and session-duration numbers. Microsoft's guidance is to aim for sustained peaks around 70 percent of allocation and adjust the next version accordingly.

Decision framework: harness, hosted, or your own loop

Default recommendation: if you are standardised on Microsoft and starting a new agent in 2026, begin with the Agent Framework Harness locally and deploy to Hosted Agents. Depart from that default only when one of the conditions below applies to you.

Choose harness + Hosted Agents when: your stack is Azure and Entra ID; you want tool approvals, compaction and tracing without building them; your traffic is spiky enough for scale-to-zero to pay off; you plan to publish to Teams or Microsoft 365, where the platform bridges the Activity protocol automatically.
Choose harness in your own container (Container Apps, AKS, on-prem) when: you want the runtime behaviours but need compute in a specific network topology, a region Hosted Agents does not cover, or an exit path that does not depend on Foundry. The single-binary design makes this a legitimate middle option, not a compromise.
Keep (or build) your own loop when: your agent's control flow genuinely does not fit the harness model, for example a fixed deterministic pipeline that only occasionally consults a model; you are multi-cloud with a hard requirement to avoid Azure-specific runtimes; or you have an existing, instrumented, approved loop in production and the migration cost exceeds the maintenance cost. Rewriting a working agent to be fashionable is not engineering.
Watch the optional features. Shell access, file access, sub-agents and automatic looping ship behind warnings for a reason. If you enable them, do it per-agent with a documented risk assessment, not as a global default.

The Swedish and EU angle

Region availability includes Sweden Central. Hosted Agents launched with a region list that covers Sweden Central along with West Europe, Germany West Central, France Central, Poland Central, Spain Central, Italy North and both Norway and Switzerland regions. Swedish organisations with a data-residency requirement can keep agent compute and session state in-country. Verify the session-storage and Application Insights regions in your own deployment, since your data-flow documentation must cover all three.

Agent identity is an audit story you no longer have to invent. Every hosted agent gets its own Entra agent identity at deploy time, distinct from the project's managed identity. The agent authenticates to models, tools and downstream Azure services as itself, and user-invoked scenarios support OAuth On-Behalf-Of flows so delegated permissions apply. For teams answering NIS2-driven questions about who or what accessed a system, "each agent is a first-class directory principal with its own RBAC assignments" is a far stronger answer than a shared service principal behind a custom loop.

Third-party components remain your compliance problem. Microsoft's documentation is explicit that non-Microsoft tools, servers and models used from a hosted agent are used at your own risk, with data potentially flowing to those services under their own terms. GDPR Article 28 processor chains and transfer assessments do not get easier because the runtime is managed. Inventory every tool your agent can call, and treat the built-in web search as a data flow to review, and disable it where the workload handles personal data it must not leak into queries.

Procurement gets a cleaner answer. Public-sector and regulated buyers in Sweden ask about support horizons. "Custom agent loop maintained by two developers" is a hard line item to defend in an upphandling. A GA Microsoft product with documented versioning, region commitments and consumption pricing is the kind of dependency procurement frameworks know how to evaluate. That is not a technical argument, but it decides real deals.

Private networking is supported. Hosted agents can deploy into network-isolated Foundry resources and use a customer-provided VNet for outbound traffic, so agents can reach internal databases and APIs without public exposure. Note the constraint on container registries: projects created after 25 June 2026 support a network-secured Azure Container Registry, while older projects need the registry reachable over its public endpoint.

Takeaways

1. The DIY-agent-loop era on Azure is ending. With the harness and Hosted Agents at GA, a custom loop is now a choice that needs justification, not the default.
2. Audit your existing loop against the harness feature list. Compaction, durability, approvals, tracing and memory: anything you built yourself is now maintenance you can plan to retire.
3. Price it with your real numbers. Session concurrency times sandbox size times active hours, against your current warm-replica cost. Spiky workloads favour Hosted Agents; steady high-volume workloads deserve the comparison in a spreadsheet.
4. Tune the idle timeout deliberately. It is the main lever between latency and cost, and the 15-minute default is nobody's optimum.
5. Use Sweden Central if residency matters, and document where session state and traces land.
6. Treat agent identities as directory citizens. Put the auto-created Entra agent identities into your access-review process from day one.
7. Gate the dangerous features. Shell, file access, sub-agents and auto-looping stay off until a named owner accepts the risk in writing.