Harness engineering in practice
Designing a harness is the first version. Engineering it is the ongoing work: each failure becomes a change to the system, and you check that the change helped.
What the discipline looks like
Harness engineering treats the agent's mistakes as information about the system. The question shifts from "how do I get a better answer?" to "what does this environment make easy, hard or impossible?"
OpenAI's account of building with Codex in 2026 is the best-known example. Their team used agents to write a large codebase, and reported that the hard part was not the coding but building the environment around the agent: what it could read, how its work was checked, and how mistakes were fed back. The lessons they described are sensible for any team, even at a smaller scale.
The improvement loop
Agent makes a mistake
↓
Trace it: what did the agent see, and what could it do?
↓
Pick the smallest harness change that prevents it
(a clearer instruction, a better tool description, a new check,
a permission, a limit)
↓
Add a binary eval for the failure
↓
Run the evals, compare with last version → keep the change, or revert
↓
(back to the start)The important step is the third one. The fix should go into the harness, not into a one-off correction. A correction helps once. A harness change helps every time.
Four kinds of harness change
1. Say it more clearly
Add a rule to the standing instructions, or make an existing one specific. Example: "Dates are always written as DD Month YYYY" in place of "use a sensible format".
2. Make the right tool obvious
Rewrite a tool description so the agent picks the right one first time. Often the failure was not the tool but a confusing name.
3. Add a check
Put a code check or a self-check step before the output is used. Example: run the test suite before the agent says "done"; reject any reply missing a required field.
4. Restrict or limit
Remove a tool, add an approval step, or set a cap on steps or spend. Use this when the mistake is costly and the other three fixes are not enough.
Keep the environment legible
An agent can only use what it can read. Things a human knows but never wrote down are invisible to it:
- Team conventions and naming rules, written in the instruction file.
- Dashboards and logs, made readable through a tool, not only through a screen.
- Decisions made in meetings or chat, copied into a document the agent can search.
- Architecture rules, stated as checks the agent can run (a linter, a test) rather than only as prose.
If you find yourself explaining the same thing to the agent twice, it belongs in the harness.
Sources
- OpenAI: Harness engineering, leveraging Codex in an agent-first world (February 2026)
- The Neuron: OpenAI's harness engineering playbook (secondary summary)
The practices are Human Agency's synthesis of the sources above. The OpenAI account is summarised from secondary coverage; read the original for exact details. For the overview, see Harness Engineering.