I catch myself doing this. I start one agent on a dashboard, another on article research, another on a client artifact. Each start is rational. The agent is going to work for a while, so why should I wait?

A couple of hours later, I am the one carrying the map. Which decision is waiting? Which branch needs review? Which result do I no longer remember well enough to judge quickly? The agents are not overloaded. I am.

That experience is becoming normal. Anthropic’s customer stories describe teams at Rakuten and developers at Ramp running multiple Claude Code sessions simultaneously. Anthropic’s own advanced-patterns guide treats parallel instances as a real operating mode. One practitioner described the coordination problem of five active project sessions.

Maybe we have broken through an old human limit. More likely, we have made it much easier to walk into the old utilization trap with a crowd of cheap digital workers behind us.

This is the point I made in Stop Focusing on Utilization. Start Focusing on Flow. Keeping every resource busy is not the goal. In agentic development, an idle agent can be perfectly healthy. Human attention for steering, review, integration, and deciding what matters is usually more scarce than agent runtime.

That is why WIP limits should still mainly reflect human capacity and attention. The argument to the contrary is valid up to a point: long-running agents create useful waiting time, good isolation reduces interference, automated checks reduce review effort, and some humans really can supervise more parallel work than before. We have always used waiting time this way. A long build, a mainframe job, or a slow test suite gave us a reason to do something else rather than stare at the screen.

But “something else” does not have to mean another feature. While an agent works, I can improve tests, prepare telemetry, clarify a product decision, review the release path, or do other useful work inside the same feature. I can also work the board right to left: review telemetry for a live feature, unblock review, help test, release something, or close the learning loop on work that is already in flight. Starting another feature should come after those options, not before them.

There is another reason to be conservative. The human version of a context window is shared across every thread we are juggling. We compact it automatically, usually without noticing. Every additional feature pushes detail out, makes reorientation more expensive, and creates some quality loss. AI agents can have separate context for separate threads. I cannot.

So my default for one human or one pod is one actively guided feature. A second feature becomes a legitimate experiment when the first agent is running a genuinely autonomous loop, such as working toward a /goal, rather than waiting for continuous prompting. Even then, the efficiency gain has to pay for the cognitive load.

There is a stronger counterexample. If an agent system can independently choose a bounded task, implement it, test it, deploy it, watch the outcome, and recover inside clear policies while humans sample by exception, human attention may no longer be the immediate constraint. The relevant limit might then come from environments, release risk, customer exposure, or compute economics. I think most teams are still far from that operating mode. Until agent output can move safely through the whole loop, counting agent sessions as capacity mostly moves unfinished work toward the next human.

A feature flowing through Spec Kit’s Spec → Plan → Tasks → Implement path is one feature, not four WIP items. Several BMAD personas discussing it are not several delivery pods. Two review agents examining the same pull request are parallel perspectives on one item.

Implementation-task fan-out, worktrees, pull requests, agent outputs waiting for input, and human review decisions are how that feature moves. They are useful workflow signals. They may need orchestration policies. But they do not become extra WIP items that you add to the feature count. The feature stays in WIP while it is being built, waiting for input, under review, deployed, or awaiting the learning needed to call it Done.

The human question is simpler:

• Am I actively guiding the AI? That is much like coding. The feature is active, and the human is not actually free.
• Is the agent pursuing a goal autonomously? That creates real waiting time and may justify pulling another feature, up to the point where context switching starts damaging judgment and quality.

Start the active feature limit at 1 for a solo pod. Test 2 only when the agent can run independently toward a clear goal, same-feature and right-to-left work are genuinely exhausted, and the second feature improves throughput without more reorientation, stale output, merge churn, rework, or quality loss. Three simultaneous features should require unusually strong evidence.

The upstream funnel and the downstream release/adoption path are separate WIP conversations. You can keep feature concurrency under control inside the spec-driven workflow and still drown in ideas before it or releases after it. Count end to end wherever the next meaningful learning boundary sits.

