Nobody Is WIP-Limiting the Human

Published July 27, 2026

A Field Guide entry in “AI-Native Ways of Working.”

Agents don't sleep, and that turns out to be the whole problem.

When I dispatch a handful of agents in the evening and pick things up the next morning, there's a queue waiting. Some of it is genuinely finished. Some of it reports finished and isn't: tests failing, a feature that doesn't run, a branch nobody pushed anywhere I can see it. Telling the real from the reported is work, and it lands on me every single morning. The agents were busy all night. The reviewing didn't happen while I slept.

There's a quieter version too. Right now I have dozens of active agent sessions across my projects, plus a pile of worktrees I spun up and never cleaned. I lose track of which window is waiting on me and which is just sitting there looking busy. If you've ever come back to something half-built and had to reconstruct where you were, you know the tax. It comes due every time the work gets ahead of me, which is now most days.

I wrote a while back that on my own projects I'm the constraint and the models aren't. That post named the feeling. This one is about the mechanism underneath it, because I finally worked out what broke.

The natural limit that agents removed

For as long as software has been built by people, the amount of work in progress had a natural ceiling: human labor. You could only start as much as humans could carry. Agents took that ceiling away. Starting is nearly free now. I can kick off ten things before breakfast. Finishing still costs human-scale effort, because somewhere inside every one of those ten, a person has to understand what came back and decide it's good enough to keep.

So work in progress climbs until it hits the one thing that never got faster: my attention. Two different things are breaking here, and it helps to name them apart. Comprehension debt — output outpacing understanding — is the pile: work I no longer know the state of. Attention is what pays it down: the capacity to swap a project back in, re-orient, and hold enough of it to make a call. Run twenty projects and you pay that re-orientation tax twenty times over. When attention loses, comprehension debt grows. In a normal team, the sheer cost of human effort held all of this back. Take that away and put nothing in its place, and you get exactly the situation I'm describing. Nobody is WIP-limiting the human.

My last essay asked where the human belongs as agents earn more autonomy: in the loop, then on it. This one asks the question sitting right next to it. Once you're on the loop and the work never stops arriving, how much can you actually hold?

I have coached this before, with people

Here's what should have clicked sooner. I have spent years solving exactly this, for other people.

Limiting work in progress is the oldest idea in kanban. Sustainable pace is one of the original Extreme Programming practices, written down more than twenty years ago. Half of coaching a team was talking them out of starting a twelfth thing while eight sat open, because a board full of started-but-unfinished work is just risk nobody has surfaced yet. You limit the work in progress so things reach done, and so the people doing them can keep the pace up without breaking.

The playbook barely varies. Make the work visible, count what's actually in progress, and let the team see the number — it's always higher than anyone guessed. Set a limit deliberately above it so nobody panics, then ratchet down. Teams push back almost every time, so you run it as an experiment, or play a simulation game with them until they've watched flow happen on a tabletop. The limit comes down, and almost without exception, throughput goes up. I've run that arc more times than I can count.

The constraint moved. It used to be a team's capacity; now it's my own. The discipline didn't change at all. I just never had to run it on myself before.

Limits that don't run on willpower

The thing I learned the hard way, in a different corner of this work, is that a limit you have to remember to enforce is not a limit. I once had a spend cap that only ever told me it was already on fire. What actually stopped the fire was hard-wired and never asked my permission. Attention is the same. By the time I notice I'm overloaded, I'm well past the point where noticing does me any good.

Right now, I mostly don't run it on myself. My working set is deliberately high — partly because my tolerance keeps growing with practice, and partly for a reason nobody warned me about. My AI subscriptions are flat-rate, so every idle hour reads as waste. The meter used to push work in progress down; mine pushes it up. What running hot has actually taught me is where the limit still bites — a brand-new project eats attention like nothing else, while small features on a mature codebase barely register until testing and hands-on validation come due — and which of these mechanisms are wired in versus riding on restraint I don't always have.

