saved
An engineer's guide to harnesses
Hraness wrote this summary from a saved copy of the source. Quotations are taken word for word from the source.
gist
Baseten's Alex Ker and Zak Keener collect their widely read X essays on harness engineering into a downloadable guide, pitching the harness as what turns a stateless model into useful work. The landing page outlines three sections, on optimizing your current harness, choosing one, and why harness fleets and depots come next.
ideas
- A harness is the loop around the model. It manages context, tool calls, I/O, and guardrails, which is why Claude Code, Codex, OpenCode, Cursor Agent, and custom scaffolding all count.
- Models and harnesses are a pair. Labs post-train them together, so swapping either half costs quality, latency, and money.
- Judgment moves into the harness. Engineering skill now shows up in the harness more than in model choice.
- Not only for engineers. Progressive disclosure, RPI, and subagents apply to anyone driving an agent; routing, caching, and joint post-training are for engineers.
quotes
“Mechanically, it's a while (have next message) do {tool} loop.”
“Engineers used to argue about IDEs; now they argue about harnesses.”
“Section 3 argues that harness fleets are inevitable and makes the case for depots as the next abstraction layer.”