Headcount alone is almost useless for choosing the number. The same six people can behave like one whole-team swarm, two independent trios, three stable pairs, or five builders feeding one reviewer.

Start with one actively guided feature for each independent pod. Treat that as a starting point. Let a pod try a second feature only when its agent is running an autonomous goal loop long enough to create useful waiting time, the pod has already looked for finishing work, and the extra concurrency pays for the cost of switching context. Then check whether a shared reviewer, architect, decision maker, environment, or release gate forces the number back down.

For the three-pair example, I would start with three active features and perhaps one shared Ready slot, for a combined limit of four. If each pair later proves it can carry a second autonomous feature without more aging or quality problems, the team could try six active features. That is a later experiment, not the default just because each pair has agents.

Before calculating anything, ask a more basic question: do we want to keep doing what we are doing, or change how we work? A limit close to current WIP will mostly preserve current behavior. That may be exactly what you want if work is flowing well and the team has no appetite for a change.

But if you notice that you or your team are spread too thin across several areas and you want to do something about it, lower the limit until it occasionally stops another start. That uncomfortable moment is useful. It creates a reason to finish something, help someone else, review, pair, remove a blocker, or improve testing and the workflow before pulling more work.

If nobody intends to behave differently when the limit is reached, the number becomes WIP-limit theater. The policy cannot create collaboration on its own. It can create the nudge and the conversation.

I used to hear people create “slack” by taking a person away from the WIP calculation. That confuses two different things.

• Capacity slack is human attention available to help, review, improve the system, or handle an incident.
• Flow slack is a small amount of controlled WIP that protects the constraint from ordinary hiccups.

In The Goal, Herbie sets the pace of the Boy Scout hike. Letting the faster scouts run far ahead does not make the troop arrive sooner; it creates distance—inventory—between them. Drum-Buffer-Rope uses a buffer to protect the constraint and a rope to control release. The point is not zero inventory. The point is enough protection without an uncontrolled gap. That interpretation is consistent with descriptions from Goldratt Research Labs and TOCICO.

This also explains why an expedite item should consume a real slot or displace a normal item. If “urgent” silently adds WIP, the rope is decorative.

Start with the active feature count your collaboration pattern can credibly support. Then compare a combined limit with one extra slot, half again as much WIP, and twice as much. For example, if you believe the team can actively guide four features, the three combined limits are five, six, and eight.

When the starting active count is one, both “one extra slot” and “twice active work” produce a combined limit of two. That is not a contradiction. It is a reminder that these are rough conversation starters. Recovery time, starvation cost, and human context matter more than the arithmetic.

Percentiles give you two more candidates. Sort the observations from lowest to highest. The 50th percentile, also called the median, is the middle: the system was at or below that WIP level on half of the observed days. It is often abbreviated p50. The 85th percentile is the level the system was at or below on 85 percent of observed days. It is often abbreviated p85. For example, if the 85th percentile is 7, WIP was 7 or lower on roughly 85 out of every 100 observed days and higher than 7 on roughly 15.

These are descriptions of what happened, not probabilities that a proposed limit will work and not automatically the limits you should choose. First name what you measured, then interpret the percentile.

Historical actual WIP answers: how much WIP did this system carry in past daily snapshots? The level the system stayed at or below on 85 percent of days is a gentle limit; it changes only the unusually crowded days. The level it stayed at or below on half the days is a much stronger intervention; it should force a conversation often enough to change how the team works. After that meaning is clear, p85 and p50 are useful shorthand.

Items consumed during one protection or replenishment interval answers: how much must be ready so the constraint is unlikely to starve before the next refill? Here the 50th percentile protects a typical interval. The 85th percentile carries more inventory to protect 85 percent of historically similar intervals.

Those are different questions. Do not average the answers.

Historical data also ages. If item definition, staffing, workflow, agent use, or replenishment cadence changed, segment the history. An old queue is evidence that inventory existed. It is not evidence that people had capacity to handle it.

