Harness Engineering

Harness engineering is the umbrella name for a stance you've been building piece by piece through the last eight lessons: the durable asset isn't any one agent session — it's the machinery around the sessions. The briefing files, the saved procedures, the enforced invariants, the scores, the gates. Together they're called the harness, and the observation this lesson exists to deliver is blunt: the teams quietly getting 10x from agents are not the teams with the cleverest prompts. They're the teams that invested here. This lesson makes the stance explicit, shows the reflex that builds a harness one friction at a time, and gives you the build order that works.

The stance, stated plainly

Sessions are disposable. Whatever made a session go well — the context you fed it, the constraints you set, the checks you ran — either gets captured into the environment or evaporates when the window closes (lesson 2 made this physical: the desk gets cleared). The harness engineer's reflex, after every good session and every bad one, is a single question:

What do I change about the environment so this outcome is automatic next time?

Run the reflex over a normal week of frictions and watch it dispatch to the lessons you already have:

• Agent kept using the wrong test command → CLAUDE.md (8).
• You typed the same three-paragraph review prompt again → command (9).
• The right checklist existed but nobody remembered it → skill (14).
• The forbidden thing happened anyway → hook (15).
• You think the new prompt is better → eval (21).
• Works in your session, nowhere else → headless run in CI (18, 28).
• You explained the same project state to a fresh session → memory file (24).

Seven frictions, seven mechanisms, one instinct: push knowledge and control out of the conversation into files, configs, and checks that persist, version, and compound. Conversation is where problems are discovered. The harness is where solutions live.

Why environment beats performance

Prompting skill is real (lesson 1) and it has two ceilings a harness doesn't:

It doesn't scale past its owner. Your best prompting improves only the sessions you personally conduct. A hook, an eval, a well-written command improves every session — teammates', future yours, and the automated ones nobody conducts at all. One is a performance; the other is infrastructure.

It doesn't ratchet. A brilliant session leaves nothing behind; a harness improvement is a permanent floor-raise. Environments accumulate. Performances don't. Over a year, the compounding difference between the two is not incremental — it's the difference between a team whose agent output is reliably good by construction and a team with one wizard and a lot of variance.

There's a third argument, and it's the one that governs the whole back half of this course. Model output is probabilistic; your comfort delegating is bounded by the worst case, not the average. Enforcement and verification are what bound the worst case — which is why every autonomy lesson ahead (17, 18, 25, 28, 29) turns out to be a harness lesson wearing a trench coat. You don't remove the human by trusting harder. You remove the human by making the checks not need one. Autonomy is purchased with harness, and with nothing else.

The build order that works

Nobody builds a harness up front, and you shouldn't try — a harness built speculatively guards against imagined frictions and misses the real ones. It accretes from actual pain, and the effective order is almost always:

1. Brief the repo — CLAUDE.md: commands, map, boundaries. An hour of work that improves literally every future session. If you do exactly one thing from this course, do this.
2. Capture procedures — commands for what humans invoke, skills for what situations invoke. Driven by the "I've typed this before" signal, spread over weeks.
3. Enforce the invariants — hooks for the small set of nevers, each proven to block by firing it once on purpose (lesson 15's sixty-second proof; unproven enforcement is decoration).
4. Score what matters — an eval for any workflow you run often enough to tune (lesson 21). This is the step teams skip, and it's the step that separates iterating from wandering: without a score, every prompt change is a vibe.
5. Wire it into CI — checks on every push; agent-produced work gated like human-produced work (lesson 28).

Two operating notes on the accretion. First, budget for maintenance, not just creation: a harness is code — briefings go stale (lesson 8), skills drift (14), hooks need re-proving after refactors (15). The same-PR discipline (update the harness in the diff that invalidates it) is what keeps it an asset instead of a second legacy system. Second, watch the overhead (lesson 2): every resident addition costs context every turn. The harness has a budget too, and lesson 20's arithmetic — what rides along versus what loads on demand — applies to your own machinery first.

The test of a good harness

One question evaluates the whole thing: could a stranger — human or agent — do good work here on day one? A well-harnessed repo answers yes: the environment briefs them (8), equips them (9, 14), constrains them (15), and grades them (21, 28), regardless of who or what they are. That framing also reveals what a harness is, underneath: engineering culture, made executable. Code review norms become hooks. Tribal knowledge becomes briefing files. "We're careful about migrations" becomes a gate with opinions. Your team already knew these things; the harness is those things, awake at 3am, applied consistently to collaborators who read everything and remember nothing. The rest of the course is spent putting that machine to work.