Harness engineering is the work of building everything around a coding agent's model so it produces correct changes with less supervision. The model writes the code. The harness decides what it can see and which tools it can call, and it catches mistakes with tests and linters before a human reads the diff.
What Is Harness Engineering?
Birgitta Böckeler's article on martinfowler.com defines the harness as everything in an AI agent except the model itself. For coding agents she separates two layers. The inner harness ships with the tool, such as the system prompt and the code retrieval mechanism of Claude Code or Codex. The outer harness is what a team adds for its own codebase.
OpenAI's February 2026 post made the term common. A small team built an internal beta product where Codex wrote every line, including tests, CI configuration, and documentation. After five months the repository held about a million lines and roughly 1,500 merged pull requests. Three engineers drove it at first, averaging 3.5 merged PRs per engineer per day, and throughput rose as the team grew to seven.
If a change to the agent's environment makes the next task more likely to succeed without a human stepping in, it is harness engineering.
Harness Engineering vs Prompt Engineering vs Context Engineering
The three terms nest. Each covers more of the system than the one before it.
| Discipline | What it controls | Typical artifact |
|---|---|---|
| Prompt engineering | The wording of one instruction | A system prompt |
| Context engineering | What the model sees on each call | Retrieval, compaction, and file selection rules |
| Harness engineering | The whole environment around the model across many calls | AGENTS.md, skills, tools, subagents, tests, linters, CI |
For the middle layer in depth, see context engineering and context rot.
Harness Engineering Controls: Guides and Sensors
Böckeler sorts harness controls by direction. Guides are feedforward. They steer the agent before it acts and raise the odds of a good first attempt. Sensors are feedback. They observe the result and let the agent correct itself. A harness with only sensors repeats the same mistakes, and one with only guides never learns whether its rules worked.
Each control is also either computational or inferential. Computational controls are deterministic programs that run in milliseconds to seconds. Inferential controls use a model, so they cost more and vary between runs.
| Control | Direction | Type | Implementation |
|---|---|---|---|
| Coding conventions | Feedforward | Inferential | AGENTS.md, skills |
| Project bootstrap | Feedforward | Both | A skill plus a bootstrap script |
| Code mods | Feedforward | Computational | A tool with OpenRewrite recipes |
| Structural tests | Feedback | Computational | A hook running ArchUnit module-boundary checks |
| Review instructions | Feedback | Inferential | Skills |
Sensors work best when their output is written for the model. A linter message that says how to fix the violation turns every failed check into an instruction.
OpenAI's Harness Engineering Lessons
Early progress on OpenAI's project was slow because the environment was underspecified, not because Codex lacked ability. The fixes were changes to the repository and tooling.
- AGENTS.md as a map. One large instruction file failed. The team kept AGENTS.md to roughly 100 lines that point into a structured docs/ directory, which acts as the system of record.
- Docs enforced by CI. Linters and CI jobs check that the knowledge base is current and cross-linked. A recurring doc-gardening agent flags stale pages.
- A bootable app per worktree. Codex can launch one instance of the application per change and drive it through the Chrome DevTools Protocol.
- Observability the agent can query. Each worktree gets an ephemeral stack of logs, metrics, and traces that Codex reads directly.
- Agent-to-agent review. Codex reviews its own change, requests other agent reviews, and iterates until they pass. Human review became optional.
Anthropic's Planner, Generator, Evaluator Harness
Anthropic's March 24, 2026 engineering post on harness design for long-running apps names two failure modes. Models lose coherence as the context window fills, and some show context anxiety by wrapping up early near their limit. Agents also grade their own work too generously.
Its answer was a three-agent harness with a planner, a generator, and an evaluator. The evaluator is a separate agent with the Playwright MCP, so it clicks through the live app before scoring it. Between sessions the harness resets context with a structured handoff instead of only compacting. Anthropic found compaction alone was not enough for Claude Sonnet 4.5 on long tasks.
Splitting work across agents is the same move covered in subagents. For the tradeoff between resets and summaries, see context compaction.
Where a Coding Agent Harness Spends Its Time
Cognition measured 60% of a coding agent's time going to search. Every file the main model reads to find the right one stays in its context for the rest of the task. The cheapest harness change is to move high-volume, low-judgment steps to fast specialized models and return only the result.
| Harness step | Cost when the main model does it | Offload |
|---|---|---|
| Code search | File reads pile up in context | WarpGrep subagent returns only the relevant files and lines |
| Applying edits | Full-file rewrites burn output tokens | Fast Apply merges a lazy edit snippet at 10,500+ tok/s |
| Long sessions | Context rot as the window fills | Compact removes 50-70% of context at 33,000 tok/s, keeping surviving sentences verbatim |
Our notes from taking more than forty harnesses apart are in lessons from 40+ coding agent harnesses.
Harness Engineering Checklist
- Keep AGENTS.md short and make it point to deeper docs.
- Make every check runnable by the agent, and write its failure messages as fix instructions.
- Run fast computational sensors (types, lint, unit tests) on every change, and save inferential review for the end.
- Give the agent a way to run and inspect the app it is changing.
- Use a separate agent to evaluate work, not the one that produced it.
- Move search, edit application, and compaction out of the main model's context.
- When the agent fails, add the missing capability to the environment before rewording the prompt.
Frequently Asked Questions
What is harness engineering?
The work of building everything around a coding agent's model so it produces correct changes with less supervision. Agent = Model + Harness.
Who coined harness engineering?
OpenAI popularized it in a February 11, 2026 post by Ryan Lopopolo about building a product with Codex and no manually written code.
How is harness engineering different from context engineering?
Context engineering decides what the model sees on a call. Harness engineering also covers tools, feedback loops, subagents, and the repository itself.
What are guides and sensors?
Guides steer the agent before it acts. Sensors check the result after it acts so the agent can correct itself.
What does a harness spend most of its time on?
Search, at 60% of agent time in Cognition's measurement.
The fastest endpoints are private deployments
Morph's top speeds come from dedicated deployments, not shared public endpoints: speculators trained on your traffic, caching tuned to your workload, and volume discounts over public per-token rates. Over 500 billion tokens per day run this way.
Add search, apply, and compaction to your harness
WarpGrep, Fast Apply, and Compact run as subagents behind one OpenAI-compatible API, so the main model keeps a clean context.