As a stable-system cross-check, use Little’s Law:

target WIP ≈ throughput rate × target cycle time

If a pod finishes four comparable features per week and wants a one-week average cycle time, a WIP candidate of eight deserves scrutiny. The equation is a consistency check, not a precision calculator for an unstable system.

This aligns with Daniel Vacanti’s emphasis on WIP, throughput, cycle time, and age as the core flow evidence in The Kanban Guide, and with Don Reinertsen’s warning that high utilization creates queues whose economic cost is routinely underpriced. I have made the same practical point in Why Focus on Flow Metrics? and AI Coding Moved the Bottleneck.

Think about the supermarket. If you shop once a week and consume four items a week, you need more on the shelf than if you shop twice a week. The team’s throughput did not change. The replenishment interval did.

With no data, estimate how many items the team will consume before the next replenishment, then compare one extra item, half again, and twice that amount. With data, compare the amount consumed in a typical interval with the amount that covered 85 percent of historical intervals. Once the meaning is clear, you can call those p50 and p85.

This is especially useful for Ready for Review, Ready for Test, and Ready for Release. Size the queue around what the receiving stage can consume during the protection interval. Better yet, put the waiting and active statuses under one combined limit so a full queue stops upstream starts.

Here is an anonymized example from a real board. I filtered out Epics because they are a different flow unit. Over 91 daily observations, Stories and Bugs had current WIP 21. WIP was 23 or lower on half the days (the 50th percentile, or p50), 26 or lower on 85 percent of the days (the 85th percentile, or p85), and reached a peak of 33.

The workflow and WIP regime changed during the period, so I also looked at the 36 days from June 17 through July 22. In that window, WIP was 23 or lower on half the days and 24 or lower on 85 percent of the days. The peak was 26, and current WIP was 21. I would treat 23 as a data-only system experiment, not yet a recommendation.

For the same recent window, the combined-column 50th-percentile (p50) candidates were:

The 50th-percentile stage candidates happen to sum to the system’s 50th-percentile WIP of 23. Do not turn that coincidence into a rule. Stage percentiles do not normally add to a system percentile because their peaks can occur on different days.

Before using 8 / 3 / 6 / 6, I would ask: How many human collaboration pods can really carry development? Who reviews? How often can QA and UAT replenish? Is release cadence responsible for the inventory at the right edge? If UAT can release only weekly, the queue conversation is different from a team that can release continuously.

I have recommended this board pattern for years: keep the active state and the downstream Ready state distinct, but put both under one combined WIP limit.

Examples:

• In Progress + Ready for Code Review
• Code Review + Ready for QA
• In QA + Ready for UAT
• UAT + Ready for Release

This controls the work owned by the receiving stage, including the work it has completed but the next stage has not yet pulled. It also avoids the loophole where a team “finishes” work into an unlimited queue.

REAL JIRA EXAMPLEActive + Ready under one column limit

Jira applies the column maximum to the combined count and can still show the mapped statuses as separate drop zones when a card moves into the column. Atlassian documents both the combined column constraint and the separate status drop targets. The maximum is a visual signal, not a hard gate. The team still needs an explicit pull policy when the column is full.

The frameworks shape the workflow. They do not set capacity.

Spec Kit

Start with one solo feature moving through Spec → Plan → Tasks → Implement. Parallel research, task fan-out, and outputs waiting for human input all remain inside that feature. The Spec Kit documentation gives you durable artifacts that make the WIP policy executable: count active feature directories/specs, not the agents or tasks inside them. Consider a second feature only when the first is progressing through a truly autonomous goal loop and there is no useful same-feature or right-to-left work to pull.

Compound Engineering

The Compound Engineering loop moves through Brainstorm, Plan, Work, Simplify, Review, and Compound. Multi-agent review is fan-out on one result, not another feature slot. If the agent is working autonomously, use the time to simplify, review, compound, or finish something already in flight before starting another feature.

BMAD

