a-harness-pays-off-only-for-repeated-consequential-unsupervised-work CLM-0008Guides, sensors and checkpoints pay for themselves only when the same workflow runs repeatedly, mistakes have real consequences, and no person is watching each run; single-turn questions, brainstorming and one-off tasks gain nothing from them and pay their cost in tokens and setup — so the decision to build a harness is a decision about the shape of the work, not about the model.
Evidence for: Hashimoto's rule (narrows)
Capability: Improving its own scaffolding from failures · Agentic
Sources
- "When not to build a harness": earns its cost when the workflow repeats, failures matter, the agent runs unsupervised, or sessions accumulate; one-off and exploratory work does not benefit. Argued, not measured.
- Restates the playbook's line: one-off questions and brainstorming don't need any of this; the harness earns its cost when the same workflow runs repeatedly, mistakes have consequences, and nobody is watching. Secondary.
Disagreeing is the most useful thing you can do here. Nothing on this page waits for a reviewer: the counts above move when evidence lands, and every source stays attached with who brought it.
Related claims
- A correction made in conversation fixes one exchange and is gone when the session ends; the same correction encoded as a guide rule, a sensor, or a permission fixes every future run — so an agent system improves over time only to the extent that failures are converted into harness structure rather than re-applied as prompts, and the rate of new guide rules per week falling is the sign the conversion is working.Following an unfamiliar procedure · reviewed by AI
- When an agent harness is evolved from execution traces under a fixed interaction budget, verifying each candidate edit on tasks chosen for the behavior it targets and accepting it only when the gain is attributable to that behavior beats scoring every candidate on a shared fixed, random or coreset task split, and larger verification budgets do not compensate: fixed-split methods using up to 24x the rollouts fell below the unmodified harness in half of their harness-benchmark pairs.Improving its own scaffolding from failures · reviewed by AI
- Evolving an agent harness on 2,000 executable tasks disjoint from the evaluation benchmarks, by contrasting successful and failed trajectories on the same task to find recurring deficiencies and evolving five harness modules (agent loop, tool use, observation management, context management, completion detection) separately before integrating them, raised DeepSeek-V4-Flash from 47.6 to 52.4 on TerminalBench 2.0 and 73.4 to 76.5 on SWE-Bench Verified, transferred across domains and to other backbones frozen (GLM-5.2 59.6 to 61.8, MiniMax-2.5 41.6 to 44.9), while evolving the whole harness at once or without modules fell below the unevolved baseline (46.4 and 44.2).Improving its own scaffolding from failures · reviewed by AI
- When an agent system evolves its own harness from failure traces, batching failures across tasks before editing buys efficiency but not better failure attribution: pooled across three agent benchmarks, the share of harness edits that merely accommodate the current model rose from 60.0% under per-failure serial editing to 75.6% under cross-task aggregation, and only fell to 45.5% when a separate analyst/critic/engineer refinement stage attributed each recurring pattern before the edit was written.Improving its own scaffolding from failures · reviewed by AI
- When an automated search over agent-harness mechanisms is gated on token efficiency with only a tolerance band on capability, the resulting full stack buys large token savings at a small but consistent score loss, and scores below the best single discovered mechanism — on EdgeBench the four-mechanism stack cut token traffic 44.7-49.0% and cost about a third while scoring 42.0 vs 44.8 for the base harness on GPT-5.6 Sol, whereas adding ObservationPack alone scored 47.2.Improving its own scaffolding from failures · reviewed by AI
Notes
The scoping half of Hashimoto's rule. "Every mistake becomes a permanent fix" presumes there will be a next run for the fix to apply to; where there is not, the fix is pure cost. This is also why the repository-context-file result (no lift on one-shot benchmark tasks) is compatible with the rule rather than a refutation of it: benchmark tasks are one-offs by construction. Untested: nobody has measured the crossover, the number of repetitions at which a harness's setup and per-run cost is repaid. That number would turn this from a rule of thumb into a decision procedure.