Agent harnesses - the layer that owns the loop

By 2026 the words “harness”, “framework” and “protocol” are used as if they named the same thing, and the confusion is expensive, because they are three different layers of an agent system and you choose each one by different criteria.

A harness is the execution system that wraps a model and turns it into a working agent. It owns the loop - the cycle of reason, call a tool, read the result, decide whether to stop - and everything the loop needs around itself: conversation state, the permission policy, the sandbox where code runs, the context strategy, and what happens when a run is interrupted. Anthropic’s own documentation describes the Claude Agent SDK as exposing “the same tools, agent loop, and context management that power Claude Code” - the loop is the product.

What a harness gives you that a framework does not

A framework - LangGraph, the OpenAI Agents SDK, Microsoft Agent Framework - is a library of primitives. It gives you model clients, tool abstractions, graph or workflow orchestration, memory interfaces and observability hooks, and a skeleton for the loop. You still write the policy: which tools need approval, how state survives a restart, when the loop gives up.

A harness is what you get when those decisions have already been made. The comparison that shows the difference:

The right way to read the table is not “harness is better” but “they answer different questions”. A framework answers what parts do I have to work with. A harness answers who runs the agent and under what rules. A protocol answers how does this agent reach anything outside itself.

Where the harnesses actually are

The vendors have been quietly consolidating the loop into a product:

• Claude Agent SDK - the harness behind Claude Code, exposed as a Python or TypeScript library. It gives you the built-in tools, the permission system, sessions you can resume or fork, hooks into the agent lifecycle, and automatic loading of skills, commands and memory from .claude/ - in other words, the whole loop, configurable rather than assembled. Anthropic also offers Managed Agents, the same loop hosted, running in an Anthropic-managed or self-hosted sandbox.
• OpenAI Agents API - the harness behind Codex, exposed as a managed endpoint. You supply a task, a model, tools and a sandbox choice (OpenAI-hosted, self-hosted, or a partner such as E2B, Daytona or Vercel) and get a running agent in one call; OpenAI runs and maintains the loop.
• Microsoft Agent Framework reached 1.0 in April 2026 - a framework rather than a harness, which is the point of naming it here: a framework can be the basis of a harness, but it is not one out of the box.

The pattern underneath all three is the same one the MarkTechPost taxonomy names: a harness is opinionated - it ships a loop, a permission model and a context strategy as a unit - where a framework gives you the parts and the decision burden.

Why the layer emerged

The honest answer is that the loop turned out to be the hard part. Early agent development was a prompt-engineering problem; once models could reliably plan and call tools, the durable work moved to everything around the model - managing context across long runs, deciding which tools fire automatically versus ask permission, keeping state when a session is interrupted, and knowing where the generated code physically runs. Those are the harness’s jobs, and they are the ones a production deployment cannot leave to the developer’s ad-hoc code.

Where it breaks

• A harness is opinionated by design - that is the product and the lock-in. Its permission model, its context strategy, its idea of when to stop - you inherit all of it, and swapping harnesses later means re-expressing your agent’s whole behaviour, not just its calls.
• “Managed” is a spectrum that matters. A hosted harness (OpenAI Agents API, Anthropic Managed Agents) runs the loop on the vendor’s infrastructure; a self-hosted one (Claude Agent SDK) runs it in yours. They are different products wearing the same name, and the data-residency and cost questions are entirely different.
• The harness does not remove the framework decision. Pick a harness for the loop and you still choose a framework or SDK for the parts it does not cover - the layers stack, they do not merge.
• Permissions are the harness’s promise and its failure surface. The whole point of the sandbox-and-approval policy is to bound what the loop can do; a misconfigured permission set is precisely the failure a harness is meant to prevent.

What this is not for

• A task that is really one function call - if a tool invocation suffices, a wire call to it beats running a loop.
• Workflows where you genuinely need to design the loop yourself - a framework plus your own policy is the honest answer when the harness’s opinions do not fit, because fighting an opinionated harness is worse than writing a simple loop.
• Replacing the protocols - a harness still uses MCP to reach tools and A2A to reach other agents; it does not absorb them.