The harness is the king now

For two years the industry's first question about any AI system was "which model?". Every quarter a new release moved the leaderboards, every vendor deck opened with a benchmark, and every architecture review began with a model name. That question is now the wrong one to ask first. The evidence from 2026 is consistent and, once seen, hard to unsee: for the work that matters in production, the harness around the model explains more of the outcome than the model does.

This is an attempt to lay that argument out properly: what a harness is, what the evidence says, why it is happening, what a good harness is made of, and what follows for anyone deciding how to build or buy AI systems.

The claim, stated plainly

An agent is a model plus a harness. The model reasons. The harness does everything else: it decides what the model sees at each step, which tools exist and how they are described, what happens to a tool result, when to stop, when to retry, what to verify, what to remember across sessions, what the model is allowed to do, and what gets logged. Benchmarks, until recently, reported one number against the model's name and let the harness disappear into a footnote.

The claim is that this attribution is backwards. Hold the model constant and vary the harness, and the score moves more than it does when you hold the harness constant and vary the model. For long, tool-heavy, stateful work, the harness is the binding constraint.

The evidence

The clearest data comes from coding and terminal agents, because they are the most measured.

For comparison, the gap between adjacent frontier model generations on the same benchmark, in the same harness, is usually in the single digits. A harness change routinely produces a bigger swing than a model upgrade.

The research community has caught up with the practitioners. A May 2026 position paper, Stop Comparing LLM Agents Without Disclosing the Harness, formalises what it calls the Binding Constraint Thesis: for long-horizon tasks across models of comparable frontier capability, performance variance is governed more by harness configuration than by model choice, to the point of reversing model rankings. Its proposed remedy is a disclosure standard, "Harness Cards", and a variance decomposition so that a reported score can be attributed to the system that produced it.⁴ Harness-Bench, published the same month, ran 5,194 execution trajectories across 106 sandboxed tasks and concluded that agent performance should be "reported at the model-harness configuration level rather than attributed to the base model alone".⁵

The vendors have said the same thing with their actions. OpenAI's Codex team described its practice as "harness engineering" in February 2026, reporting roughly a million lines of code shipped by a small team in five months with no hand-written source, held together by documentation that agents treat as the source of truth, linters that enforce it, and structural tests that enforce architectural layers.⁶ In August 2026 OpenAI open-sourced the Codex harness itself, describing it as the most valuable reusable asset in the product.⁷ Anthropic published a design guide for harnesses in April 2026 and, before that, a study of harnesses for agents that run across many context windows.^{8 9}

Harness engineering includes context engineering, architectural constraints, and garbage collection. Martin Fowler, on OpenAI's framing of the discipline⁶

Why this is happening

Three forces, and none of them is temporary.

Frontier models have converged on well-specified tasks. For a task the model can hold in one context window with a clear success criterion, the top handful of models are within noise of each other. Differentiation has moved to tasks that are long, ambiguous, tool-heavy and stateful, and those are exactly the tasks where the harness does the work.

Long-horizon work is a control problem. The position paper's framing is the right one: the harness is the controller of a closed loop and the model is a stochastic policy inside it. Small changes to the controller, such as when to reset context, what to carry across a reset, and how to verify before declaring done, change the trajectory more than swapping the policy. Anthropic's account of building long-running agents reads as a list of controller fixes: an initialiser agent that writes a feature list and a progress file, a coding agent that reads them and the git log before starting, mandatory end-to-end checks before a feature is marked complete, and context resets with a structured hand-off to a fresh instance, introduced because the model started wrapping up early as its window filled.⁸

The failures that hurt in production are outside the model. Harness-Bench's recurring failure pattern is that "plausible reasoning becomes decoupled from tool feedback, workspace state, evidence, or verifiable output contracts".⁵ That is not a reasoning failure. It is the absence of a harness that checks outputs against a contract, feeds tool results back honestly, and refuses to accept a confident answer without evidence.

Anatomy of a harness