BMAD offers many specialist agents and Party Mode. Personas are roles, not end-to-end pods. One solo human with twelve available personas still starts with one feature. In multiplayer mode, two trios that independently steer features start with two active slots. Each pod can test a second slot later if its agents are genuinely autonomous and the added context pays off. If both trios need the same architect or product owner for every decision, that shared queue may lower the useful limit.

Superpowers

The Superpowers subagent-driven development skill uses fresh implementer and reviewer agents while explicitly avoiding parallel implementers and clearing review before the next task. That is a useful orchestration policy inside the feature. It does not create a second WIP count alongside feature WIP.

Matt Pocock’s skills

Matt Pocock’s skills compose specification, tickets, implementation, and review. Standards and Spec review agents may inspect one diff in parallel, but they converge into one human decision. The tickets, implementation branches, and review outputs are activity inside one feature flow. They do not justify pulling a second feature by themselves.

The common pull rule is simple: count the feature once, define the limit, and define what happens before anyone starts another feature. First, find useful work inside the feature the agent is already advancing. Second, work the board right to left: review, test, repair, simplify, generate evidence, integrate, release, inspect telemetry, or stop obsolete work. Only then consider another feature, and only when the current agent loop is genuinely autonomous.

We are a team of six. What number should we put on the board?

First ask how the six people collaborate. If they work as one swarm, start with one active feature and one protective slot, for a combined limit of two. If they work as two independent trios, start with two active features and compare combined limits of three or four. If they work as three stable pairs, start with three active features and compare four, five, or six. If everyone feeds one reviewer, set the review constraint first—often 1 Reviewing + 1 Ready = 2—and let it govern upstream pull. Test a second feature per pod only after autonomous loops and flow evidence justify it.

I work alone with several agents. Is a WIP limit of one too conservative?

No. One actively guided feature is the right default. Agent tasks and waiting inputs inside it are still that one feature. When an agent is running autonomously toward a goal, first look for useful work inside the same feature, then work the board right to left to finish or learn from existing WIP. If those options are exhausted, test a second feature. Keep it only if the efficiency gain outweighs context reload, forgotten details, stale outputs, merge churn, rework, and quality loss.

Our agents can generate code much faster than review. Should implementation get a bigger limit?

No. That feeds the constraint. Limit Ready for Review + Reviewing around reviewer consumption, then use idle implementation capacity to prepare evidence, reduce change size, improve automated checks, repair failures, or help review. I cover this pattern directly in AI Coding Made Code Review the Bottleneck.

As I told one team in a recent private workshop, “Coding is ten times faster, but code review is still the same speed.” The exact multiplier will vary. The queue pattern is what matters.

We already have WIP of 15. Should we set the limit to 15?

Only if you are comfortable with the current pattern. A limit of 15 will mostly document what the system already does. If people feel spread too thin and want to change, compare the WIP level the system stayed at or below on 85 percent of days as a gentle ceiling, the level it stayed at or below on half the days as a stronger intervention, and an aggressive experiment near half current WIP. If those historical levels are 13 and 10, I would discuss 13, 10, and 7-8, then ask which one is likely to create the behavior change the team actually wants.

What if requests arrive whether we have capacity or not?

Do not pretend the arrival queue can be blocked. Keep it visible and govern it with service and triage policies. Apply the strict limit to treatment/processing work. That is the distinction I make in How to Limit WIP When You Cannot Block Arriving Work Requests.

How long should we keep the experiment?

Usually two to four weeks, long enough to experience normal variation but short enough to change course. Watch throughput, cycle-time distribution, work-item age, starvation, blocked time, limit exceptions, review age, context-reload time, forgotten agent sessions, merge churn, rework, and quality. Raise the limit only when throughput improves and the other signals remain stable.

The prompt below asks about your workflow, collaboration topology, agent autonomy, shared human constraints, flow data, and replenishment cadence. It calculates all five candidates, recommends one starting configuration, and translates it into board and agent pull policies.

