Splitting one agent into five does not make the system smarter. It makes it more debuggable - or more chaotic, depending on whether you had a reason.
The four tests
Answer these before designing a crew. Two or more yeses justify multiple agents.
1. Context test. Does one prompt need more instructions and tools than the model reliably follows? (Symptom: adding a rule makes an unrelated rule stop working.)
2. Tool test. Do different steps need different tool permissions - one read-only researcher, one that can write to your CRM?
3. Ownership test. Will different people own different steps, with different review standards?
4. Model test. Would some steps be dramatically cheaper on a small model, and a few need the expensive one?
All four no? Write one prompt with a clear output schema. You will ship this week instead of next month.
What multi-agent actually costs
| Cost | Why it bites |
|---|---|
| Latency | Sequential handoffs multiply round trips |
| Debuggability | A wrong final answer could come from any hop |
| Error compounding | 95% accuracy at four steps is 81% end to end |
| Prompt drift | Five prompts to keep consistent instead of one |
That third row is the one teams underestimate. Reliability multiplies, so the fix is fewer hops and a validation gate at each one - not more agents.
The shape that usually works
An orchestrator that routes, specialists that do one thing each, and a validator before anything leaves the system.
```
orchestrator
├── researcher (read-only tools, cheap model)
├── analyst (no tools, expensive model)
└── writer (templates, cheap model)
↓
validator (schema + policy check, deterministic where possible)
```
Specialists never call each other directly. Every hand-off goes through the orchestrator, so there is exactly one place to log, retry, and reason about state.
Make hand-offs typed
The most common multi-agent bug is a specialist returning prose where the next step expected fields. Define the payload between every pair of agents as a schema and validate it in code, not by asking the next model nicely to cope.
Stop conditions are not optional
Every agent needs a maximum step count, a maximum spend, and a defined failure output. An agent with no stop condition does not fail - it loops, quietly, at your expense. Write the escalation path too: what happens when the validator rejects three times in a row, and which human sees it.
Sketch yours with the [Multi-Agent Designer](/multi-agent) before writing code.