Multi-agent is the current default answer, and it's often the wrong one. Every additional agent adds a handoff, and every handoff loses context, adds latency and creates a new place for things to go wrong. Complexity should be earned.
The test: does it need different tools, or a different job?
Split into separate agents when at least two of these are true:
- Different tool sets. One needs write access to the CRM; another only needs to search documents. Separating them means the researcher physically cannot modify a record.
- Different success criteria. A drafting agent is judged on tone; a QA agent on catching errors. A single prompt optimising both does neither well.
- Different data sensitivity. One touches customer PII, another doesn't. Separation is your access boundary.
- Genuinely parallel work. Five independent lookups can run at once instead of sequentially.
If none of that applies, you want one agent with more tools. "It feels more organised" is not an architecture.
A shape that works
When a split is warranted, this structure has held up well for us:
- Orchestrator. Owns the plan and the state. Delegates, never does the work itself, decides when the job is done or needs a human.
- Specialists. Narrow scope, minimum tools, one clear output contract each.
- Reviewer. Sees the specialist's output and the original requirement, and can send work back exactly once before escalating. This single component catches more errors than any prompt tuning.
Note what's absent: agents talking freely to each other. Free-form agent chat is where token budgets go to die. Structured handoffs through the orchestrator, with typed outputs, stay debuggable.
Pass state explicitly
Don't rely on conversation history as shared memory. Keep an explicit state object, the task, findings so far, decisions made, open questions, and pass the relevant slice to each specialist. Then any single step can be replayed in isolation when something goes wrong, which is the only way these systems are debuggable at all.
If you cannot re-run one step of your agent system in isolation, you do not have an architecture. You have a very expensive guess.
Budget the loop
Every agent system needs hard limits: maximum steps, maximum tool calls, maximum spend per task, maximum wall-clock time. Hit any ceiling and it stops and escalates with what it has.
Without ceilings, two agents will eventually hand work back and forth in a polite loop until someone notices the bill. We've seen it. Set the limits on day one.
Evaluate before you tune
Build a set of 30–50 real tasks with known good outcomes before optimising anything. Run the whole system against it after every change. Without that harness, every prompt edit is superstition, you fix one case and silently break three.
Start with one
Our default sequence: build one agent with all the tools. Find where it actually fails. Split off exactly the piece that failed. Repeat only when the evidence demands it.
Most production systems we run in anger end up with two or three agents plus a reviewer. Almost none need seven.
Put this to work
Want this built, not just read?
Tell us the workflow that's eating your week. Thirty minutes, no deck.