Guides and sensors: the two jobs of a harness

Birgitta Böckeler's harness-engineering piece gave me a cleaner vocabulary for a thing I had already built by feel. Agent = Model + Harness; the harness is everything that is not the model. She splits it into two jobs — guides and sensors. Guides steer the model before it acts. Sensors watch after it acts and help it self-correct. Once you have those two words, the whole apparatus of an autonomous system snaps into a grid.

Each guide and each sensor is either computational — deterministic and fast, milliseconds to seconds — or inferential — semantic, slower, a judgment call. A linter is a computational sensor. A frontier model reviewing a diff is an inferential one. The taxonomy is not the insight; the insight is that you push work down and to the left. The cheap deterministic checks should run first and most often, and you should only spend an inferential check — expensive, fallible — where a deterministic one cannot reach.

My deploy gate is that map wearing work clothes. Before anything ships, a static-analysis pass, a secret scan, and a 100% coverage floor run first: computational sensors, all of them, pass-or-fail. Then, and only then, a frontier model reads the diff — the one inferential sensor, spending money only on the semantic question the others cannot answer: does this change actually make sense. Nothing ships until all of them agree. The guides show up earlier and quieter — a doctrine injected into every prompt, the ontology the engines reason from, the scope rules that keep a change small. They are feedforward; they shape the change before it exists.

Böckeler names a property I had felt but never labelled: harnessability — how amenable your codebase is to being controlled by an agent in the first place. A pure-logic crate at 100% coverage is highly harnessable; a sprawling client-rendered app is not. It is why my one hard rule is that the risky logic lives in a small, totally-covered module and the agent may touch only three files. You raise harnessability the same way you raise testability: by making the environment legible. The harness is only ever as good as the terrain lets it be.

The map also explains my worst night. I loosened a guide — told the loop to build features instead of small safe changes — and it obliged, building an elaborate feature across twenty commits until, somewhere in there, the code stopped compiling. The computational sensor that would have caught it, a compiler, does not run locally here; the only one lives in CI, minutes downstream. So the broken commits stacked faster than the sensor could fire. The fix was not a smarter model. It was a better-placed sensor and a tighter guide: revert to green, forbid the multi-line edits the loop cannot verify, and keep the ambitious work for a human who can see the compiler. Keep quality left. Keep the agent inside what the harness can actually sense.

That is the quiet thesis of the whole discipline. The model is the part everyone watches. The harness — the guides that steer it and the sensors that catch it — is the part that shows up to work, and the part that decides whether an agent you cannot supervise makes you faster or just makes messes faster. This post was drafted, gated, and shipped through exactly such a harness. If it reads clean, that is the sensors doing their job.