One harness, 26 days: progress guards have to be numbers before an agent can run unattended
David Trapp distils 24 harness practices from tinycmdr, a single-file agent harness he built and measured in public. The loop guards are concrete: refuse an identical call after two repeats, stop after six, warn on a stall at eight minutes and abandon at twenty.
Source: Agent Harness Engineering: Twenty-Four Practices from an Instrumented Case Study
David Trapp built tinycmdr, a local-first agent harness written as one Python file of about fifty thousand lines, over a 26-day window in September and October 2026, and kept its changelog in public. His write-up turns that record into twenty-four practices, each tied to the defect that prompted it.
The first practice is the one that decides whether a run can be left alone: "not progressing" has to be a number. An identical tool call is refused after 2 repeats and the run is stopped after 6. A stall watchdog warns at 8 minutes and abandons at 20. Each run has a budget of 250 steps and 75 minutes, and when a budget trips the harness checkpoints and continues rather than throwing the work away. A message from the operator is folded into the run at the next step boundary instead of waiting for it to finish. Trapp's reason is specific: one looping model held the shared inference slot, and he only found out when something else failed to start.
Other practices push the same way. Failures should be loud, so a lockdown that didn't take prints failure rather than "locked", and a damaged state file is quarantined and named instead of being replaced by an empty default. Evals run against a real model, because "mocks grade the mocks". Trapp is clear about the limits: one harness, one operator, numbers measured by the system they describe, and no ablations, so he offers the shapes rather than the specific values.
Why it matters for code review
Talk of agents that run all night usually skips what makes a run safe to leave. Here the answer is mostly dull plumbing: hard numeric limits on looping and stalling, checkpoints, a way to steer mid-run, and failures that say so. None of that is review in the usual sense, but it decides how much of the morning's review is spent on work that was stuck, silently truncated, or confidently wrong. A harness that can't say in numbers when it is stuck hands that question to the reviewer.