The Best Agent Harness Is the One You Don't Notice

Everyone wants to talk about the model. Nobody wants to talk about the loop around it — the harness that reads its output, calls a tool, feeds the result back in, and decides when to stop. That's a mistake. The model is swappable. The harness is where the actual engineering lives, and a bad one will make a great model look unreliable.

What a harness actually has to do

• Own the control loop, not the model. The model proposes a next step; the harness decides whether to run it, retry it, or halt.
• Enforce permissions outside the prompt. "Please don't delete production" is a suggestion. A harness that checks tool calls against a real allowlist is a control. The same structural thinking applies to retries: a harness stamps each logical action with an idempotency key — a fresh UUID v4 per step — so a model-initiated retry can't double-fire a side effect.
• Make partial progress legible. When a run stops at step 3 of 7, the harness — not the transcript — should be able to say exactly what happened and what state it left behind.
• Keep context management separate from reasoning. Summarizing, truncating, and re-injecting context is bookkeeping. It shouldn't share a failure mode with the model's actual judgment calls.

The trap

The tempting design is to let the model drive more of this — decide its own stopping point, manage its own memory, self-report its own permissions. It demos well. It also means your safety and reliability properties now depend on the model behaving, every time, under adversarial and edge-case input. A harness that enforces its guarantees structurally doesn't need the model to cooperate. One that delegates them to the prompt is hoping.

The best harness architecture isn't the clever one. It's the boring one: explicit state, explicit permissions, explicit stop conditions — all living in code that runs whether or not the model agrees with it.