glossary//harness-engineering
harness engineering
Harness engineering is the practice of designing and reshaping the scaffold an agent runs inside: where the gates sit, what each role is allowed to read, how work gets routed, and what happens when a check fails.
An agent harness is an artifact. Harness engineering is the work of deciding its shape and changing that shape once it is running. The distinction matters because the two have different levers. If a review keeps catching expensive problems too late, the harness engineering answer is to move where the review fires, not to make the reviewer more thorough.
That also separates it from prompt work. Better wording improves one agent's output. Harness engineering changes which agent sees what, in what order, and who is permitted to clear the result.
Five changes, as an example
Shift-left quality in an agentic dev pipeline is a straight case study of the practice. The question it starts from is deliberately narrow: what is the Critic actually catching, and which of those catches should have happened upstream? The five answers are all structural, not tonal.
A pre-spec decision screen runs an Analyst pass before requirements are written, looking for material decisions someone would otherwise guess: timezone, locale, auth model, anything that triggers spend. ADR decision records commit architecture decisions to docs/adr/ in the target repo, so cold review has ground truth to check drift against. Seam-first testing makes every build prompt declare the seam it tests, then verifies by mutation: break the guarded behavior, confirm the test goes red, restore, confirm green. Two-axis build-diff review separates spec-fidelity findings from code-standards findings, so the expensive class can't hide behind the cheap one. Bug-diagnosis discipline requires a red-capable feedback loop before diagnosis, and a regression test that fails pre-fix and passes post-fix.
One concrete catch from that pipeline: a public-facing assessment-intake endpoint able to trigger spend, flagged in pre-build review with no rate-limit, budget-cap, or length-guard decisions pinned. Before any code was written.
Two rules that come out of it
The harness is the product states the doctrine the practice keeps arriving at. Route to ground truth, not to a vote: every trusted green signal in that system, including its own author's diagnosis, the cold reviewer, and a passing fixture, has been wrong at least once, and what caught the lie each time was something repo-aware reading the actual code, outside the party that wanted to ship. And a gate is only real if something outside the gated party can check it. The goal is mechanical enforcement, not a bigger panel of advisory reviewers.