Harness Engineering

Harness Engineering names the shift that happens once models are strong enough: the engineering center of gravity moves from "how to ask" (Prompt Engineering) and "what to show the model" (Context Engineering) toward giving the agent tools and feedback channels so it can decide for itself what to look at and what to verify, while boundaries — sandboxes, permissions, tests, CI round limits, structural constraints — keep it from running away.

The point of the three-ring spiral is not the taxonomy but that each ring, once mature, becomes the next ring's infrastructure: prompt technique hardens into templates and system prompts, context assembly hardens into retrieval and compression pipelines, and then the harness layer takes over "who decides the next step inside the loop".

The answer to "if models are this strong, what is a harness still for" (the agent-harness bitter-lessons field retrospective): the harness's job is not to eliminate complexity — complexity cannot be eliminated — but to allocate complexity, routing each piece of business truth back to the layer that should be responsible for it. The anti-pattern is the runaway loop (benchmark → bad case → prompt patch → local metric gain → new regression → system-wide rigidity); the healthy pattern is the homing loop (bad case → locate the failing layer → minimal fix at the responsible layer → end-to-end regression → decide whether the rule stays). The touchstone sentences: a benchmark is a diagnostic instrument, not an autocomplete for the System Prompt; a bad case is evidence, not an answer — it tells you something broke, not which layer to fix it in.

The same source's view of rule governance: any new rule entering the system must be able to answer four questions — which failure it came from, which layer it truly belongs to, what metric shows it works without hurting neighboring cases, and how you will know it can be deleted once upstream changes. Without that record, temporary scaffolding stays in the System Prompt forever; the people after you dare not delete it and can only build around it — "the scaffolding ends up a prison". This lines up with the engineering reading of The Bitter Lesson: freezing local human experience into rules works short-term and compresses the model's generalization space long-term — but the conclusion is not "write no rules"; it is that deterministic boundaries go into code / state / testable contracts, and only the parts that need understanding, search and generalization go to the model. The unit of evaluation is accordingly not a single prompt, node or offline score, but the task the user actually needs done (three scales: components and contracts / end-to-end chains / live product outcomes — see agent-runtime-design).

First-hand confirmation is in the article How one Video Agent iteration grew into a harness method: the iteration pressure of a video-style agent naturally grew shared context (comparison matrix + phase trace), independent review (a three-layer review stack), a boundary knowledge base (boundary / exemplar store) and regression protection (golden set + regression gate) — together those four things are a harness.

Observations at the writing-methodology level are recorded in LLM Harness Writing Study.