Multi-agent systems: when they help and when they hurt
A multi-agent system splits a task across several agents, each with its own instructions, tools and context, usually coordinated by an orchestrator agent. It helps when parts of the task can run in parallel, when each part needs a very different set of tools or expertise, or when one agent's context would get too full. It hurts when the parts depend closely on each other, because agents lose information when they hand off, make conflicting decisions, and multiply cost. Start with one agent with good tools, and split only when you can show a single agent is the bottleneck.
What a multi-agent system is
Instead of one agent with many tools and a long list of instructions, you have several agents, each focused on one job. A research system might have a lead agent that plans and several sub-agents that each search a different topic. A job application assistant might have one agent that reads the job post, one that analyses the resume, and one that writes the tailored version.
They communicate by passing messages or results, often through an orchestrator that assigns work and combines results.
When multiple agents help
- Parallel work: several independent sub-tasks, like researching ten companies, can run at the same time, which reduces total time.
- Separate context: each sub-agent works in its own clean context and returns only a short summary, so the main agent's context doesn't fill with every search result.
- Specialisation: very different jobs, like writing SQL and writing marketing copy, benefit from different instructions, tools and even different models.
- Different permissions: an agent that reads sensitive data can be separate from an agent that sends emails, which limits what a single manipulated agent can do.
Anthropic described this in their multi-agent research system: a lead agent plans and launches sub-agents that search in parallel, and on their internal research evaluation, the multi-agent setup outperformed a single agent by a large margin on broad research questions.
When multiple agents hurt
- Cost: more agents means more model calls, more context resent and more tokens. Anthropic reported that their multi-agent research system used about 15 times more tokens than a chat interaction.
- Lost information: every handoff is a summary, and summaries drop details one agent knew and the next one needed.
- Conflicting decisions: agents working in parallel on related parts, like different parts of the same codebase, can make choices that don't fit together.
- Harder debugging: a failure might come from any agent or from the communication between them.
- More things to evaluate and monitor.
Teams building coding agents have argued against multi-agent designs for tasks like writing code, where every decision depends on the others and a single agent with a well-managed context works better.
Common architectures
Orchestrator and workers
A lead agent breaks the task into sub-tasks, assigns them to worker agents, and combines their results. The most common and usually the easiest to reason about.
Sequential pipeline
Agents run in a fixed order, each taking the previous one's output: researcher, then writer, then reviewer. Predictable, and really a workflow where some steps are agents.
Hierarchical
Managers with sub-managers and workers, for very large tasks. Powerful and complex, rarely needed.
Peer-to-peer or group chat
Agents talk to each other directly or in a shared conversation, deciding among themselves who acts next. Flexible, and the hardest to control and debug.
Designing a multi-agent system
- Give each agent one clear responsibility and its own tools.
- Define what each agent returns, in a structured format, so handoffs don't depend on free text.
- Pass the original goal and constraints to every agent, not only the sub-task, so they don't drift.
- Limit the number of agents, steps and total spend for the whole task.
- Trace the whole run, so you can follow every agent's decisions.
- Evaluate the system end to end, and each agent on its own job.
A simple test before splitting
Build the single-agent version first, with good tools and context management. Measure where it fails. If failures come from a context that's too full, tasks that could run in parallel but don't, or one agent juggling tools that confuse it, then try splitting that part out, and compare the results and the cost.
From the floor
In the CrewAI workshop, we built a job application assistant as a multi-agent system: it pulled the job description from a URL, read the candidate's resume from a PDF, and worked out how to tailor the resume to the job, with separate agents for each part and Gemini's free API through Google AI Studio as the model. CrewAI is designed for exactly this kind of crew of agents, each with a role, and it's open source.