Harness engineering: your agent is only as good as the loop around it

The uncomfortable truth about production agents: the model is maybe 20% of the system. The other 80% is the harness, the loop that decides what the agent sees, what it's allowed to do, what happens when it fails, and who gets asked when it shouldn't decide alone. Teams that treat the harness as plumbing ship demos. Teams that treat it as the product ship systems.

A harness, concretely: state the agent can re-anchor to from any point (checkpoints, not chat history), idempotency keys on every write so a retry never double-books, explicit budgets (tokens, wall-clock, actions) with hard stops, and an escalation path that hands a human real context instead of a transcript dump. Every one of these exists because something in production taught me it had to.

The design question that sorts harnesses: what happens at 3am when step 7 of 12 fails? If the answer is 'the run is corrupted, start over,' you have a script with an LLM inside. If the answer is 'it retries idempotently, and if that fails it parks the run in a reviewable state,' you have a system. Pause, resume, cancel, those three verbs cost more engineering than the agent itself, and they're worth more.

Evals close the loop. Every incident becomes a test case; every test case gates the next deploy. My rule from operating agent fleets: an agent capability doesn't exist until there's an eval that fails when it breaks. Vibes-based agent quality degrades silently, models drift, prompts rot, and nobody notices until a customer does.

The field is converging on this from both ends, model vendors shipping better loops, engineers building better scaffolding. The job title that's emerging in the middle is basically 'harness engineer.' It's most of what I do, and it's the most leveraged engineering I know of right now.