Agent Harness vs Framework vs MCP: Who Actually Owns the Loop?

Agent harness, agent framework, and MCP get used as synonyms in almost every architecture discussion. They are not synonyms. Each sits at a different layer, owns a different slice of agent behavior, and overlaps with the others only at the edges. This breakdown maps five core responsibilities: execution loop, state, tool transport, permissions, and recovery. Knowing which layer owns each one prevents the most common agent design mistakes.

What happened

Layer	Key fact
Agent harness	Ships a fixed loop, sandbox, and permission model as one unit (Claude Code, OpenAI Codex platform)
Agent framework	Provides configurable primitives: LangGraph, OpenAI Agents SDK, Microsoft Agent Framework 1.0 GA (April 2026)
MCP	Stateless JSON-RPC 2.0 wire protocol; session handshake retired in the July 28 2026 spec update
Governance	Linux Foundation’s Agentic AI Foundation governs MCP since December 2025

The three terms describe three genuinely different things, and mixing them up tends to produce agents with no clear owner for state management, confused permission boundaries, or recovery logic that nobody actually implemented.

The three layers, defined plainly

Agent harness

A harness wraps a model and turns it into a working agent. OpenAI’s Codex platform post from August 19 2026 defines it directly: the harness manages conversation state, streams execution, runs tools, enforces sandbox and approval policies, and carries work across turns. Anthropic’s Claude Code documentation uses the same term. The Claude Agent SDK exposes “the same tools, agent loop, and context management that power Claude Code.”

The harness is opinionated by design. You get a loop, a permission model, a sandbox, and a context strategy as one unit. The loop is not yours to rewrite. The Claude Agent SDK documents its loop as five steps: receive prompt, evaluate and respond, execute tools, repeat, return result. Each full cycle is one turn. The loop ends when the model produces a response with no tool calls.

Agent framework

A framework is a library of primitives. It covers model clients, tool abstractions, graph orchestration, memory interfaces, and observability hooks. You assemble those parts and configure the loop yourself. Notable examples include LangGraph (where the loop is whatever graph you draw), the OpenAI Agents SDK (loop terminates on final output, raises MaxTurnsExceeded when the limit is hit), and Microsoft Agent Framework, which reached 1.0 GA in April 2026.

The framework gives you the skeleton. You decide the policy: termination conditions, handoff logic, turn caps, guardrail behavior.

MCP

The Model Context Protocol is a wire protocol, not a runtime. It standardizes how an LLM application discovers and calls capabilities exposed by servers: tools, resources, and prompts. The transport is JSON-RPC 2.0 over stdio or Streamable HTTP.

Crucially, the July 28 2026 specification made the protocol core stateless. The initialize/initialized handshake and the Mcp-Session-Id header were retired. Every request now travels alone, carrying its protocol version and client capabilities in _meta. MCP has no loop and, since that update, no session layer either. If a server needs state across calls, it mints a handle from a tool and the model passes it back.

Who owns what: the full ownership map

Responsibility	Agent harness	Agent framework	MCP
Execution loop	Owns: fixed, product-grade loop	Owns skeleton: you configure termination and turn caps	None: request/response only
Agent state and memory	Owns: sessions, resume, fork, file checkpointing	Exposes: checkpointers, session stores, thread IDs	None at protocol level (since July 28 2026)
Tool transport	Consumes: built-in tools plus MCP client	Consumes: function tools plus MCP client	Owns: JSON-RPC over stdio or Streamable HTTP
Permissions and approvals	Owns: permission modes, hooks, sandbox	Exposes: guardrails, interrupts, middleware	Delegates to host: cannot enforce
Recovery	Owns: session resume, checkpoint rewind, compaction	Exposes: durable execution, replay, retries	Partial: tasks extension for long-running calls
Isolation and sandboxing	Owns: OS sandbox, worktrees, containers	Optional: hosted sandboxes or micro-VMs	None
Multi-agent orchestration	Owns patterns: subagents, dynamic workflows	Owns primitives: graphs, handoffs, fan-out	None: A2A covers agent-to-agent

Why it matters

Most agent reliability failures trace back to ownership gaps in this table. If you build on a framework and assume it handles state recovery the way a harness does, you will lose work on crashes unless you explicitly attach a checkpointer and pass a thread ID. LangGraph offers three durability modes: “exit” (persists only when the graph exits), “async” (writes while the next step runs), and “sync” (writes before each step). Choose wrong and a mid-run crash silently drops state.

Permissions are the other common gap. MCP cannot enforce access policies. It delegates to the host. If your harness or framework does not define an approval policy, no layer does. The Claude Agent SDK and the Codex harness both own this explicitly. A bare framework implementation does not.

For teams exploring AI integration for production workflows, the choice between harness and framework is effectively a build-vs-buy decision on loop reliability, sandboxing, and recovery. A harness trades flexibility for correctness guarantees. A framework trades guarantees for control.

Our take

The conflation of these three terms is not just an academic problem. We see it cause real scoping failures: teams building with LangGraph who expect session resume without configuring a checkpointer, or teams adopting MCP and assuming the protocol handles permissions when it explicitly does not.

The ownership table above is the most useful mental model we have seen for cutting through the noise. Build from it before you write a line of agent code. If you are evaluating whether to use a harness (lower flexibility, higher correctness) versus a framework (higher flexibility, you own reliability), that decision should happen at the architecture stage, not after you have shipped something fragile into production.

The July 28 2026 MCP statelessness change is also worth watching closely. Server developers who relied on session headers for state continuity need to migrate to handle-based state. The protocol is moving toward simpler, more composable primitives, which is sensible, but it shifts more responsibility onto host implementations. We have been covering shifts in how AI agents are architected and resourced across several stories, and this is consistent with a broader trend toward leaner protocols with heavier host-side logic.

What to do about it

1. Map your agent’s five responsibilities (loop, state, tools, permissions, recovery) against the ownership table before choosing a stack.
2. If you need guaranteed state recovery and sandboxing out of the box, evaluate a harness first (Claude Agent SDK, OpenAI Codex platform).
3. If you need custom loop logic, multi-graph orchestration, or polyglot tool composition, pick a framework and explicitly wire each durability and permission layer yourself.
4. Treat MCP as a tool transport contract only. Do not rely on it for state or permissions.
5. If your MCP servers used session headers for state continuity, migrate to handle-based state patterns as described in the July 28 2026 specification.

The simplest rule: whichever layer you choose, make sure someone in that stack explicitly owns each row of the table above.

Source: Marktechpost