WIP limits for AI agent work

WIP limits for AI agent work should cap how much finished-but-unreviewed work you allow to pile up, not how many agents you can run. Agents make starting work almost free: a new terminal, a task description, and a branch appears an hour later. What they do not make cheaper is your attention. Every agent run ends in something a person must read, check and decide on, so the real constraint on throughput is review capacity. Without a limit, work in progress grows quietly, reviews get shallower, and stale branches conflict with each other. This article explains why the classic kanban idea matters more with agents than with people, where to put the limit, how to choose the number, and what to do when you hit it. For board states themselves, see kanban for AI agents.

Why agents make starting too easy

With a human team, starting a task has a natural cost: someone has to stop what they are doing. That friction acts as an informal WIP limit. With agents the friction disappears. You can open five sessions before lunch, each on a reasonable task, and each will produce output. The cost arrives later, all at once, when five diffs need review and two of them touch the same files.

There are second-order costs too. Each open task holds context in your head: what you asked for, what you decided, what the agent might have assumed. Parallel branches drift apart and conflict at merge time. Work that sits unreviewed goes stale because the code it was built against keeps changing. And when the queue is long, people review faster and less carefully, which is exactly the wrong response to agent output. Running many agent terminals at once is fine in itself; letting their output outrun your review is the problem.

Put the limit on review, not on runs

The useful question is not how many agents are running but how many items are waiting for a person. An agent session that is still working costs you little. An item in review costs you attention every time you glance at the board, and it gets more expensive the longer it waits.

So count everything that is active or waiting for review against the limit, and treat the review column as the one that matters most. When it is full, the rule is simple: no new work starts until something leaves review, either accepted, sent back with a clear note, or declined. This turns the limit into a pull system. You start a new agent task because review capacity freed up, not because an idea occurred to you.

Some teams also cap active sessions separately to avoid file conflicts between agents. That is a reasonable second limit, but it addresses coordination, not throughput. See keeping agents out of the same files for that problem.

Choosing the number

Start from your honest review rate. Over a normal week, how many agent changes can you read properly, run checks on, and decide about per day? For a solo developer doing careful review of moderate changes, that might be three or four. For larger changes touching shared code, it might be one.

Set the WIP limit at roughly one to two days of review. If you can review three items a day, a limit of four to six items active or in review keeps work flowing without letting a backlog form. Smaller is better at first; you can raise it once you see the review queue clearing reliably.

Adjust for task size. A limit counted in items treats a one-line fix and a schema change the same. If your tasks vary a lot, split large tasks before they start, or count large tasks as two. Revisit the number when the queue shape changes: a column that is always empty means the limit is too high to bite, and one that is always full with old items means it is too high to keep up with.

What to do when you hit the limit

Hitting the limit is the system working, not a failure. The response should always be to finish things, never to raise the limit on the spot. Work through the review queue oldest first, because older items are more likely to have gone stale against current code. For each one, choose one of three outcomes: accept it, send it back with a specific instruction, or decline it and record why.

If an item is stuck waiting on a decision only you can make, make the decision or move it to a state that clearly says a decision is owed, so it stops counting as active work. If an item is blocked by another task, link the dependency and move it out of the active lane.

Use the pause to look at the backlog. A full review queue is a good moment to ask whether the next tasks are the right ones; prioritizing by review cost covers how. Starting new work only when something leaves review keeps the board honest about what is actually done.

QUESTIONS

What is a good WIP limit for one developer using AI agents?

Roughly one to two days of your real review capacity. If you can properly review three agent changes a day, a limit of four to six items in progress or in review is a reasonable start. Lower it if items routinely wait more than two days for a look.

Should work waiting for review count toward the WIP limit?

Yes. Work waiting for review is the most important part to count, because it consumes your attention and goes stale while it waits. Excluding it lets agents keep producing output faster than anyone checks it, which defeats the purpose of having a limit.

How many AI agents should I run in parallel?

As many as your review rate and file boundaries allow, which is usually fewer than you can start. Parallel agents on separate, well-scoped tasks are fine. Once the review queue grows faster than you clear it, more parallel sessions only add unreviewed work and merge conflicts.

RELATED GUIDES

• How to find and organize work across projects

RELATED HARNESS PAGES

• kanban for AI agents Kanban for AI agents: the board states that matter when software does the work, including review, blocked and decision owed.
• Prioritizing a backlog when agents work fast Prioritizing a backlog when agents work fast: rank by value, review effort, risk and dependency order, and use P0 to P3 as real commitments.
• Running several AI agent terminals without losing track Running several AI agent terminals without losing track: one task per terminal, task-based names, a session ledger and a close-out check.
• human review of agent output Human review of agent output: what to inspect before accepting AI changes, and how recorded outcomes make the review honest.
• Tracking AI agent progress: built vs accepted Tracking AI agent progress: built vs accepted. Keep implementation, current evidence and acceptance as separate numbers and read them weekly.
• A solo developer's workflow with AI agents A solo developer's workflow with AI agents: one person as planner, reviewer and release owner, with a weekly plan and a short daily routine.