Eight components, each answering a question that the model cannot answer for itself. A team that can describe all eight for its system without opening a model vendor's documentation understands what it has built. A team that cannot has built a demo.

1. Context construction. What the model sees at each step, in what order, and what is deliberately left out. Anthropic's guidance to put static content first and dynamic content last is not a style point; it is the difference between a 10% cache-read price and full price on every call.⁹
2. Tool design. Few, general, well-described tools beat many narrow ones, because the model has already learned the general ones. Claude 3.5 Sonnet reached 49% on SWE-bench Verified with nothing but bash and a text editor.⁹
3. Loop control. When the agent stops, retries, re-plans or asks, and whether the model or a check decides that a task is done.
4. Verification. What is checked mechanically before an output is accepted: a schema, a test, a diff against a baseline, a second model as judge.
5. Memory and hand-off. What survives a context reset or a session boundary, and in what form: files, structured records, a git history, a progress note.
6. Permissions and boundaries. Which actions are promoted to typed tools the harness can intercept, gate, render and audit, and which run through a general executor. This is where security and cost limits live.⁹
7. Observability and evaluation. Whether every step is logged with cost, latency and outcome, and whether a held-out task set runs on every change to the harness, not only on every new model.
8. Cost shaping. Whether context is built for caching and tool results are filtered by code before they reach the model. The best recent harness advice is subtractive: give the model a code-execution tool and let it decide what to filter, pipe or pass through, rather than routing every result through its context window.⁹

What follows

If the harness carries the outcome, several long-held assumptions about building with AI need revising.

Evaluation

A model benchmark is evidence about the harness that produced it. A vendor's number describes the vendor's product, not the model. The papers' recommendation is the right standard for any serious buyer or builder: results reported per model-and-harness pair, a fixed task set from the actual domain, run on every harness change, with trajectory-level metrics that show recovery, drift and control lag rather than a single pass rate.⁴

Ownership

The harness is where domain knowledge lives. The model knows English and code; the harness knows that a certificate number must be transcribed exactly, that a Port State Control code is never guessed, that a reply is drafted but never sent. That knowledge is the product. Renting the model is sensible. Renting the harness is renting the product.

Cost

The harness sets the token bill. Context rebuilt every turn instead of cached, tool results dumped into the window instead of filtered by code, retries without back-off: each is a multiplier on inference cost. On one of Sea-Squad's own workloads the difference between a naive and a disciplined context strategy on the same model was a factor of roughly twenty, almost all of it from cache hits and shorter prompts. Before negotiating a model price, fix the harness.

Portability and sovereignty

When the harness is yours and the model sits behind a standard inference API, changing the model is a configuration change plus an evaluation run. That is what makes a localised, open-weight deployment practical: the harness carries the behaviour, so a 27-billion-parameter model on a GPU inside a client's environment can meet or beat a hosted frontier model on the tasks that matter, because the harness is doing the parts the frontier model was being paid for. The sovereignty and cost case is set out separately.¹¹ The point here is that harness ownership is its precondition.

Vendor risk

