The phrase "multi-agent system" now gets used for everything from two prompts calling each other to full simulated company org charts. Most of what ships in production is closer to the first.
A useful multi-agent setup is a handoff contract between narrow specialists. Each agent has a job description, a small set of tools, a clear input contract, a clear output contract, and a rule for when it must stop and return control. The "multi" part is just the routing logic that decides which specialist gets the next piece of work.
Single agent vs. multi-agent - when the split is worth it
| Situation | Single agent is enough | Split into multiple agents |
|---|---|---|
| Task has one clear skill (summarize this doc, draft this email) | Yes | No |
| Task branches into genuinely different expertise (legal review vs. financial model vs. outreach copy) | No | Yes |
| One agent starts forgetting earlier steps after 6 turns | Maybe add memory first | Split only if memory fix fails |
| Handoff requires a human decision (money, legal commitment, brand voice) | Keep human in loop | Add agent only for the part before the human gate |
If your single agent is already reliable on the narrow task and the only problem is "it tries to do two things at once," splitting usually helps. If the problem is "it hallucinates facts" or "it forgets the goal," splitting rarely fixes it.
The minimal viable handoff contract
Every handoff needs four lines written down before you code anything:
- Trigger condition: what output from agent A causes B to run?
- Input package: exactly what data B receives (not "the context," the actual fields or files).
- Success signal for B: what does "done correctly" look like in one sentence?
- Escalation rule: when does either agent stop and flag a human?
Example for a customer inquiry that might be technical or billing:
Trigger: triage agent outputs category "technical" or "billing" with confidence > 65.
Input to specialist: the original message text, the customer tier from CRM, the last three resolved tickets with same keywords, and the relevant policy snippet.
Success for specialist: a draft reply that cites the exact policy line or known bug status, offers next step with date or link, and does not promise anything outside the policy.
Escalation: if confidence < 65 or amount > $200 or customer tier is enterprise, return to human with the draft plus the three facts that drove the low confidence.
Without those four lines written, the agents will invent their own handoff rules and you will debug routing bugs for days.
A real three-agent pattern that works
1. Intake / triage (reads the raw request, pulls relevant context, decides bucket or flags for human).
2. Specialist (one per major bucket - e.g. code-debug agent, policy agent, content-draft agent).
3. Review / formatter (takes specialist output, applies house style, checks guardrails, produces final deliverable or escalation).
The review agent is often the one people skip. It is also the one that prevents the "agent wrote something that sounds nothing like us" problem.
See the [Multi-Agent System Designer](https://auth.mane.dev?site=aiagentstudio&template=multi-agent) and the [AI Agent Setup Blueprint](https://auth.mane.dev?site=aiagentstudio&template=agent-setup) for the exact field templates.
Why most multi-agent demos stay demos
- They give every agent access to every tool "just in case."
- They have no numeric confidence threshold - the triage agent always picks something.
- The handoff is "pass the whole chat history" instead of a minimal structured packet.
- There is no stop condition, so the loop runs until token limit or the user gets bored.
Add the four-line contract and a "human gate on anything that touches money or external send" and the demo suddenly looks like a boring but reliable internal tool.
One-week test before you trust the handoff
Day 1-2: Run the full flow on 10 historical examples with known correct answers. Log every handoff decision and whether the final output was right.
Day 3: Add the numeric thresholds and the minimal input packet. Re-run the same 10.
Day 4: Shadow mode on live traffic - generate but do not act. Compare to what a human did.
Day 5-7: Let it act only on the narrow low-stakes bucket with human review still required. Measure error rate on the handoff itself, not just final quality.
If the handoff decision is wrong more than 8% of the time on day 7, you do not have a multi-agent system yet. You have two prompts arguing.
The [Multi-Agent](https://auth.mane.dev?site=aiagentstudio&template=multi-agent) tool on aiagentstudio.pro forces you to write the contract before it generates the prompts. That is the part that actually makes the system survive contact with real work.