• Ask one or two questions at a time.
• Accept either a no-data path or a data-rich path.
• State assumptions and show arithmetic. Round fractional WIP up.
• Treat every number as a 2-4 week experiment, not a permanent truth.
• Ask whether I want to preserve today’s way of working or deliberately create more focus, collaboration, and continuous improvement. Do not recommend a lower limit unless I am willing to change what people do when it becomes full.
• Count the top-level feature/spec once throughout its flow. Agent tasks, worktrees, branches, pull requests, specialist personas, and outputs waiting for input are how that feature moves; they are not additional WIP items.
• Keep upstream and downstream Ready queues visible and limited separately where useful, while allowing a combined Ready + Active limit around a constraint.
• Treat human attention as the governing capacity. The human has one shared context across all the threads they are juggling, so every additional feature carries reorientation and quality cost even when every agent has its own context window.

First establish the work and workflow:

1. What is the top-level work item: feature, story, defect, experiment, service request, or something else? Where does commitment begin and Done end?
2. List the workflow states. Classify each as funnel/backlog, Ready queue, active work, downstream waiting queue, or Done.
3. Do I want to preserve roughly the current amount of work in flight, or am I trying to change a pattern where people feel spread too thin? What should happen more often when the limit is reached: finishing, helping, reviewing, pairing, unblocking, or improving the workflow?
4. Which active stages require the same people to steer, review, integrate, or decide? Which can run independently end to end?

Then establish human-agent topology:

5. How many humans are involved, and how do they really collaborate: one swarm, pairs, trios, solo drivers, or several builders feeding a shared reviewer?
6. How many genuinely independent collaboration pods can take a feature from a pull point to the next meaningful Done state without repeatedly borrowing the same human constraint?
7. Is the human actively guiding the agent, or is the agent pursuing a durable goal autonomously for a meaningful stretch? How long are the genuinely autonomous intervals?
8. While an agent works, what useful work remains inside the same feature? What existing downstream work could the pod finish or learn from by working the board right to left?
9. Which reviewers, architects, product decision makers, environments, or release gates are shared across pods?
10. Which agentic workflow is used: Spec Kit, Compound Engineering, BMAD, Superpowers, Matt Pocock’s skills, or another pattern? Are agents sequential roles, parallel perspectives on one item, or independent implementers in isolated worktrees?
11. How many branches, pull requests, deployments, and pending decisions does the feature create? Use these as coordination and aging signals, not as additional WIP units.

Then establish flow and replenishment evidence:

12. How often can each Ready queue be replenished? Use the supermarket question: how much must be on the shelf to reach the next realistic trip?
13. How quickly can the system recover from a blocker, absence, failed agent run, or urgent interrupt? How expensive is it for the constraint to run out of work?
14. If available, provide daily actual WIP history, throughput per period, cycle-time distribution, work-item ages, blocked time, and items consumed by the constraint per replenishment/protection interval.
15. Has staffing, work-item definition, workflow, agent use, or replenishment cadence changed enough to make the history stale?

Start with one actively guided feature per independent collaboration pod. Treat it as the first number to discuss. Then adjust it based on the behavior the team wants and the shared human constraint.

• Actively guiding AI is active work, much like coding; a fast or parallel agent does not make the human free.
• Before opening another feature, first pull useful work inside the same feature. Then work the board right to left: review telemetry, validate a live feature, review, test, integrate, release, or finish another item already in the system.
• Test a second feature slot only when the first is advancing through a true autonomous goal loop, the same-feature and right-to-left options are exhausted, and the human can absorb the context switch without quality loss.
• Lower the number if I say the team is spread too thin and wants to change that pattern. Explain what the lower limit should make us do differently when it becomes full.
• Leave the number close to current WIP only when preserving current behavior is intentional. Warn that an unchanged limit will not create new collaboration or improvement by itself.
• Cap the active count at any shared human attention, review, architecture, decision, environment, or release constraint.
• Never multiply by the number of agents, terminals, personas, or workflow phases.

