Agent Harness Architecture: The 70% of Performance That Lives Outside the Model

Two teams run the same model on the same coding benchmark, Terminal-Bench 2.0. Measured by the share of tasks each agent completes, one scores 63%, the other 76%. The only thing that differs is the software wrapped around the model: how it manages context, which tools it exposes, and how its loop decides when to stop. That wrapper is the agent harness, and its design often moves the score more than a model upgrade would. This guide breaks agent harness architecture into five dimensions and shows the measured evidence behind each one.

Does Architecture Really Beat the Model?

Often, yes. In controlled tests that hold the model fixed and change only the harness, scores swing by roughly 7 to 26 points. That is frequently larger than the jump from one model generation to the next, which makes the harness a first-class performance variable in its own right.

The title says 70%. Treat that as a memorable shorthand for most of it, not a measured statistic. No published study reports a clean 70% split between model and harness, and this article will not pretend one exists. What the research does show is a set of large, repeatable swings driven by the harness with the model held constant.

On the Terminal-Bench 2.0 leaderboard, Claude Opus 4.6 scores anywhere from 62.9 to 76.4% depending only on which harness runs it. Endor Labs measured GPT-5.5 moving from 61.5 to 87.2% on functional correctness when the same model switched harnesses. These gaps trace to agent harness design rather than to new model weights.

The practical consequence is simple. Before you reach for a bigger, more expensive model, look hard at the agent harness architecture you already have, since a harness change usually ships faster and reverses more easily than a model migration.

What Is Agent Harness Architecture?

Agent harness architecture is the design of everything that wraps a model to make it act: how work is split across agents, how context is managed, how tools are shaped, how permissions are enforced, and how the control loop decides when to act or stop. The model generates tokens; the architecture turns those tokens into completed work.

A useful map comes from a 2026 survey, Architectural Design Decisions in AI Agent Harnesses (arXiv 2604.18071), which studied 70 public agent-system projects. It found that harness design keeps returning to the same five dimensions, whatever the framework or language. Because the sample spans many independent projects, the pattern is not an artifact of one team’s stack.

Calling it architecture is deliberate. Each dimension is a design decision with trade-offs, and the decisions interact: a memory strategy changes what your tools return, and a permission model changes how the loop retries. Good agent harness architecture treats these as one system, the way a building’s plumbing and wiring are planned together.

The survey also found a telling gap. Careful context strategies are common, while high-assurance safety and audit are rare. Teams invest in the visible parts of the harness and skip the boring ones. The next section lays out all five dimensions so you can see what a complete architecture covers.

The Five Dimensions of Harness Architecture

Harness architecture breaks into five dimensions: subagent orchestration, context management, tool design, safety and permissions, and loop orchestration. Each controls a different part of how the agent behaves, and most production harnesses combine all five.

The five dimensions of agent harness architecture, after the 2026 survey Architectural Design Decisions in AI Agent Harnesses (arXiv 2604.18071).

Subagent orchestration divides the work, and context management sets what the model sees each turn. Tool design shapes the action surface, while safety and permissions bound what the agent may do. Loop orchestration decides when the agent acts, retries, or stops. Each dimension gets a dedicated section below; the table summarizes all five first.

The Evidence That the Harness Outweighs the Model

Multiple 2026 studies hold the model constant and vary only the harness, and all of them find large swings. The cleanest example is a public leaderboard where one model posts eight different scores under eight different harnesses.

Relative sizes only. Exact swings and their sources are in the table below.

On the Terminal-Bench 2.0 leaderboard, Claude Opus 4.6 ranges from 62.9% under the Terminus 2 framework to 76.4% under Stanford’s Meta-Harness, a 13-point gap from harness choice alone. Meta-Harness earns part of that lead by snapshotting the sandbox and injecting it into the first prompt, which saves several early exploration turns.

A separate study, Agentic Harness Engineering (arXiv 2604.25850), evolved a coding agent harness over ten iterations and lifted Terminal-Bench 2 pass@1 from 69.7 to 77.0%, beating a human-designed harness. The same evolved design carried gains of 5 to 10 points across three other model families, showing the effect travels with the architecture, not one lucky model.

Endor Labs pushed the swing further. In its Agent Security League benchmark, GPT-5.5 scored 61.5% on functional correctness under its native Codex harness and 87.2% under Cursor, a 26-point jump. And Harness-Bench (arXiv 2605.27922), spanning 5,194 execution trajectories, concluded that agent capability should be reported for a model-harness pair rather than for a model alone.

Subagent Orchestration: How Work Is Split Across Agents

Subagent orchestration decides whether one agent handles a task end to end or a planner delegates to specialized workers. A single loop keeps coordination simple and cheap. Splitting the work lets each agent hold a smaller, cleaner context and keeps a failure in one subtask from corrupting the rest. The trade-off is coordination overhead, since more agents mean more prompts, more tokens, and more handoffs that can go wrong.

The higher-value pattern is agents that check each other. Anthropic’s long-running-apps harness borrows a structure from generative adversarial networks: a planner writes a spec, a generator implements it, and a separate evaluator judges the result. The important detail is separation. An agent grading its own work tends to go easy on itself, especially on subjective tasks, so an independent evaluator catches problems the generator misses.

That separation is why orchestration is an architecture decision, not a scaling trick. A planner, worker, and independent evaluator split turns extra agents into extra checks, raising the odds an unattended run finishes correctly rather than confidently wrong.

