# Agent Harness vs Agent Framework vs MCP: What Each Layer Actually Owns
## Introduction
The AI agent ecosystem has produced three terms that get tossed around as if they mean the same thing: harness, framework, and MCP. They do not. Each occupies a distinct layer of the stack, carries different responsibilities, and increasingly brushes against the others at the boundaries. Understanding where one ends and another begins matters enormously when designing agent systems — it determines what you get for free, what you have to build yourself, and where your control lies.
This article breaks down the three categories and answers a single guiding question: which layer owns the execution loop, state management, tool communication, permission enforcement, and failure recovery?
—
## The Three Layers Defined
### Agent Harness
A harness is the execution system that wraps a language model and turns it into a functioning agent. Think of it as the engine that drives the model through a structured workflow. It handles the conversation thread, manages state across multiple turns, streams results, and invokes tools as needed. Critically, a harness also enforces sandbox policies and approval mechanisms, carrying work forward even when a session spans many turns.
A harness is opinionated by design. It ships with a predetermined loop structure, a built-in permission model, a sandboxing strategy, and a context management approach — all bundled together as a cohesive unit. You configure it; you rarely rewrite it.
### Agent Framework
A framework is a library of building blocks for composing agents. It provides primitives like model clients, tool abstractions, orchestration graphs, memory interfaces, and observability hooks. A framework gives you the skeleton of a loop and the raw materials to assemble agent behavior, but it leaves policy decisions — approval flows, persistence strategies, sandboxing — up to you.
Frameworks range from graph-based orchestration engines to SDK-style libraries that expose modular components. The common thread is flexibility: you assemble the pieces, and you decide how they interact.
### Model Context Protocol (MCP)
MCP is a communication standard — a wire protocol that defines how an application (the host) discovers and invokes capabilities served by external servers. These capabilities include callable tools, readable resources, and templated prompts. MCP uses JSON-RPC 2.0 messages passed between hosts, clients, and servers over standard input/output streams or HTTP.
MCP owns nothing at runtime. It has no loop, no agent state, no execution engine. It defines a contract — a shared language — between the agent and the tools it uses.
—
## Ownership Matrix
| Responsibility | Agent Harness | Agent Framework | MCP |
|—|—|—|—|
| **Execution loop** | Defines and enforces a fixed loop with turn limits, context compaction | Provides a skeleton you configure — termination conditions, handoffs, turn caps | None — request/response only |
| **State and memory** | Owns sessions, resume, fork, checkpointing | Exposes checkpointers and session stores, but does not decide persistence policy | Stateless at protocol level |
| **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 enforcement | Exposes guardrails and middleware hooks — you write the policy | Delegates entirely to the host |
| **Recovery** | Owns session resume, checkpoint rewind, context compaction | Exposes durable execution and retry mechanisms | Partial — Tasks extension for long-running calls |
| **Isolation and sandboxing** | Owns OS-level sandbox, containers, worktrees | Optional — can integrate hosted sandboxes or micro-VMs | None |
| **Multi-agent orchestration** | Owns patterns like subagents and dynamic workflows | Owns primitives like graphs, handoffs, and fan-out | None (A2A covers agent-to-agent communication) |
—
## Who Owns the Execution Loop?
Every agent runs a repeating cycle: send context to the model, read the response, execute any requested tool calls, feed results back, and repeat. Both harnesses and frameworks implement this cycle, but they differ in how much control they hand to the developer.
A harness runs a fixed loop. The loop typically follows a defined sequence — receive input, evaluate and generate a response, execute any tool calls, repeat until a final answer is produced, and return the result. Each full cycle counts as one turn, and the loop terminates when the model produces a response that contains no further tool calls. Importantly, the loop itself is not something you rewrite. What you can do is intercept it — inserting hooks that modify or block tool calls before they execute.
A framework, by contrast, gives you the loop’s skeleton. You define when it stops, what happens on handoffs between agents, and what occurs when a turn limit is reached. Some frameworks raise explicit exceptions when limits are hit, allowing you to catch and handle them. In graph-based frameworks, the loop is whatever structure you draw — nodes, edges, and conditional routing define the control flow entirely.
MCP has no loop. The protocol is stateless and request-driven. Every message travels independently, carrying its protocol version and client capabilities. The host’s own loop decides when to invoke a tool. MCP simply defines what that invocation looks like on the wire.
—
## Who Owns State?
State management is where harnesses distinguish themselves most clearly. A harness keeps agent state alive across sessions. It supports resuming interrupted work, forking from a prior point, and rolling back file changes to previously saved checkpoints. Some harness implementations even perform automatic context compaction, monitoring token usage mid-loop and consolidating conversation history to stay within context windows.
Frameworks expose state primitives but do not dictate how they are used. You must attach a checkpointer, provide a thread identifier, and choose a durability mode — whether to persist only when the graph exits, to write asynchronously during execution, or to synchronize before each step. Choose incorrectly, and a crash mid-execution can wipe accumulated progress.
MCP’s position is firm: the protocol core is stateless. If a server needs to maintain state across calls, the pattern is to mint a handle from a tool call and pass it back as an argument in subsequent requests. State belongs to the agent, not the protocol.
—
## Who Owns Tool Transport?
This is the single responsibility MCP owns outright. The protocol defines how tools, resources, and prompts are discovered and invoked between an application and external services. It uses JSON-RPC 2.0 messages transported over standard I/O streams or Streamable HTTP.
Recent updates to the specification have sharpened this focus. Mandatory headers on HTTP requests now allow gateways and rate limiters to route traffic without parsing message bodies. Tool listing responses can be cached with configurable time-to-live values and scope settings. Legacy transport methods have been deprecated with a clear migration path.
Meanwhile, both harnesses and frameworks consume MCP as a client — they sit on top of the protocol, translating their internal calls into MCP-compliant messages and receiving responses back.
—
## Who Owns Permissions?
The MCP specification is explicit: hosts must obtain explicit user consent before invoking any tool. Tool descriptions should be treated as untrusted unless the server providing them is trusted. The protocol itself cannot enforce these security principles — it can only carry the request for approval across the wire.
Harnesses own the permission model end to end. They ship with multiple permission modes that range from fully automatic to fully manual, including configurations that route each tool call through a background classifier for risk assessment. Custom hooks can be attached at decision points to inject additional logic.
Frameworks expose the hooks but not the policy. They provide mechanisms like interrupts and guardrails that pause execution and wait for input, but you must write the approval logic and the user interface yourself.
—
## Who Owns Recovery?
Recovery is where harnesses demonstrate their value most dramatically. A harness can resume a session after interruption, rewind file changes to a known checkpoint, and compact context when a window fills up. These capabilities turn a fragile process into a resilient one.
Frameworks require you to design for recovery explicitly. Durable execution depends on determinism — wrap side effects in tasks, keep nodes idempotent, and a interrupted run can resume later. The framework provides the replay mechanism, but you are responsible for making your code safe to replay.
MCP addresses a narrower slice of this problem. Its Tasks extension, contributed by the broader community, supports long-running tool calls through a poll-based mechanism. This covers a single extended operation, not full agent-level recovery.
—
## Architecture in Practice
A typical agent stack organizes into four layers. At the top sits the application — your product, its user interface, its business rules, and its consent flows. Below that are the runtime layers: the harness or framework (or both), which manage the agent’s behavior. The transport layer sits beneath, handled by MCP. At the bottom are the capabilities — the MCP servers that expose tools and data from external systems.
This layered approach means the application never talks directly to capabilities. It delegates to the runtime layer, which delegates to the transport layer, which talks to the servers. Each layer has a single responsibility, and the boundaries between them create natural points of control and security.
—
## Frequently Asked Questions
**Q: Can I use MCP without a harness or framework?**
A: Technically yes. MCP is a wire protocol, so you can write a client that speaks JSON-RPC 2.0 directly to servers. However, you would need to build the loop, state management, permissions, and recovery yourself — which is what a harness or framework exists to provide.
**Q: Does a framework replace a harness?**
A: Not necessarily. A framework gives you the building blocks, while a harness gives you a complete execution environment. Many production systems use both — a framework for orchestration and a harness for the heavy lifting of each agent step.
**Q: Is MCP evolving into a runtime?**
A: No. The maintainers have kept the protocol core focused on being a communication standard. Features like elicitation and the Tasks extension add capability, but the fundamental design remains stateless and request-driven. Agent behavior still lives in the harness or framework layer.
**Q: What happens when a tool call needs user input mid-execution?**
A: MCP now supports this through its elicitation feature, enhanced by Multi Round-Trip Requests. A server can signal that input is required, and the host pauses the loop, collects the input, and retries the original call with the new information attached.
**Q: Should I start with a harness or a framework for a new project?**
A: If you need a proven loop with approvals and recovery built in, start with a harness. If you want full control over the loop structure and are comfortable building permissions, persistence, and sandboxing yourself, start with a framework. Either way, MCP should be your tool transport layer — it is the shared substrate that both speak.
—
## Conclusion
The confusion between harness, framework, and MCP is understandable — they overlap at the edges and are often discussed in the same breath. But they are fundamentally different things. The harness is the engine. The framework is the toolkit. MCP is the language they both speak.
Recognizing which layer owns which responsibility prevents architectural mistakes: trying to enforce permissions at the protocol level, expecting MCP to manage state, or building an entire execution loop from scratch when a harness already provides one. The emerging pattern — a framework orchestrating the outer graph, a harness running each heavy step in its own sandbox, and MCP carrying every tool call — reflects a healthy separation of concerns.
Choose your layers deliberately. Each one does a specific job, and the best agent architectures use all three.
Thank you for reading
