Rigor has a budget
The most expensive failure in my agent fleet this fall didn’t look like a failure. Every check was green and every agent was busy.
On October 21, 2026 we rewrote our plan for the next release, and its first section had to explain why the plan had suddenly become small. This is what it said, in short.
For two weeks the agents had worked on two proofs they set for themselves. One was a speed benchmark over 5 million rows. It took four failed attempts and ended in a real fix six lines long. The other was a seven-step release ceremony for the agents’ own tooling. Since October 8, main had taken about 650 commits. Four of them touched product code.
The platform we were preparing for didn’t ask for either proof. No customer would ever touch either one. We parked both.
Nobody was lazy
Every one of those commits was careful work toward a goal that sounded reasonable. That is the trap. Agents are very good at making progress, and progress feels like the thing you asked for. A benchmark is rigor. A release ceremony is rigor. Neither one was the product.
The same pattern, three weeks earlier
On September 29, an audit of my model-training program had found the same pattern from the other side. In a 41-hour stretch of the governed phase, there was about one hour of actual training. Across the program, a training process was running in about 28% of the wall-clock time.
The rest was process: plans filed before each run, guard scripts, review rounds. Each piece was there for a good reason. Together they crowded out the work they existed to protect. The audit called it “ceremony displaced learning.”
It found two more things worth repeating. Failures were being “consumed” instead of retried. And the independence was nominal: the lane that reviewed experiments and the lane that ran them shared one CLI identity and one model family. The goal prompt had no budget and no condition for stopping.
So we had all the trappings of rigor, without the budget that makes rigor useful, or the independence that makes review mean anything.
What we do now
A question for every step in a plan: who would notice if this step were never done? If the honest answer is “only the agents,” the step waits.
A rule about time. Our process doc now says to treat unexpected duration as a defect in the delivery path, and never as a reason to wait longer. Every live phase gets an expected duration, an observation timer and a named checkpoint. If a phase runs past twice its expectation, misses a 60-second checkpoint, or repeats the same expensive proof without a recorded reason, the blind retries stop and someone asks why, with measurements. A stuck agent looks exactly like a busy one. A clock is the cheapest way to tell them apart.
Independence that is real. The reviewer comes from a different model family than the author, and it runs under its own identity.
The lesson
Rigor is a cost. It is usually worth paying, and it still needs a budget. When the checking takes more time than the work it checks, look at what the checking is for, and whether anyone outside the system would notice it was gone.
The six-line fix from that benchmark was real and we kept it. It is a good reminder that the work inside a ceremony can be fine. What goes wrong is the share of the time it takes.
- Sep 2026The cleanup agent that deleted my model caches
- Aug 2026When an agent does something strange, check what it was refused
- Aug 2026Ten tasks marked done, never on main
- Jul 2026Eight completions, zero real
Building something with agents? Say hello.