Hisham AlhussainEvery few weeks someone shows me an architecture diagram with six agents on it. A planner agent, a researcher agent, a writer agent, a critic agent, a manager agent to coordinate them all, and usually one more for good measure. It looks great on a slide.
And then I ask, "Have you tried just one agent with good tools?" Usually the answer is no.
Why I default to one agent
A single agent with a solid set of tools and good context has some big advantages:
- It sees everything. No information gets lost when passing work from one agent to another.
- It's easier to debug. One trace, one loop, one place to look when something goes wrong.
- It's cheaper. Multi-agent setups often use several times more tokens, since every agent needs its own context.
- Fewer moving parts. Every handoff between agents is another place where things can break.
Most of the time when someone builds multiple agents, what they really needed was better tools or better context for one agent.
When multiple agents actually help
That said, there are real cases where splitting things up wins. Here are the ones I've seen hold up:
- Parallel exploration. If you need to research ten things at once, sending out several sub-agents in parallel and combining their results is fast and works well. Each one gets a clean context for its piece.
- Protecting the main context. A sub-agent can dig through a mountain of logs or documents and return just a short summary. The main agent stays focused instead of drowning in detail.
- Different permissions. If one part of the task needs access to sensitive systems and another reads untrusted content, separating them into agents with different tool sets is a good security boundary.
- Truly different jobs. When the tasks share very little context and need different instructions, splitting them can be cleaner.
My rule of thumb
Start with one agent. Only split when you can point to a specific problem: the context is getting too big, the work could clearly run in parallel, or you need a security boundary. "It feels more organized" isn't a good enough reason.
When I do split, I keep it to a simple pattern: one main agent that hands off well-defined tasks to sub-agents and gets back short, structured results. I avoid agents chatting freely with each other. That tends to turn into an expensive group chat that goes in circles.
Be clear about handoffs
If you do go multi-agent, the handoffs are where most bugs live. Be very explicit about what each sub-agent receives and what it must return. Treat it like an API contract: clear inputs, clear outputs, and validation on what comes back.
Multi-agent systems can be powerful. But a single agent with great tools is underrated, and it's almost always where I'd start.