Why Many Agents?
And when not to.
Juno keeps growing. Forty tools. A prompt that's ten pages long. And it's started to get confused, using the wrong tools, and mixing up rules. Sound familiar? A startup with one person doing every job has the same problem. The answer is the same as well. Specialise.

- Forty tools, ten pages of prompt
- It's getting confused
- Specialise
Why split an agent up
Splitting helps for four reasons. Each agent has a focused prompt, and only a few tools, so it makes better choices. Each one has a clean context, which isn't cluttered by other people's work. Each one can use a different model. And you can test each one separately. That's the upside.
The real cost
But be honest about the costs. Agents have to pass information to each other, and things get lost, just as in a company. There are more model calls, so it's slower and it costs more. Failures are harder to trace. Most teams that jump to many agents would have been better off with one good agent, and better tools.
Benefits
- Focused specialists
- Clean contexts
- Separate testing
Costs
- More model calls
- Information gets lost
- Harder to debug
When to go multi-agent
So when should you do it? Split when one agent has too many tools to handle, when jobs need clearly different skills, or when tasks can run in parallel. Keep one agent if a single prompt can handle it, or if the steps depend heavily on each other.
| Situation | Choice |
|---|---|
| Few tools, one domain | One agent |
| Too many tools | Split by domain |
| Parallel research | Several agents |
| Tightly linked steps | One agent |
| Separate teams own the parts | Split |
Summary
Split for focus, but only when you need to. There are two main ways of organising a team. The first has a boss.
Key takeaways- Specialists make better choices
- Communication has a cost
- Default to one agent