Harness engineering is the discipline of designing, testing and improving everything around an AI model that makes an agent reliable: its instructions, tools, context, checks, permissions and logs. Instead of writing the code yourself, you build the environment in which agents write it, and you tighten that environment every time an agent makes a mistake.
The term went from almost nothing to one of the most searched phrases in AI engineering in a few months of 2026. This article explains where it came from, how it relates to prompt and context engineering, which practices make it work and where its limits are. For the basics of what a harness is, start with our guide What is an AI harness?
Where the term harness engineering comes from
The idea that an agent is a model plus scaffolding is older. What changed in early 2026 is that teams started to treat that scaffolding as the main product of their work.
On 11 February 2026, OpenAI’s Ryan Lopopolo published Harness engineering: leveraging Codex in an agent-first world. It described a five-month internal experiment in which a small team built a product used daily inside OpenAI, with a repository of roughly a million lines of code and, by their account, no lines written by hand. The engineers’ job shifted to making the agents effective: breaking goals into small tasks, writing down how the codebase works and building the checks that kept the agents on track.
Around the same time, Mitchell Hashimoto wrote about the term, LangChain published its anatomy of an agent harness, and on 2 April 2026 Birgitta Böckeler of Thoughtworks published a widely read framework on martinfowler.com. Who coined it first is disputed. What is clear is that by spring 2026 the phrase had stuck.
Prompt engineering, context engineering, harness engineering
The three terms describe a widening circle of work around the model.
| Discipline | Question it answers | Typical work |
|---|---|---|
| Prompt engineering | How do I phrase this request? | Writing and testing instructions for one call |
| Context engineering | What should the model see? | Selecting, ordering and compacting instructions, files, memory and retrieved knowledge |
| Harness engineering | What system makes the agent reliable over many steps? | Designing the loop, tools, sandbox, checks, evaluations and logs, and improving them from failures |
Each step contains the previous one. A good harness still needs good prompts and good context, but it adds the parts that let an agent work for hours without a human checking every move. Loop engineering is the part of harness engineering that focuses on how the agent iterates and when it stops.
The core model: guides and sensors
Böckeler’s framework is the most practical way to think about harness engineering. Every control in a harness is either a guide or a sensor.
- Guides act before the agent does: instruction files, coding conventions, templates, skills and examples. They aim for a good first attempt.
- Sensors act after the agent does: tests, linters, type checks, structural rules, a reviewer. They tell the agent what went wrong so it can correct itself.
You need both. With only sensors, the agent keeps making the same mistakes and gets corrected every time. With only guides, you never find out whether your rules work.
Each control can also be computational or inferential. Computational controls are deterministic, fast and cheap: a test passes or it does not. Inferential controls use a model’s judgement, such as an AI code review or an LLM acting as a judge. They catch more subtle problems but are slower, more expensive and less predictable.
| Computational | Inferential | |
|---|---|---|
| Guide (before) | Code mods, templates, generators | Conventions in AGENTS.md, skills, examples |
| Sensor (after) | Tests, linters, type checks, architecture rules in a pre-commit hook | AI code review, LLM-as-judge, review instructions as a skill |
Eight practices that make harness engineering work
- Make the repository the system of record. Everything the agent needs to know about how the system works should live in files it can read, not in people’s heads or chat threads.
- Break work into small, checkable tasks. Agents do well on tasks with a clear definition of done. Large goals become a chain of small ones.
- Put cheap, deterministic checks first. Run linters, type checks and fast tests on every change. Keep expensive checks, such as mutation testing or an LLM review, for later in the pipeline.
- Write sensor messages for the agent. An error message that says what is wrong and how to fix it lets the agent correct itself without a human.
- Test behaviour, not wording. Google’s developer team recommends behavioural evaluations that check observable steps, such as whether the agent searched the web before answering a question about live data, or ran a validator before declaring a build finished. Start with one recurring failure, keep the suite fast (their local suite runs in under five seconds) and track pass rates over batches instead of single runs.
- Tighten the harness after every slip. Each time an agent makes a mistake, ask which guide or sensor would have prevented it, and add it.
- Bound what the agent can touch. Sandboxes, scoped permissions and human approval for risky actions are part of the harness, not an afterthought.
- Log everything and keep it. Full traces make agents debuggable, and they are the raw material for automatic improvement.
Letting AI do the harness engineering
If harness engineering is about improving the environment from failures, an agent can do part of that work too. Meta-Harness from Stanford lets a coding agent rewrite a harness after reading the raw logs of earlier attempts. Google’s Harness² proposes changes to prompts, memory, skills and tool guidance, tests them against each other and keeps what wins, per task. Google’s developer team describes a smaller version of the same idea: an LLM adjusts a system prompt until a failing behavioural test passes, while the rest of the suite guards against regressions.
These methods do not replace human judgement, but they change its role. People decide what good looks like and write the tests; the loop does the tuning.
The limits of harness engineering
Harness engineering is not a guarantee. Böckeler is clear about what sensors cannot catch: a misdiagnosed problem, an over-engineered solution or an instruction the agent misunderstood. Behaviour is the hardest thing to harness, and AI-generated tests are not yet trustworthy enough to be the only safety net. Legacy codebases, which need it most, are also the hardest to harness.
The OpenAI experiment deserves the same care. It is a single, self-reported case from a company that sells the agent, on a new product without legacy code. It shows what is possible, not what every team should expect.
Harness engineering beyond code
The term was born in software development, but the method applies wherever agents do repeated work. A marketing team that writes its tone of voice, approval rules and channel checks into the agent’s environment is doing harness engineering. So is a finance team that adds a validation step before an agent posts a report. The questions stay the same: what should the agent know before it acts, how do we check its work, what may it touch, and what do we learn from each mistake. Our guide to AI harnesses covers these company harnesses in more detail.
Frequently asked questions about harness engineering
What is harness engineering in simple words?
It is building and improving the working environment of an AI agent, so that it does good work on its own. You spend less time doing the task and more time on the rules, tools and checks the agent works with.
Is harness engineering the same as prompt engineering?
No. Prompt engineering is about the wording of a request. Harness engineering covers the whole system around the model: context, tools, sandbox, checks, evaluations and logs, over many steps.
What is an example of harness engineering?
Adding an architecture test to a pre-commit hook after an agent broke a module boundary is harness engineering. So is writing your team’s conventions into an AGENTS.md file, or adding a behavioural test that checks the agent ran the validator before calling a task done.
Is Claude Code harness engineering?
Claude Code is a harness: Anthropic engineered the inner layer. When you add your own instruction files, skills, hooks and MCP servers on top, you are doing harness engineering on the outer layer.
Do you need to be a developer to do harness engineering?
For coding agents, mostly yes. For agents in marketing, sales or operations, the work is closer to writing clear procedures and checks, which domain experts often do better than developers.
Dit artikel is ook in het Nederlands beschikbaar op artificial-intelligence.be: wat is harness engineering?
Sources: OpenAI, Harness engineering (11 February 2026); Birgitta Böckeler, Harness engineering for coding agent users (2 April 2026); Google Developers Blog, The anatomy of harness engineering (9 September 2026); LangChain, The anatomy of an agent harness.
