Beans is great.
> During my analysis, the main issue I found with most agentic coding tools right now is that they all focus on one thing: running as many agents in parallel as possible. But why? Why run 10, 100, or even 1000 agents when you are unable to write enough tickets for them to consume?
> Maybe I’m wrong. Maybe I should be running hundreds of agents in parallel, but I can’t honestly say I’ve ever run more than 2 at a time. Both working on separate tasks, and I spent most of my time not in setting up and running agents, but in defining the work that needs to be done. Also, the context switching from managing two agents was exhausting.
Your confusion here comes from the idea that the agents all work on completely different tasks. Much if not most of the time, it's about speeding up one task by deploying multiple agents in parallel.
Some people prefer waterfall-like flows with big tasks, where a large amount of time is spent on planning up front, and then run them this way. Obviously there's upsides and downsides to this, but it's a common approach.
Another reason is money. Opus especially loves to start of with 150 context-gathering tool calls, which is a huge waste of money and time compared to 3 Haiku agents (or even cheaper models) doing this part in parallel.
