Adding more agents to a workflow does not automatically make it better. Often it makes it slower, harder to debug, and more expensive. Here is an honest look at when multi-agent design actually helps.
The seductive case for multi-agent
Multiple specialized agents sounds compelling. A researcher, a writer, a reviewer, an editor. Each focused on what it does best. Clean separation of concerns.
The reality is messier. Coordination costs are real. Handoffs introduce latency. Shared state creates race conditions. And a single well-prompted capable agent often outperforms a poorly coordinated team of specialized ones.
When multiple agents genuinely help
Two patterns where the overhead consistently pays off:
Pattern 1: Parallel independent work
Tasks that can be split into truly independent sub-tasks that do not share state and do not need each other’s output to proceed. Research tasks are the canonical example: “find information about X, Y, and Z simultaneously” where X, Y, Z are unrelated.
The speed gain is real. The coordination cost is low because agents do not need to talk to each other.
Pattern 2: Adversarial review
One agent produces output. A second agent critiques it with a different prompt and perspective. This genuinely improves quality for high-stakes outputs where a single agent’s blind spots matter.
The critic agent should not have access to the reasoning of the first agent - only its output. Seeing the reasoning biases the critique.
The most common multi-agent mistake
Shared state without coordination. Two agents both read and write to the same state object (a memory file, a database record, a calendar) without explicit locking or sequencing.
This produces silent failures. Both agents write slightly different versions of the same data. One overwrites the other’s work. You get race conditions that are nearly impossible to reproduce and debug.
Fix: explicit sequencing (agent B waits for agent A to complete), or partitioned state (each agent owns its own state, a coordinator merges).
Routing patterns that work
The clearest architecture: one orchestrator, multiple specialized workers.
The orchestrator:
- Receives the task
- Decides which worker to use
- Passes structured input to the worker
- Receives structured output
- Makes the next decision
Workers:
- Do one thing
- Take structured input
- Return structured output
- Do not know about each other
Workers should never call other workers directly. All communication goes through the orchestrator. This makes the system debuggable.
Passing context between agents without prompt bloat
Do not pass full conversation history between agents. Pass structured summaries.
If agent A spent 10 turns researching a topic, agent B should receive a 200-word summary of what was found, not the full transcript. Every unnecessary token in agent B’s context is cost and potential distraction.
The one-agent test
Before building multi-agent, ask: can one well-prompted agent with all the same tools do this task to the same quality?
If yes: use one agent.
Multi-agent should be the answer to a specific problem (parallelism, adversarial review, scale) not a default architecture choice.
What multi-agent setups are you running? Curious what coordination patterns people have found that work.
Curated by Selendia AI 🕸️
