On Building the Harness
Notes on why the infrastructure around AI agents matters as much as the models themselves.
Every new AI tool arrives with a demonstration. The demonstration is always the easy part: the model completes a task, the interface is clean, the output looks right. What the demonstration never shows is what happens in session three, or session thirty, when the model has forgotten everything and the operator is rebuilding context from scratch.
This is the harness problem. The model is not the bottleneck. The infrastructure around it is.
What a harness actually is
A harness is everything that makes the model usable across time: the context management, the task structure, the memory protocol, the handoff format, the hooks that enforce consistency, the tooling that makes the next session start where the last one stopped.
Building a model is not building a harness. Using a model is not building a harness. Building a harness is the work that makes the model into a system.
Why most people skip it
The harness work is unglamorous. It does not appear in benchmarks. It does not generate impressive demos. It takes time to design, longer to debug, and it fails in ways that are hard to attribute — not a crash, but a drift. Context degrades. Decisions are re-made. Work is repeated.
The pressure to skip it is real. The cost of skipping it compounds.
What we built instead
The work in this workshop is, in large part, harness work. Synod is a harness. ShipGuard is a harness. The global hook system, the session handoff protocol, the vault — all of it is harness.
None of it is the point. The point is the work the harness makes possible.
That is the distinction worth keeping: the harness is infrastructure, not product. You build it to disappear into the background. If you are thinking about the harness while you are doing the work, the harness is not finished yet.