Agent Harness

An agent harness is the software wrapped around a language model that actually runs the agent loop: dispatching tool calls, persisting memory and state between steps, retrying failures, verifying results, and deciding when to stop. The model proposes an action; the harness executes it, decides how to represent the result, records what happened, and chooses whether to go around again.

Four responsibilities do most of the work. Tool dispatch turns a model's structured call into a real execution and turns the result back into context, which is where the format and truncation decisions live. State and memory carry what the agent has already tried, so step twelve does not repeat step three. Error handling decides which failures are retried, which are re-planned around, and which end the task. Termination enforces a step budget, a cost ceiling, or a success check, and is the difference between an agent that gives up cleanly and one that burns tokens in a loop. Firecrawl published a definitional post on the term in 2026 that frames it the same way, as the layer managing tool execution, memory, state persistence and verification.

The practical claim behind the term is that harness quality, rather than model choice, accounts for most of the gap between two agents built on the same model. This is a statement about where the design surface is, not a benchmark result. But the reasoning is easy to follow: the model sees only what the harness puts in its context, so a harness that truncates a 200KB page dump at the head loses the answer that was in the middle, one that returns a raw stack trace spends the next two turns confusing the model, and one that surfaces a 429 as task failure rather than backing off turns a transient error into a wrong answer. None of those are model problems, and a stronger model does not fix them.

This is also why browser and web-data tools are consumed through a harness rather than called directly. A raw browser session is not a tool a model can use well: someone has to decide how a page is represented as an observation (accessibility tree, DOM snapshot, screenshot, extracted markdown), how much of it fits in context, when a session is reset or discarded, and what happens on a navigation timeout. Browser Use and Stagehand are largely that decision set made for you, expressed as natural-language actions over a page. Steel.dev and Browserbase own the session lifecycle underneath, which is the state-persistence half of the same problem. When you evaluate a browser infrastructure vendor for an agent product, a large share of what you are actually evaluating is its harness defaults.

One clarification, since the terms are often used interchangeably: MCP standardises how a tool is described and connected, not how the loop is run. A well-designed MCP server tells the model what a tool does and returns a well-shaped result. Everything about retries, budgets, memory and stopping is still the harness's job, and it is still yours to get right.