Context Management: The Dimension That Decides Long Tasks

Context management is usually the dimension that decides a long task, because model quality drops as the input grows. How the harness compacts, retrieves, and resets context often matters more than the model choice does. It is what turns a large context window from a liability back into an asset.

Research from Chroma, known as context rot, tested 18 frontier models and found every one gets less reliable as input length rises, even on simple tasks. The decline sets in while plenty of window remains, so a bigger context budget cannot rescue a task the model has stopped attending to. Window size is a weak proxy for usable context.

Anthropic’s engineering team hit the same wall building long-running agents. In its write-up on harness design for long-running apps, it describes context anxiety, where a model degrades as it nears a perceived limit. The fix that worked was a full context reset with a structured handoff artifact, rather than compacting the running history in place. That choice adds orchestration work and some latency, and it still won on quality.

This is why a coding agent harness that manages context well can beat a stronger model paired with a naive one. The dimension stays invisible in a demo and turns decisive on a real, multi-hour task.

Tool Design: The Action Surface That Shapes Behavior

Tool design is the set of actions you expose to the model and how you describe them. Granularity, clear schemas, and useful error messages decide whether the agent recovers from a mistake or repeats it. It is the dimension teams underrate most after context.

Every tool is a contract. A vague schema invites malformed calls, and a tool that fails silently gives the loop nothing to correct against. A tool that returns a specific error, like a missing argument or the name of a failing test, lets the agent fix its next call without a human. Clear error feedback turns a dead end into a productive retry.

Granularity is a genuine trade-off. A few broad tools keep the prompt small but force the model to pack complex arguments into one call. Many narrow tools are easier to call correctly, yet they crowd the context and slow tool selection. The right split depends on the task, which makes it a design decision rather than a default.

Efficiency follows from tool design too. In the Agentic Harness Engineering study, an evolved harness reached top success on SWE-bench Verified while using 12% fewer tokens, largely by reshaping how the agent called tools and read their results. Cleaner tool use compounds into real cost and speed savings across a long run.

Safety and Permissions: The Dimension Teams Skip

Permission gates, validators, and sandboxes get treated as afterthoughts, yet they shape how reliably an agent finishes. The survey of 70 systems found that basic isolation is common while high-assurance audit is rare, so this is where most harnesses are weakest.

Safety and permissions decide what the agent can touch. Real design decisions here include approval gates before a destructive action like a force-push to a shared branch, validators that check a tool’s output before it is trusted, and sandboxes that contain a bad step. These controls rarely show up in benchmark scores, which is why teams skip them, yet they matter most when an agent runs unattended.

Skipping this dimension risks more than a security incident. It also caps reliability, because an agent that cannot verify its own actions has to redo work or hand it back to a person. Reliability and safety turn out to be the same investment, which is why strong harnesses treat them as core architecture rather than a final gate.

Loop Orchestration: When the Agent Acts, Retries, or Stops

Loop orchestration is the control logic that decides when the agent takes another action, retries a failed one, or stops. The survey treats it as its own dimension, covering stopping criteria, retry policy, and re-planning. It governs how a run actually ends, which is easy to overlook until an agent either quits a solvable task or never stops at all.

Both failure modes are expensive. A loop that stops too early hands back work a few more turns would have finished. A loop with no real stopping rule spins in place, burning tokens and sometimes undoing correct work while it thrashes. Good stopping criteria end a run when progress stalls, not at a fixed turn count.

Retry policy is where the loop leans on the rest of the harness. A retry only helps if the agent gets a concrete signal about what failed, which is why loop design and tool feedback are tied together. A loop that retries the same call against the same silent error just wastes turns. That coupling is why loop orchestration is tuned alongside the other dimensions rather than bolted on at the end.

How the Five Dimensions Interact (and Where Teams Over-Invest)

The five dimensions compound rather than add. A better tool schema makes retries cheaper, which makes the loop safe to run longer, which lets context management pay off. Over-investing in model choice while the harness stays thin leaves the biggest gains on the table.

Because the dimensions interact, tuning one in isolation underdelivers. A retrieval upgrade that hands the model cleaner context is wasted if the loop stops too early to use it. A careful permission model only slows the agent down unless the tools give clear feedback the loop can act on. Strong agent harness architecture tunes them together and measures the whole system.

The common mistake is spending the entire budget on the model. A model upgrade is a single, expensive lever, and the evidence above shows the harness can match or beat its swing. Context management and tool design are cheaper to change and often move the number more, yet they get less attention because they feel like plumbing.

Engineering the Harness, Not Just the Model

Return to the two teams from the opening. They ran the same model on the same benchmark, yet one finished 63% of tasks and the other 76%. Nothing about the model explains the gap. The difference was the harness, the software layer that fed the model context, handed it tools, gated its actions, and decided when its loop should stop.

That layer is five compounding dimensions, not one setting. Subagent orchestration splits the work and lets agents check each other. Context management keeps the model attending to what matters as input grows. Tool design decides whether the agent recovers from a mistake or repeats it. Safety and permissions govern what it can touch unattended. Loop orchestration sets when it acts, retries, or stops. The measured swings, roughly 7 to 26 points with the model held constant, come from these choices rather than from new weights.

A clear order of work follows. Audit the harness before paying for a bigger model, then spend first where the weight sits, on context management and tool design, before tightening safety and loop control. Get the architecture right, and the next model upgrade lands on a foundation ready to use it instead of masking a harness that left most of the performance unclaimed.