Harness engineering
If the model is rented and the harness is yours, then the harness is the thing you are actually building. Here is what it is made of.
The term was defined and popularised by Birgitta Böckeler, a Distinguished Engineer at Thoughtworks, in an April 2026 article on martinfowler.com that updated an earlier internal memoprimary. Independent descriptions of the same emerging discipline appeared across the industry through 2026, which is usually a sign that people were already doing the thing and needed a name for itprimary.
Start from the decomposition: Agent = Model + Harnessprimary, a formulation Böckeler attributes to LangChain’s anatomy of an agent harnessprimary. Everything below is about the second term.
Guides and sensors
Böckeler’s first cut splits harness controls by when they act.
Guides are feedforward controls. They steer the agent before it acts: an AGENTS.md or
CLAUDE.md file, skills, reference docs, codemods, scaffolds and
templatesprimary. A guide’s leverage is that it prevents a class of
error rather than catching instances of it, which makes it the cheapest control in the system
and the most consistently under-built.
Sensors are feedback controls. They observe after the agent acts and let it self-correct: linters, type checkers, tests, review agentsprimary. Sensors are what make a loop a loop rather than a single shot — the check in gather-act-check.
The second cut splits by how the verdict is produced. Computational controls are deterministic, fast and cheap. Inferential ones are judged, slow and non-deterministicprimary. A type checker and an LLM-as-judge are both sensors, and treating them as interchangeable is a budget error in one direction and a capability error in the other.
- AGENTS.md / CLAUDE.md
- codemods, scaffolds
- typed APIs, test seams
- templates that ship green
- linters, type checkers
- unit and property tests
- build, link, schema checks
- structural fitness tests
- skills and playbooks
- worked examples
- reference docs, craft notes
- LLM-as-judge
- review agents with rubrics
- architecture critique
The three nested loops
The controls sit inside a structure of three loops, one inside the next:
- The model’s reason-act-observe loop: inside the model, not yours.
- The agent’s self-correction loop: the sensors firing, the agent responding.
- The steering loop: you, iterating the harnessprimary.
One sentence of harness engineering deserves memorising: the human’s job is to iterate the harness, not the code. When an agent produces something wrong, there are two available fixes. Fix the output, and you have fixed one instance. Fix the guide or add the sensor, and you have fixed the class — for every future run, including runs by people who were not in the room.
Böckeler pairs this with “keep quality left”primary: push controls as early in the flow as they will go. It is the same argument as chapter 3’s upstream judgment, arriving from a different direction.
Where specs come in
Spec-driven development is the on-ramp most teams take, and in harness terms an executable specification is the strongest available guide: it is the artifact the agent works from instead of a chat transcript.
GitHub Spec Kit is the reference toolkit, bundling a constitution.md of immutable project
principles, a specification, a plan, and slash-command templates across 30-odd coding
agentsprimary. BMAD-METHOD is the most architecturally
ambitious, simulating an agile team of 12 to 21 specialised agents each producing versioned
artifactsprimary. It carries a reported token cost of $800 to
$2,000 per developer per month on frontier modelsreputable, which is
a real number to put in front of whoever signs it. OpenSpec is the lightweight
brownfield option, treating every change as a proposal needing
approvalprimary. AWS’s Kiro reached general availability and
popularised EARS requirements notationprimary.
The category grew fast enough that framework shopping became its own failure mode. The recurring finding across 2026 comparisons is that the framework is rarely the differentiator; harness and context design isreputable.
Context engineering, briefly
Context engineering is a specific form of harness engineering: deciding what the agent knows
when it acts. The conventions have converged on an AGENTS.md or CLAUDE.md at the repo root,
on progressive disclosure so context is loaded when needed rather than all at once, and on
summaries that compress history without losing decisionsprimary.
The failure it exists to prevent is context rot: a window that fills with transcript until the signal is a minority of what the model sees. The Ralph loop in chapter 7 attacks the same problem from the opposite end, by throwing the context away every iteration.
What to build first
If the quadrant is the map, the route through it is unbalanced on purpose.
Start top-left: guides that are computational. Templates that ship green, typed interfaces, scaffolds, a project file that states the conventions once. These are cheap, they never expire, and they remove errors rather than detecting them.
Then top-right: computational sensors on every change. Linters, type checkers, tests, build and link checks, schema validation. Fast, binary, un-gameable — the deterministic floor of chapter 8.
Only then bottom-right: inferential sensors, reserved for what a linter structurally cannot see — architecture, prose, comprehension, design. They cost real money per run, so spend them after integration rather than on every keystrokeprimary.
The bottom-left quadrant holds the inferential guides, meaning skills and worked examples and craft documents. It is what teams discover last and value most, because it is where taste becomes transmissible.
When an agent gets something wrong, do not fix the output. Ask which control would have prevented or caught it, and whether that control is a guide or a sensor. If the honest answer is "a person would have to notice", you have found a place where the lights must stay on — which is worth more than the fix.