Agent harness

The software wrapper that turns a model into a working agent: tool use, instrumenting the computer, checking its own output, managing sessions and sub-agents. The word exists to keep two sources of capability apart — what the weights can do, and what the tooling around them lets them do — and both conversations that use it reach for it precisely at that seam.

The clearest definition site is DHH at [00:08:10] of the Lex Fridman episode, explaining the winter capability jump: “I don’t know if Opus 4.5 was that much smarter than Opus 4 … but its ability to instrument your computer, to use tools, to check its own work, to apply its intelligence in such a way that you could get real meaningful work out of it, was completely different.” The referents are concrete — Claude Code, OpenCode, Codex — and the form factor is part of the observation: “all these agent harnesses arrived as TUIs, arrived as CLIs” [01:50:17]. His ranking criterion is harness-level, not model-level: multi-agent session handling is why “they actually have the best harness” [02:39:51].

The second origin is the token-factory conversation’s closing wish: “I want abundant tokens and diverse harnesses. I want everyone to build their own harness” [01:13:01] — the harness as the layer where intelligence gets customised and owned, through context rather than weight fine-tuning.

What it is not: not the model, by construction; and not an application — it is the general-purpose agent loop, which DHH expects to be a transient thing to build yourself: the bespoke coordination setups are “all gonna be solved” by the labs [02:48:14].