Harness engineering / 01
Harness anatomy
A harness is the operating system you build around a probabilistic CPU. It has five organs: a loop, memory, context, tools, and evals. Most "agent problems" are a missing organ.
What it is
The model is not the product. The product is everything wrapped around the model call: the loop that decides whether to call again, act, or stop; the memory that persists across sessions; the context assembled for each call; the tools the model is allowed to use; and the evals that prove the whole thing still works after a change. That wrapper is the harness.
Claude Code is a harness. Cursor is a harness. Every serious agent product is a harness with a rented CPU inside. Two products on the same model behave completely differently, and the difference is never the model. It is the harness.
Why it exists now
Models are commoditizing on a cadence of months. Whatever capability advantage a model gives you, your competitor rents it next quarter. The harness is the part you own: it accumulates your product's judgment about what to remember, what to show the model, what it may touch, and when to stop it.
The skill is also commoditizing from below: frameworks now ship the skeleton of a harness in one install. What they cannot ship is the judgment inside each organ. That is why teams increasingly interview for systems thinking around the model rather than model knowledge itself. Systems thinkers age well here; model thinkers re-learn their job every release.
The 20-minute kata
- Pick an agent product you use every day. Claude Code, Cursor, a support bot you operate, one of your own.
- Reverse-engineer its harness on one page, five headings: Loop (when does it call the model again, and when does it stop?), Memory (what survives between sessions, and where does it live?), Context (what gets assembled into each call: instructions, history, retrieved docs?), Tools (what can it do to the world, and what is gated behind an approval?), Evals (where are the checks that catch a regression?).
- Mark the organ you cannot find evidence of. There is usually one.
- Write one sentence: how does that missing organ explain the thing that most annoys you about the product?
If you can do this for someone else's product, you can design your own on purpose instead of by accident.
What good looks like
- Can name all five organs of any system they build or operate, and point to where each lives in the code.
- Triages misbehavior to an organ: a wrong answer is diagnosed as a context problem, a memory problem, or a loop problem before anyone blames the model.
- Designs the organs deliberately instead of accepting framework defaults, and can say why each default was kept or changed.
- Treats the harness as the durable asset and the model as a swappable part. A model upgrade is a config change plus an eval run, not a rewrite.
How it's tested
"Sketch the architecture of an agent you've shipped. Where does the model end and your system begin?"
The red flag: fluent description of what the model can do, silence about what their own code decided. If the answer has no loop, no memory, and no evals in it, the candidate has operated a demo, not a system.