The default answer
You probably need one agent with better tools. Multi-agent architectures are frequently proposed because they sound sophisticated, and they add real cost, latency and failure modes. Split only when the parts genuinely need different context or different capability.
Orchestration is fashionable and frequently unnecessary. This is a practical test for whether your workflow actually needs it.
What each additional agent costs you
| Cost | Why it appears |
|---|---|
| Latency | Sequential calls compound; each adds seconds |
| Token cost | Context passed between agents is paid for repeatedly |
| Failure surface | Every handoff is a place the chain can break |
| Debugging difficulty | A wrong answer could originate anywhere in the chain |
| Error compounding | A small misunderstanding early becomes a large one late |
| Evaluation complexity | You must score each stage, not just the outcome |
Error compounding is the failure mode teams underestimate. If each agent is 90% reliable, a four-agent chain is roughly 65% reliable end to end. Adding agents to improve quality frequently reduces it, because each handoff is another opportunity to lose or distort information.
The test
Split into multiple agents only if you can answer yes to at least one:
- Different context requirements. One stage needs a large document corpus, another needs live system data, and loading both into one context is wasteful or impossible.
- Different capability tiers. One stage genuinely needs your most capable model; others are fine on something cheaper and faster.
- Genuine parallelism. Independent subtasks that can run simultaneously, where the latency saving outweighs the coordination cost.
- Separation of concerns for review. A distinct verification step that must not share the generating agent's context, so it checks rather than confirms.
- Different permission scopes. One stage acts with elevated rights that should not be available to the rest of the workflow.
"It feels more organised" is not on that list. Architectural tidiness that costs latency, money and reliability is not tidiness — it is decoration.
Patterns that genuinely work
| Pattern | Structure | Good for |
|---|---|---|
| Router | Classify, then dispatch to a specialist | Varied request types |
| Generator + verifier | One produces, another checks independently | Quality-critical output |
| Pipeline | Sequential stages with defined handoffs | Genuinely staged work |
| Parallel fan-out | Independent subtasks, then merge | Research across sources |
| Supervisor | One plans and delegates dynamically | Genuinely variable workflows |
The router and the generator-verifier pair carry most of the practical value. The supervisor pattern is the most flexible and the hardest to make reliable — it is where multi-agent systems most often become unpredictable.
The verifier pattern, specifically
Worth calling out because it is the one that reliably improves quality rather than just adding structure.
- A second agent evaluates the first's output against explicit criteria.
- It must not share the generating agent's reasoning context, or it will agree with itself.
- Failed checks trigger a retry with specific feedback, not a blind regeneration.
- Retry count is capped, so a stubborn failure escalates rather than looping.
Before building a verifier agent, try deterministic checks. Schema validation, business rule checks, and range assertions catch a large share of errors at a fraction of the cost and with none of the ambiguity. Use an LLM verifier only for what code cannot check.
Making it debuggable
Non-negotiable for anything beyond two agents:
- Trace every step — which agent, what input, what output, how long, what cost.
- Correlate by request ID across the whole chain.
- Record handoff payloads, since information loss between agents is a common failure.
- Score stages independently, so a quality drop is attributable.
- Set global limits — total steps, total cost, total time — so no workflow can run away.
A sensible progression
- Start with one agent and good tools. Most workflows never need more.
- Add deterministic verification — code checks, not another model.
- Add a router if you have genuinely distinct request types.
- Add a verifier agent only where deterministic checks cannot cover the quality bar.
- Consider full orchestration only with measured evidence that the simpler structure could not deliver.
Designing an agentic workflow and unsure how much structure it needs? Describe the steps involved — we will say plainly if one agent would do. See our agentic AI service, agentic vs chatbot, and tool use explained.