Not the above person, and I usually max out around 5 although I have definitely had 10 or more at some point.

Assuming I'm working on one repo, I'll have different worktrees, each for a related area. For example, one worktree for each of: ui, small bug fixes, feature A, feature B, and so on.

Each worktree will have one active write agent, but I have a special docs/plans folder where I can have additional agents doing research and saving their findings. Agents in "plan mode" are write restricted to just that folder.

So look at a bug fix worktree. I could easily have 5 agents doing RCA into various bugs, each in plan mode. One at a time will get promoted to write mode to fix its specific bug while I continue discussion/RCA with the others. After fixing several bugs I'll spin up a "quality pass" agent that will make sure all tests/lint etc. pass and then give me a list of touched surfaces to manually verify before merging the branch and closing the worktree.

Note, I'm working solo at the moment so there's no PRs needed, but it would look quite similar if I had to make a PR for each bug fix, just probably with more worktrees.

We have a skill that takes a well defined Jira ticket and basically drives it to completion until it produces a human-review ready PR. This process is coded into a bunch of gates that the agent needs to clear before it can advance to the next stage, like fully understanding of the context/problem, fully solidified design (or several), implementation, critic review, submit PR, address CI issues and automated review comments etc.

In practical terms it often means that you can give the agent a ticket and it'll work on it for several hours until the PR is ready. Occasionally it'll run into some question that it needs you to clarify something or make some directional choice, but overall it's pretty autonomous.

Because this takes so long, you normally run 3 or 4 of those in parallel.

Then between shepherding those session, you also run several PR review sessions at the same time. Those also run for quite some time when doing deep investigations.

And then you also have long running discovery/design sessions for various other projects or problems you're working in between.

Some tasks could take a while, especially with /goal mode. At work we often have multiple agents running on different tasks, and each could spawn subagents that you may or may not want to track. With the herdr skill you can have subagents be managed via tabs or panes, which gives them more visibility and could also explode your terminal :)

Say you have something easily paralelizable, like 150 decompiled binaries, and you want to produce documentation for what each does. You can run 50 subagents in parallel (eg. kimi swarm) to analyze it all in a few minutes in 3 batches instead of doing it serially which would take half a day.

Lower-priority backlog items. TODOs atop your new PRs. Code reviews. Exploratory work where you can discuss a design sync and then dispatch one or more agents to prototype async. Any workstream where you can define a loop and let the agent hill-climb towards the goal.

A lot of this is personal taste but the general thing I get most value from is asking an agent to speculatively build every idea, instead of writing down ideas in some backlog for later (it never happens later).