The Theory of Constraints for agentic engineering.
Agents made implementation cheap. That didn't make software delivery fast: it moved the slowest step somewhere else. Rolling out agentic engineering is the work of finding that step, fixing it, and finding the next one.
Eliyahu Goldratt's Theory of Constraints says every system has one constraint that limits its throughput. An hour gained at the constraint is an hour gained for the whole system. An hour gained anywhere else is an illusion.
Speed up a step that isn't the constraint and the extra work doesn't come out the other end. It piles up as work in progress in front of the constraint, waiting.
Illustrative capacities.
Whole processes grew up around the cost of implementation: estimation, sprint planning, careful rationing of what's worth building.
Agents remove that constraint, and the next one appears immediately downstream. Typically it's the humans who used to sit next to implementation: reviewing it, testing it, approving it, and deciding what should be built at all.
An organisation that adds agents but keeps the old process just builds a bigger queue in front of the reviewers.
A common order, not a law. Most chapters in this book are about elevating one of these.
Goldratt's five focusing steps are a loop, like everything else in this book. You never finish: elevating one constraint reveals the next.
The order matters. Exploit and subordinate are cheap and come first. Only elevate, the expensive step, once you've got everything you can out of the constraint as it is.
IdentifyFind where work waits longest. Say it's human PR review.
ExploitDon't waste the constraint: reviewers only see PRs that have already passed the agent review loop and every check.
SubordinatePace everything else to it: cap open agent PRs per reviewer instead of flooding the queue.
ElevateRemove the need: zero-eyes approval for change classes the loop has proven it can handle.
RepeatReview is no longer the constraint. Find the new one, and don't let inertia keep the old rules in place.
You find a constraint by its queue. Work arrives faster than it leaves, so the items in front of it get older. In an agentic pipeline that's easy to see, because every step is already an event in a process: when did this PR start waiting, and for whom?
Measure flow and quality together. Throughput that rises while the defect rate per change rises too isn't progress. It's entropy that will show up later.
| Measure | What it tells you |
|---|---|
| Age of waiting work, per step | Where the constraint is. The oldest queue wins. |
| Lead time, broken down | How much of an issue's life is work, and how much is waiting. |
| Escalations to humans | How often, about what, and how long they sit unanswered. |
| Defects per change | Whether speed is being bought with quality. |
| Rework rate | Changes reverted, re-fixed or redone: a loop that's leaking. |
| Loop time and cost | When the constraint is the machine, not the human. |
Agents optimise the change in front of them and erode the codebase. Teams do the same at a larger scale: each one adopts agents to speed up its step, and measures success by its output.
More code, more PRs, more tickets closed. Meanwhile the review queue, the release train or the product team downstream is drowning, and nothing reaches users any faster.
Measure the system, not the step. The only throughput that counts is what reaches users, at a defect rate you can live with.
Agents removed the oldest constraint in software, so every step that used to wait on implementation is now the thing being waited on. Measure where work queues, get the most out of that step, pace the rest to it, then remove it. And very often, the first constraint you find isn't technical at all.