Constraints, specs, and gates

Theory of Constraints says a system’s throughput is set by one limiting step, and that work anywhere else does not move it. That is the organizing principle for how we build with an agent fleet. It matters more with agents than without them: agents produce plausible work fast, and the scarce thing is not production, it is knowing which production counts.

The constraint decides where work goes

Specs form a dependency chain. Each declares a return document, and its consumers start when that document exists. So at any moment one unwritten return is the limiting step, and that is where the next dispatch goes. Everything else waits, including work that is ready, well-scoped and tempting.

The second constraint is verification. Agents can run in parallel; judgment cannot. The number of returns that can be checked properly in a session is the real ceiling, and dispatch volume is held under it. A return nobody verified is not progress.

Specs make completion countable

Each spec declares a return shape: the named sections a consumer may cite. Dependencies name sections, not whole specs, so a consumer waits only on what it needs. A spec that needs two sections of another is not blocked by the other eight.

Acceptance clauses are measurements. Every clause resolves to a command or a count, so approving a spec is arithmetic and not an argument. That is what lets approval happen one spec at a time, at the moment a consumer needs it, instead of in review batches that take a day and decide six things at once.

Superseded understanding moves to a companion document the spec points at. The spec itself carries current best understanding of the area it governs, so reading it tells you what is true now, and the history stays available for anyone asking why.

Gates make the count trustworthy

A guard needs a negative case that must fire. A check that cannot fail and a check that passes are indistinguishable from outside, so every guard ships with a test proving it catches the thing it is named for.

Guards live in the tooling, not in process documents. A rule that depends on everyone remembering it is a rule with a decay rate; a rule in a pre-commit hook or a CI job has none.

Instruments report the size of the population they examined. A tool that says zero problems says how many things it looked at, so zero problems over zero files reads as the defect it is.

Together

The constraint says where effort belongs. The spec turns finishing into a count. The gate makes the count mean something. Remove any one and effort can accumulate while throughput sits still, which is the specific failure this is built to prevent and the thing that gets expensive fastest when the people writing code are agents.