When You Actually Need Multiple Agents (and When You Don't)
The honest starting question isn't "how do we build a multi-agent system" — it's "does this task actually need one." A task earns a multi-agent architecture when it decomposes into genuinely independent sub-steps: research that's separate from drafting, drafting that's separate from review, review that's separate from execution.
If a single agent with the right tools and a well-scoped prompt could do the whole task in one continuous session, adding more agents usually adds token cost, latency, and handoff failure points without adding real capability. Most production failures we've seen trace back to teams reaching for multi-agent complexity before they'd proven a simpler version couldn't do the job.
Key takeaway: complexity should be earned by a named limitation of the single-agent version, not assumed because "multi-agent" sounds more sophisticated.
The Core Pattern: Orchestrator, Workers, and an Evaluator
The pattern that holds up in production is simple: an orchestrator agent breaks the task into sub-steps and assigns them, one or more worker agents execute each sub-step with narrow, specific tooling, and an evaluator checks output against a defined standard before it moves forward or reaches a human.
orchestrator.plan(task)
-> worker_research.run(subtask_1)
-> worker_draft.run(subtask_2, context=research_summary)
-> evaluator.check(draft, criteria)
-> if pass: worker_execute.run(final_action)
-> if fail: worker_draft.retry(feedback, max_attempts=2)The evaluator step is the piece teams skip most often, and it's the one that catches a bad draft, a hallucinated fact, or an incomplete task before it becomes a customer-facing mistake. For engagements where we build this end-to-end, our Claude agent development work centers on getting this evaluator step right, not just the happy-path orchestration.
Designing Handoffs So Agents Don't Silently Drop Context
Passing the full conversation transcript between agents feels safe — nothing gets lost — but it multiplies token cost with every handoff and often buries the one fact the next agent actually needs under everything else that was said. A structured handoff (a short summary object: decisions made, open questions, next required action) is both cheaper and more reliable.
This is the same discipline covered in our guide to reducing Claude API costs — multi-agent systems are exactly where uncontrolled context growth turns into a real bill, since every handoff is a new call with its own input tokens.
Working on something like this? See our Claude Agent Development →
A Worked Example: Lead Research and Outreach Drafting
A common, well-scoped use case: a research agent pulls public information on a prospect and summarizes relevant context, a drafting agent writes a personalized outreach email from that summary, and an evaluator checks the draft against a tone and accuracy checklist before it reaches a human for final approval.
Each agent has a narrow job and a small, specific toolset — the research agent doesn't draft, the drafting agent doesn't fact-check itself. That separation is what makes the evaluator's job tractable: it's checking one clear thing against one clear standard, not judging an entire end-to-end process at once.
Where These Workflows Break in Production
The most common production failures aren't reasoning errors — they're unbounded retry loops (a failed evaluation triggering endless re-drafts with no cap), unmonitored cost (a workflow that quietly triples in token spend as inputs grow), and silent handoff failures where one agent's output doesn't match the format the next agent expects.
Guardrails that matter in practice: a hard retry cap per step, cost and latency alerting per workflow run, and schema validation on every handoff so a malformed output fails loudly instead of propagating a bad result downstream.
Build vs. Manage: Running This Yourself vs. a Managed Agent
| Factor | Build and Run In-House | Managed Agent Engagement |
|---|---|---|
| Team has ML/agent engineering capacity | Good fit | Optional |
| Workflow is core to revenue or customer-facing | Needs dedicated ownership | Good fit for ongoing tuning |
| One-off internal tool, low stakes | Good fit | Often unnecessary overhead |
| Need for ongoing monitoring and iteration | Requires internal process | Built into the engagement |
If you'd rather have engineers who build and monitor this ongoing, hiring a Claude agent engineer is the more direct path than assembling this in-house from scratch. And once a workflow like this is live, pairing it with an internal knowledge base gives your agents a reliable source of truth to retrieve from instead of relying only on what's in a single conversation.