Lock-in is moving. A model can be swapped in an afternoon; a harness an operation has grown around cannot. Open-source harnesses (OpenAI's Codex harness is now one) change the calculus, and a proprietary harness that cannot be inspected is a heavier dependency than any model contract.

Teams

The scarce skill is no longer prompt writing. It is the engineer who can design a control loop, write the verification, instrument it, and read a trajectory log to see where an agent drifted. That is the person to hire and to promote.

What this looks like in practice

Sea-Squad's agents run a ship-management office's email, documents, certificates and inspections, so the harness had to be right before the model mattered. A few concrete choices, because the principle is only useful in the specific:

• Every model output is a contract. Email analysis returns a fixed schema: category, priority, action, summary, vessel link with confidence. The harness validates it, and a missing field is a failure even when the HTTP call succeeded. That check is how a cheaper model was caught silently dropping a field while returning two hundred successful responses an hour. The model looked healthy; the harness said otherwise.
• Verification before adoption. No model change carries traffic until it has run a held-out set with known answers and been compared field by field against the incumbent. A 27B open-weight model went into email analysis this way and matched the hosted baseline on nine of ten categories while catching four vessel codes the baseline had missed. That result was produced by the evaluation harness as much as by the model.
• The harness owns the boundaries. Reply drafts are a tool exposed on request, never a default behaviour. Documents are read by a lane the scheduler places behind interactive work. Outbound network access is an allow-list. Every call lands in a usage ledger with cost, latency and outcome.
• Hand-offs are files. Long document jobs stamp progress on the data itself, so a session that stops at two in the morning resumes without any memory of what happened before. The one bug that cost coverage was a work-list predicate that skipped partially processed documents. It was a harness bug, and fixing it was a harness fix.

None of this required the largest model available. All of it required treating the harness as the product.

Questions worth asking of any AI system

1. Can the team describe the harness in the eight components above, without the model vendor's documentation?
2. Is there a held-out task set from the real domain that runs on every harness change?
3. Is every model output validated against a contract before it is used?
4. Is context built for caching, with static content first?
5. Are high-risk actions promoted to typed tools that can be gated and audited?
6. What survives a context reset, and has a cold resume been tested?
7. Can the model behind the harness be swapped with a configuration change and an evaluation run?
8. Is every call logged with cost, latency and outcome, and does someone read the trajectories that fail?

The next twelve months

Three predictions, held loosely. Benchmarks will publish harness disclosures as a matter of course, because the papers have made the omission embarrassing. The best harnesses will get simpler, not more elaborate, as models take over orchestration decisions that harnesses used to hard-code; the advice to ask what a harness can stop doing is the right instinct. And the companies that win in vertical AI will be the ones whose harness encodes how their industry actually works, running whichever model is best that quarter, in whichever environment the client requires.

The model is the engine. The harness is the ship. Nobody has ever asked which engine a vessel had before asking whether it arrived.

References

1. Cursor's harness comparison as reported in MindStudio, "What is the agent harness? Why scaffolding matters more than the model" (May 2026): the same Claude model scored 46% on one harness and 80% on another. mindstudio.ai/blog/agent-harness-scaffolding-matters-more-than-model ↩
2. Terminal-Bench 2.0 leaderboard analysis: Claude Opus 4.6 between 58.0% and 74.7% across seven harnesses. futureagi.com/blog/coding-agent-harness-benchmark ↩
3. Terminal-Bench 2.0 and 2.1 results by harness: Letta Code 59.1% vs Claude Code 41.6% on Claude Opus 4.5; Codex CLI 83.4% vs Terminus 2 76.4% on GPT-5.5. codex.danielvaughan.com, June 2026; snorkel.ai/leaderboard/terminal-bench-2-1 ↩
4. Zhang, Xu, Wang, Hamm, Ge and Reddy, "Stop Comparing LLM Agents Without Disclosing the Harness", arXiv 2605.23950, May 2026. arxiv.org/abs/2605.23950 ↩
5. Yao et al., "Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows", arXiv 2605.27922, May 2026. arxiv.org/abs/2605.27922 ↩
6. InfoQ, "OpenAI introduces harness engineering: Codex agents power large-scale software development", 21 February 2026, including Martin Fowler's comment. infoq.com/news/2026/02/openai-harness-engineering-codex ↩
7. OpenAI, "Unlocking the Codex harness: how we built the App Server" (2026), and coverage of the August 2026 open-sourcing of the Codex harness. openai.com/index/unlocking-the-codex-harness ↩
8. Anthropic, "Effective harnesses for long-running agents", 26 November 2025. anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩
9. Anthropic, "Agent harness design: 3 patterns for harnessing Claude's intelligence", 2 April 2026. claude.com/blog/harnessing-claudes-intelligence ↩
10. Faros, "Harness engineering: a guide to AI coding agents" (2026). faros.ai/blog/harness-engineering ↩
11. Sea-Squad, "Sovereign AI for Ship Management", white paper, September 2026. seasquad.ai/whitepaper ↩