For a solo practitioner, recommend 1 active feature as the starting point. A second can be a legitimate experiment when the current feature is running autonomously toward a durable goal for long enough to create real waiting time. Explain the analogy to a long build or mainframe job: keeping busy can improve efficiency, but every extra feature consumes the human’s one shared context window. Recommend returning to 1 when context reload, stale outputs, forgotten sessions, merge churn, review age, rework, or quality loss rises. Treat 3 as exceptional and evidence-dependent, not a normal target.

With no reliable history, take the active feature count you just identified and compare these combined active-plus-protective-buffer choices:

1. One extra slot — the leanest practical buffer. For four active features, the combined limit is five. Favor fast replenishment and recovery, reliable flow, and expensive aging or delayed feedback. Risk: the constraint may starve during ordinary hiccups.
2. Half again — balanced protection for moderate variability, dependencies, interrupts, or recovery time. For four active features, round 4 × 1.5 to a combined limit of six. Risk: some inventory may age without protecting the constraint.
3. Twice the active work — strongest heuristic protection. For four active features, the combined limit is eight. Favor slow replenishment/recovery, high variability, or very expensive constraint starvation. Risk: the largest queue, context load, aging, and feedback delay. Require a clear rope/pull rule.

With meaningful data, also calculate:

4. The 50th percentile: the observed level that half the measurements were at or below. After explaining it in those words, you may call it p50. For historical actual WIP, this is an interventionist ceiling that challenges roughly half the snapshots. For items consumed during a protection interval, it protects a typical interval while accepting more buffer depletion.
5. The 85th percentile: the observed level that 85 percent of the measurements were at or below. After explaining it in those words, you may call it p85. For historical actual WIP, this is a gentler ceiling that challenges roughly the highest 15 percent of WIP snapshots. For interval consumption, it protects through 85 percent of historically similar intervals, at the price of more inventory.

Do not lead with p50 or p85 when speaking to the practitioner. Explain the observed-day or replenishment-interval meaning first, then introduce the shorthand if it helps later comparisons. These percentiles describe the historical observations; they are not probabilities that a proposed limit will succeed. Do not average conflicting candidates. Explain what each one is answering and why they disagree. Historical WIP can include old queues and is not proof of human capacity.

Cross-check the candidate with Little’s Law when the system is stable:

target WIP ≈ throughput rate × target cycle time

Use matching units. Treat this as a consistency check, not precision engineering. In a brownfield system, also compare a deliberately aggressive experiment near half current WIP or batch size.

For each active stage:

• Identify the credible collaboration pods/cells that can perform and review the work.
• Choose an active limit from that capacity and the real downstream constraint.
• If an adjacent Ready state protects that activity, prefer a combined limit across Ready + Active while keeping the states visibly distinct.

For each queue:

• Funnel/backlog: do not treat it as committed WIP; govern it with selection and aging policies.
• Ready-to-start: size it to consumption until the next replenishment opportunity. With data, compare the amount consumed in a typical interval (the 50th percentile, or p50) and the amount that covered 85 percent of historical intervals (the 85th percentile, or p85). Without data, estimate how many items the team will consume before replenishment, then compare one extra item, half again, and twice that amount.
• Ready for Review/Test/UAT/Release: size it to what the receiving constraint can consume during the protection interval. Prefer a combined Ready + Active limit so the rope stops new upstream starts.
• Unblockable arrivals: keep the arrival queue visible and governed by service policy, but strictly limit actual treatment/processing work.

Clarify that positive flow slack is controlled additional WIP before the constraint. It is not capacity - 1. Keep capacity slack—available human attention for helping, reviewing, incidents, and improvement—as a separate policy.

For every recommendation, specify:

