Your Retry Budget Is Not a Safety Net

*Second in a series on The Factory. Previously: The Factory That Merged 37 Tasks . The harness is at github.com/frozer/factory . The public description of my task harness ends on a claim: a packet that's wrong about the world fails identically on every retry. That sentence cost me four dead tasks and nine commits spent repairing task definitions instead of writing code. It reads like something you'd arrive at by thinking. I arrived at it by watching the same failure scroll past three times in a row. What three attempts is actually good for max_attempts = 3 felt like obvious hygiene. Models are stochastic. Sometimes a run goes sideways for no reason you can name — a bad turn, a truncated response, a tool call that gets refused. Retry it and it works. That's real, and a retry budget handles it well. The strength is exactly the constraint. A retry budget assumes the next attempt will differ from the last one . It buys you a second sample from a distribution. But a retry doesn't hand the model a fresh situation. It hands it the same packet back . Same file, same claims, same instructions. If the packet says a file lives at a path where no file lives, attempt three fails precisely where attempt one did, and the only thing three attempts bought was three times the bill. Failure without variance isn't flakiness. It's a specification defect wearing a reliability costume. Nobody had opened the files Here's what that looked like in practice. B03 was a loader for a national census dataset. Three attempts, all burned, all against a file shape that existed nowhere: wrong directory, wrong filenames, and a Data / Valor JSON envelope that appears nowhere in the actual data tree. Every attempt produced a parser for a document that doesn't exist. The packet was the defect, not the model. Nobody had opened the actual files before cutting it. Rewritten from the real JSON, the truth was a flat metadata / data envelope, four files — one of which shouldn't be loaded at all — and a long-fo