What is harness engineering for AI agents?

Harness engineering is the work of building everything around an AI model that turns it into a working agent. That means the instructions it reads, the tools it can call, the sandbox it runs in, the checks that tell it whether it is finished, and the rules for what happens when it is not. LangChain reduces it to a formula, agent equals model plus harness. The term matters because changing the harness alone, with the same model, has moved benchmark scores by more than ten points. For most teams the harness is the part they can actually change.

Where did the term come from?

Nobody claims to have coined it, and the dated record runs over about four months.

Anthropic used "harness" in November 2025 in a post on long-running agents. It described an initialiser agent that writes a feature list with every item marked failing, a progress file, and a first commit. A second agent then completes one feature per session. In February 2026 Mitchell Hashimoto made "engineer the harness" a step in his account of adopting AI. His version is simple: each time an agent gets something wrong, change its instructions or give it a tool so that "the agent never makes that mistake again". Six days later OpenAI published Harness engineering, the post most people credit with spreading the term. It describes a product of about a million lines built over five months, with no code written by hand.

By April, Birgitta Böckeler at Thoughtworks had written the longest treatment on Martin Fowler's site. She calls it a form of context engineering.

What is in a harness?

Böckeler's split is the most useful one. A harness has guides, which shape what the agent does before it acts, and sensors, which tell it what happened after.

• Guides are the instructions and conventions: an AGENTS.md file, reusable skills, coding conventions, how-to documents, and the tools the agent is allowed to call.
• Sensors are the feedback: linters, type checkers, test suites, structural tests, runtime logs and review by a second model.

Each can be deterministic, like a test that passes or fails, or judged by a model. The deterministic ones are cheaper and harder to argue with, so a good harness uses them wherever it can.

How is it different from prompt and context engineering?

Prompt engineering is writing the instruction. Context engineering is choosing everything the model sees on a given turn. Harness engineering is the system that runs across many turns: which tools exist, what gets checked, what is written down between sessions, and when the run stops. A prompt can ask an agent to test its work. A harness runs the tests whether the agent remembers to or not.

That distinction is why the topic grew. As agents run longer, a single prompt covers a smaller share of what decides the result. That argument is made at more length in why agent failures are context failures.

How much difference does the harness make?

Enough that "which model?" is often the second question.

LangChain held its model fixed and changed only the harness. Its coding agent went from 52.8% to 66.5% on Terminal Bench 2.0. The changes were a self-verification step, a checklist before declaring completion, detection of loops, and a varied reasoning budget. A separate experiment changed only the format of the edit tool across many models. One of them went from 6.7% to 68.3% on the same edits.

A harness costs money too. Anthropic's March 2026 write-up compared one agent working alone for 20 minutes at about $9 with a planner, builder and evaluator harness that ran for six hours at about $200. The harnessed output was far better. Whether it is twenty times better depends on the work.

What should the checks look like?

The teams running coding agents at scale have reached the same answer separately.

Something other than the model runs the checks. Spotify's background agent calls verifiers for formatting, build and tests without knowing how they work, and a hook runs them before any pull request opens. Stripe's Minions mix agent steps with deterministic ones that do not call a model at all, such as lint and push.

The agent sees only what failed. Spotify filters verifier output down to the relevant errors and returns a short line on success. Every line handed back is read again on every later turn, so a full log is expensive noise.

Retries are bounded. Stripe allows one local fix attempt and at most two CI rounds, then hands the branch to a person. A loop without a limit is a loop that can spend money indefinitely on a task it cannot finish.

The judge is not the worker. Anthropic found that agents reliably skew positive when grading their own work, and separated the agent doing the work from the one evaluating it. Spotify's judge model vetoes about a quarter of sessions.

Where does the harness stop?

At the edge of the run. A harness makes an agent more likely to finish correctly. It does not decide whether the work is accepted, and it cannot be the record of what happened, because it runs beside the agent and is configured by the same people.

That second job belongs to whatever sits around the task: a definition of done written before the work starts, proof attached when it ends, and a reviewer that did not do the work. Böckeler makes a related point. In her account a good harness does not aim to remove people. It aims to put their attention where it counts.

Cognibl's Harness flow is built on these rules. A repository declares its own checks under Settings, at most eight commands. When a cloud agent says it is finished, the harness runs them in the agent's own checkout and hands back only the failing lines, at most twice. The checks are not the gate. A repository that was already failing stays workable, and the agent is told to report a failure it did not cause instead of fixing it. The gate is the proof of work against the definition of done, and a reviewer agent can never review its own work. We have not yet measured how much the checks raise first-pass rates, so we make no claim about it. See the Harness flow and its statuses.