• The counted artifact: normally the top-level feature/spec or another explicitly chosen value-bearing work item. Name branches, PRs, deployments, and pending decisions as states or signals inside that item, not extra WIP units.
• The limit and whether it applies to one state, several states, one pod, or the whole system.
• The pull condition.
• What agents and humans do when the limit is full, in this order: progress the same feature; work right to left on existing WIP; review, test, repair, split, simplify, document, automate evidence, integrate, release, learn from telemetry, or stop obsolete work. Only then consider a new feature if an existing one is in a true autonomous goal loop.
• Override rules. An expedite consumes a slot or displaces another item; it never silently adds WIP.

When Jira is used, offer this implementation pattern where it fits:

• Map an active status and its downstream Ready status into one board column, such as In Progress + Ready for Code Review or Code Review + Ready for QA.
• Set the column maximum to the combined limit.
• Keep the underlying statuses distinct; Jira can present each as a separate drop target.
• Explain that Jira’s maximum is a visual signal, not a hard gate. The pull policy is still owned by the team.

Use these as examples, not universal recommendations:

1. Solo human actively guiding agents: start with one active feature and a combined limit of two. Test a second active feature only for a true autonomous goal loop after same-feature and right-to-left work is exhausted.
2. Six people as one swarm/pod: start with one active feature and a combined limit of two.
3. The same six as two independent trios: start with two active features and compare combined limits of three or four.
4. The same six as three independent pairs: start with three active features and compare combined limits of four, five, or six.
5. Several builders and agents feeding one reviewer: cap Reviewing 1 + Ready for Review 1 = 2, regardless of upstream implementation capacity.
6. Weekly replenishment at four items/week: the team needs about four items until the next trip; one extra gives a queue limit of five.
7. Twice-weekly replenishment at the same throughput: the team needs about two items until the next trip; one extra gives a queue limit of three.
8. Near-continuous replenishment: the team needs about one item; one extra gives a queue limit of two.
9. Brownfield actual WIP 15: compare an illustrative 85th-percentile level of 13, 50th-percentile level of 10, and aggressive half-WIP experiment 7-8.
10. Four active slots with illustrative history: compare +1 = 5, ×1.5 = 6, ×2 = 8, a historical 50th-percentile actual-WIP level of 5, and an 85th-percentile level of 7.
11. Real-data calibration: a 91-day Stories/Bugs history has current WIP 21. WIP was 23 or lower on half the days and 26 or lower on 85 percent of the days. In a more representative 36-day window, those levels are 23 and 24. Treat 23 as a data-only system experiment, then cross-check human capacity and release cadence.
12. In that real-data example, recent combined-column 50th-percentile candidates are 8 / 3 / 6 / 6 for Development, Review, QA, and UAT/release. Do not assume accumulated inventory equals capacity.
13. Solo Spec Kit, Compound Engineering, or BMAD: start with one feature flow. Tasks, phases, personas, and review agents stay inside that feature count. A second feature is conditional on true autonomous progress plus exhausted same-feature and right-to-left options.
14. Solo Superpowers or Matt Pocock skills: task sequences and parallel reviewers are orchestration inside one active feature. Their fan-out does not create feature capacity.
15. Two independent multiplayer pods: start with two active features; one shared reviewer can still cap downstream combined WIP at two.

Provide:

1. A workflow table with active and queue stages.
2. Whether the team wants to preserve current behavior or use a lower limit to create more focus, collaboration, and improvement.
3. The collaboration-pod topology, the distinction between active guidance and true autonomous goal loops, and the human constraint that caps it.
4. All applicable candidates with arithmetic and rationale.
5. One recommended starting configuration, including separate active and queue limits.
6. Why the other candidates were not selected.
7. Executable pull/rope policies for the board and agents, including the same-feature-first and right-to-left-before-new-work sequence.
8. A normal-week, absence, 2× agent-generation, slower-review, and changed-replenishment sensitivity check.
9. A 2-4 week experiment with explicit tighten, loosen, and redesign signals.

Tighten when work-item age, context-reload time, forgotten agent sessions, stale branches, review queues, merge churn, rework, or quality problems rise. Loosen only when throughput rises while those signals remain stable. Redesign the workflow when the same shared constraint keeps overriding every local limit.