Before You Pay for a Bigger Model, Audit the Harness Around It

Two teams ran the same model on the same coding benchmark. One finished 63 percent of tasks, the other 76. The only difference was the software wrapped around the model, and that gap is usually bigger than a model upgrade would buy you.

The result that reset my priorities was a leaderboard, not a paper. Two setups ran the same model on the same coding benchmark, and one completed 63 percent of the tasks while the other hit 76. Same weights, same problems. The only thing that differed was the harness: how it managed context, which tools it exposed, and how its loop decided when to stop.

That wrapper is the agent harness, and holding the model fixed and changing only the harness moves the score by roughly 7 to 26 points in the studies I have read, which is frequently more than the jump between one model generation and the next. The practical takeaway I now start every build with: before reaching for a bigger, more expensive model, audit the harness architecture you already have, since a harness change ships faster and reverses more easily than a model migration.

One honest caveat up front. You will see this framed as “70 percent of performance lives outside the model.” Treat that as a memorable shorthand, not a measured statistic, because no study I know reports a clean 70–30 split. What the research does show is a set of large, repeatable swings the harness drives with the model held constant, and those are real.

What the harness actually is

The agent harness is everything that wraps the 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, and the harness turns those tokens into finished work.

A 2026 survey of 70 public agent systems found that harness design keeps returning to the same five dimensions regardless of framework or language, which is what convinced me this is architecture rather than one team’s stack. Each dimension is a design decision with trade-offs, and the decisions interact: a memory strategy changes what the tools return, and a permission model changes how the loop retries. The same survey found a telling gap, that careful context strategies are common while high-assurance safety and audit are rare, so teams invest in the visible parts of the harness and skip the boring ones.

The five dimensions, at a glance:

Dimension What it controls Example decision Subagent orchestration How work is split across agents One planner plus workers, or a single loop Context management What the model sees each turn Compaction, retrieval, and memory windows Tool design The action surface Tool granularity, schemas, and error feedback Safety and permissions What the agent may do Approval gates, validators, and sandboxing Loop orchestration When to act, retry, or stop Stopping rules, retry policy, and planning

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.

• On the Terminal-Bench 2.0 leaderboard, one frontier model ranges from about 63 to 76 percent across eight harnesses, a 13-point gap from harness choice alone. The top harness earns part of its lead by snapshotting the sandbox and injecting it into the first prompt, which saves several early exploration turns.
• A separate study evolved a coding-agent harness over ten iterations and lifted pass@1 from about 70 to 77 percent, beating a human-designed harness, and the same evolved design carried 5-to-10-point gains across three other model families, so the effect travels with the architecture rather than one lucky model.
• Endor Labs pushed the swing further: in its security-league benchmark a model scored about 62 percent on functional correctness under its native harness and 87 percent under another, a 26-point jump.
• A trajectory study spanning several thousand runs concluded that agent capability should be reported for a model-and-harness pair, not for a model alone.

The pattern across all four: the harness is rarely the smaller factor.

Subagent orchestration

This dimension 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, at the cost of 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. One well-known long-running-app harness borrows a structure from adversarial training: a planner writes a spec, a generator implements it, and a separate evaluator judges the result. The important detail is the separation, because an agent grading its own work tends to go easy on itself, especially on subjective tasks, and an independent evaluator catches what the generator misses. That is what turns extra agents into extra checks rather than just extra cost.

Context management

This 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, and it is what turns a large context window from a liability back into an asset.

Research on context rot tested 18 frontier models and found every one gets less reliable as input length rises, even on simple tasks, and 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. A team building long-running agents hit the same wall and described context anxiety, where a model degrades as it nears a perceived limit, and 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 harness that manages context well can beat a stronger model paired with a naive one, and it is exactly the dimension that stays invisible in a demo and turns decisive on a real multi-hour task.

Tool design

Tool design is the set of actions you expose to the model and how you describe them, and granularity, clear schemas, and useful error messages decide whether the agent recovers from a mistake or repeats it. Every tool is a contract. A vague schema invites malformed calls, a tool that fails silently gives the loop nothing to correct against, and a tool that returns a specific error, a missing argument or the name of a failing test, lets the agent fix its next call without a human.

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, while many narrow tools are easier to call correctly and crowd the context and slow tool selection, so the right split depends on the task. Efficiency follows too: in one study an evolved harness reached top success on a verified coding benchmark while using 12 percent 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

Permission gates, validators, and sandboxes get treated as afterthoughts, and the survey of 70 systems found basic isolation common while high-assurance audit is rare, so this is where most harnesses are weakest. The real decisions here are 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 rarely show up in benchmark scores, which is why teams skip them, and they matter most when an agent runs unattended.

The part I underrated for too long is that skipping this dimension caps reliability, not just security, 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.

Loop orchestration

Loop orchestration is the control logic that decides when the agent takes another action, retries a failed one, or stops, covering stopping criteria, retry policy, and re-planning. Both failure modes are expensive. A loop that stops too early hands back work a few more turns would have finished, and 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, and a loop that retries the same call against the same silent error just wastes turns. That coupling is the reason loop orchestration gets tuned alongside the other dimensions rather than bolted on at the end.

The dimensions compound, which is 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. 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, and a careful permission model only slows the agent down unless the tools give feedback the loop can act on.

The common mistake, and the one I have made, is spending the whole budget on the model. A model upgrade is a single expensive lever, and the evidence says the harness can match or beat its swing, while context management and tool design are cheaper to change and often move the number more. They get less attention because they feel like plumbing.

What I would do first

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.

If you have run the same model under two harnesses, I would like to know which dimension moved your number most. For me it was context management, the full reset with a handoff artifact beating in-place compaction on every long task I have measured.