• A personal dispatch limit. A cap on how many things I let run at once, picked on purpose instead of discovered at 11pm. Right now this one lives in my head, and it mostly loses to the itch to start. The version I want is a gate that refuses the next launch until something clears — at least for new work, where the attention cost is highest.
• An escalation budget. A ceiling on how many “please review” pings a workflow gets before it has to batch them or go quiet, so an agent competes for my attention instead of assuming it. I don't have one set yet, but ops teams solved this same problem with alerting years ago: page on what matters, batch the rest, because people who get paged constantly stop reading pages.
• Batched review windows. The one I actually practice. Dispatch a batch, go do the work that needs my full attention while they run, then come back, review the outputs in a block, and hand out the next round — often scheduled around whatever meetings already fragment the day. About half a day of this is my honest ceiling; past that I feel myself skimming instead of reading.
• Pull-based dispatch. This one turned real the hard way. Agents kept colliding — two of them merging into the same part of the codebase, and once a database migration that landed before the code it belonged to and broke everything downstream. Now work queues by the part of the system it touches, and the next thing starts when its lane is clear. Collisions built that plumbing, not discipline.
• A definition of done for agent work. This is the one that's genuinely structural. A short, checkable list a result either passes or fails. Did the tests run and pass, not just report green? Is it pushed somewhere I can see it? Trivial to write down, and it's the whole difference between a finished pile and a graveyard. Mine is still sitting in my backlog — which is exactly the joke it sounds like.

The anti-patterns

Naming the failure modes helps, because you feel each one before you can see it.

• Queue flooding. Dispatching faster than anything gets reviewed, so the queue only ever grows.
• The dispatch binge. That late-night hit of productivity from starting five more things, none of which you'll finish tonight or maybe ever.
• Rubber-stamp drift. The slow slide from reading the work to just approving it, one tired click at a time. The last essay drew the line between a real reviewer and a rubber stamp; this is how you cross it without noticing.
• The always-on operator. Treating a wall of live windows as a flex, when really it's the tell that you're already past your limit.
• The 80%-done graveyard. Careful with this one, because it hides a real distinction. Plenty of my projects sit at “done for now” on purpose — the problem they solve is solved, and the door stays open for the next feature when I actually need it. That's a decision, and it's fine. The graveyard is the other thing: work that stalled while nobody was looking. The difference is whether you stopped on purpose, not what percentage is left.

Where the limit itself breaks down

Three honest caveats, because a WIP limit isn't free either.

The first: batching means deliberately not looking, and I've already paid for it. I've pushed features for days while the pipeline was red and tests were failing. I once burned through a CI compute quota without noticing until things simply stopped running. And my favorite: I assumed tests were still being written along the way, discovered much later they'd stopped, and the backfill became its own project. Every one of those happened between review windows.

The second: I rubber-stamp more than the last essay would make you proud of, and it hasn't burned me yet. My problems are small, and none of this is production-grade — a flaw that won't scale is invisible to me until the day I try to productize. I'm not defending it; I'm pricing it. At my blast radius the stamp is cheap, and I know exactly what changes that math.

The third: part of why my attention is still the bottleneck is that the tooling isn't grown up enough to take the load off me. Agents dispatching agents, automated triage I'd actually trust to decide what needs a human, that isn't baked yet. I keep hoping it becomes table stakes. Until it does, budgets and batched windows are a stopgap, and I know it. I'm rationing my attention because I don't yet have anything better to hand the rationing to.

For leaders

If you're rolling agents out across teams, here's the part the agents-per-person slide leaves out. Every agent you add lands its output on a human who then has to make sense of it. Add enough of them and you've built a queue that empties at the speed of one tired person.

In my own experience, the more windows I ran, the closer I got to burning out, whatever my output looked like on a given day. I only have my own R&D to go on, and a team reshapes the problem: work hands off between people, and someone still has to own the queue. But the core holds. A person is still the thing that finishes.

So watch what agents-per-person can't see. Ask each of your people what their own dispatch limit is, and what “done” means for the work their agents hand back. If they can't answer, nobody is managing the constraint that governs their output. Give them a real ceiling, and room to finish before they start again, while it's still a decision you get to make.

For years I told teams to stop starting and start finishing. I never thought I'd be the one who needed the lesson. The work in progress is mine now, and no one is going to manage it for me.

This is one pattern from a set I'm working through on human-agent teams. It comes out of my own hands-on R&D — these days a lot of agents, run hotter than I'd advise — not a production deployment.

Back to Field Notes