Agentic Orchestration & Multi-Agent Best Practices
A checklist for designing reliable, cost-bounded multi-agent architectures: when to reach for multiple agents at all, how to design the orchestrator/worker split, how to delegate work in parallel, how to choose between chaining and routing, and the guardrails, error recovery, evaluation, and ADR discipline that keep a multi-agent system safe to run in production.
How to Use This List
- Work through the groups in order the first time you design a multi-agent workflow; later groups (guardrails, evaluation, ADR) assume you've already made the decisions in the earlier ones.
- Treat Group A as a gate, not a formality. If a task doesn't pass the decomposition test, stop there and build a single agent instead.
- Use this as a design review checklist for any new orchestrator, not just a one-time reference; revisit it whenever a workflow's task mix, cost profile, or failure rate changes.
- Each item links back to the page in this section that explains the reasoning and shows working code.
A - When to Reach for Multi-Agent At All
- Start every task as a single agent and prove it insufficient before splitting it. A single tool-calling loop is sufficient for most tasks; multi-agent is the exception that has to earn its added complexity, not the default architecture.
- Reach for multi-agent when a task decomposes into independent, parallelizable subtasks. If you can describe the subtasks as parallel bullet points with no arrows between them, splitting across agents is worth considering; if the steps depend on each other's intermediate state, keep them in one loop.
- Reach for multi-agent when subtasks need specialized tool access or context, not to add ceremony. A subtask that should only ever read files, or that needs a narrower context than the rest of the task, is a legitimate candidate for its own agent even without parallelism, since tool scope in the Claude Agent SDK is set per agent.
B - Orchestrator/Worker Design
- Give the orchestrator one job: dispatch and merge, not the underlying work itself. An orchestrator configured with an empty tool list and only
subagentsset keeps its role unambiguous and stops it from quietly doing a worker's job. - Write each worker's description as specifically as a tool description. A vague
SubagentConfig.descriptiongives the orchestrator's model no reliable signal for when that worker applies, and it will either skip it or invoke it for the wrong subtask. - Specify the exact merge output shape in the orchestrator's prompt. Left vague, an orchestrator will default to pasting each worker's raw result back to back instead of synthesizing them; name the target sections, ordering, and length limits the same way you'd specify a function's return type.
- Scope each worker's tools independently of the orchestrator's and of every other worker. A worker inherits nothing automatically from the parent; grant it only what its specific job requires, not the union of everything the orchestrator can do.
C - Parallel Delegation
- Spin up one subagent per independent subtask, not one subagent doing several. Isolation per subtask keeps each worker's dead ends and exploratory tool calls out of the other workers' context, and out of the orchestrator's.
- Dispatch independent workers concurrently, not sequentially. Sequential dispatch of subtasks that don't depend on each other wastes the parallelism that was the reason to delegate in the first place.
- Sequence dependent workers explicitly when one needs another's output. Forcing parallel dispatch on a pair where the second worker actually needs the first's result produces a worker that's guessing at input it doesn't have yet.
- Have every worker report one final result back to the coordinating agent, not a stream of partial state. The orchestrator should be able to reason about what a worker found without reconstructing it from intermediate tool calls it never saw.
D - Chaining vs. Routing
- Use prompt chaining for a fixed, predictable sequence of steps. Chaining suits workflows where the next step is always the same regardless of input, and it's simpler to reason about and debug than a dynamic alternative.
- Use routing when the task type varies and the path forward is a dynamic decision. Routing suits variable task types where different inputs genuinely need different handling, not a workflow that's always the same three steps in disguise.
- Don't build a router for a workflow that never actually branches. An unnecessary routing decision adds a model call and a failure mode for a choice that was always going to resolve the same way.
- Don't force genuinely variable input through one fixed chain. Forcing everything through the same sequence produces wasted steps for inputs that didn't need them, or a chain that silently mishandles the cases it wasn't built for.
E - Guardrails: Depth, Tools, and Spend
- Cap subagent depth. Workers that themselves delegate to sub-workers multiply coordination overhead and make failures far harder to trace back to a root cause; most production systems cap delegation at one or two levels.
- Scope tool access to least privilege, per agent. Every enabled tool is additional surface area a runaway agent, orchestrator or worker, can act on unsupervised; scope decisions don't carry over automatically between agents.
- Set an explicit token or cost budget per task, not just per run. A synthesis step that reads every worker's full result into context can spend far more than any single worker did; cap total spend across dispatch plus merge, not just at the individual agent level.
- Treat depth, tools, and spend as one system of guardrails, not three separate controls. A shallow but tool-heavy agent can spend as much and cause as much damage as a deep, narrowly scoped one; review all three together when you design or audit a workflow.
F - Error Recovery
- Retry a failed tool call before escalating it as a task failure. Transient failures like rate limits or a flaky network call shouldn't fail the whole run; a bounded retry absorbs the common case.
- Define a fallback for a subagent that stalls or exhausts its retry budget. A simpler tool, a different worker, or a handoff to a human are all legitimate fallback paths; letting the orchestrator wait indefinitely is not.
- Apply a circuit-breaker pattern so one failing dependency doesn't cascade through the system. Once a worker or tool has failed enough times in a window, stop calling it and surface the failure instead of retrying forever and burning budget on something that isn't going to recover on its own.
- Log every failure and the recovery decision that followed it. Without a record of what failed and what kicked in afterward, you can't tell a genuinely flaky dependency from a systemic bug in your orchestration logic.
G - Evaluation Before Production
- Score task success rate on a representative task set before shipping. A repeatable evaluation process, not anecdotal spot checks during development, is what tells you whether the architecture actually works on the range of inputs it will see in production.
- Track cost per task alongside success rate, not success rate alone. A multi-agent design that succeeds more often but costs several times more per run per task may not be the right trade for the workflow; evaluate both together.
- Catalog failure modes, not just a pass or fail count. Understanding how a workflow fails, a stalled worker, a bad merge, a missed edge case, is what tells you which guardrail or fallback to invest in next.
- Re-run the evaluation whenever a prompt, model, or subagent's tool scope changes. An evaluation from before a meaningful change tells you nothing reliable about the system as it stands today.
H - ADR Discipline
- Write an ADR before committing to a multi-agent orchestrator for a workflow. Documenting the tradeoff between a single agent and a multi-agent orchestrator forces a deliberate decision at the point it's made, instead of an architecture that accreted one subagent at a time.
- Record what decomposition or specialization need justified the split. If you can't state the specific reason plainly in the ADR, the decomposition test in Group A probably wasn't actually met.
- Revisit the ADR when the workflow's task mix or cost profile changes materially. An architecture decision that was right at launch can become wrong as task volume, cost, or requirements shift, and the ADR is the record that tells the next person why it was made in the first place.
FAQs
When is a single agent still the right call, even if a task looks complex?
When the steps are sequential and depend on each other's intermediate state, no matter how many steps there are. Complexity in the reasoning doesn't require multiple context windows; only genuine independence between subtasks does.
What's the fastest way to tell if a task decomposes well enough for multi-agent?
Try to describe the subtasks as parallel bullet points with no arrows between them. If you can't do that without adding an arrow (subtask B needs subtask A's result), it isn't independent enough to split cleanly.
Should the orchestrator itself have tools?
Only if it needs to do something beyond dispatching and merging, such as writing the final result to a file. When its job is purely synthesis, an empty tool list keeps its role unambiguous and stops it from doing a worker's job itself.
What's the difference between chaining and routing in practice?
Chaining is a fixed sequence: step two always follows step one the same way. Routing is a dynamic decision: the workflow picks which path to take based on the input. Use chaining for predictable workflows and routing for variable task types.
How deep should subagent delegation go?
Cap it at one or two levels for nearly all production systems. Deeper delegation, workers that themselves spawn sub-workers, multiplies coordination overhead and makes failures much harder to trace back to a root cause.
What's the most common way multi-agent systems run away on cost?
An open-ended prompt that lets the orchestrator dispatch as many workers as it decides it needs, combined with a merge step that reads every worker's full result into context. Cap subagent count and token spend explicitly rather than leaving dispatch open-ended.
What should trigger a retry vs. a fallback vs. a circuit breaker?
Retry a single transient failure, like a rate limit. Fall back once a retry budget is exhausted or a subagent stalls outright. Trip a circuit breaker once a dependency has failed repeatedly in a window, so the system stops calling something that clearly isn't going to recover.
What does "evaluate before production" actually mean in practice?
Running the workflow against a representative task set and scoring task success rate, cost, and failure modes as a repeatable process, not just checking that it worked on the examples you happened to test by hand during development.
Does every multi-agent workflow need an ADR?
Any workflow where you're choosing a multi-agent orchestrator over a single agent should have one. The ADR is what documents the tradeoff and the specific decomposition or specialization need that justified the added complexity.
What's the biggest mistake teams make when they first adopt multi-agent?
Reaching for it by default instead of proving a single agent insufficient first. Most tasks stay single-agent; multi-agent earns its complexity only when a task genuinely decomposes or needs specialized tool access.
Can a single subagent break guardrails on its own?
Yes, if its own tool scope or spend isn't bounded independently. Guardrails apply per agent, not just at the top level; a narrowly capped orchestrator with an unbounded worker still has an unbounded system overall.
How do parallel delegation and orchestrator/worker design relate?
Orchestrator/worker is the role split, one agent dispatches and merges, others do the underlying work. Parallel delegation is a property of how that dispatch happens: independent workers running concurrently rather than one after another. You can have one without the other, but they're usually paired in practice.
Related
- Single-Agent Loops vs Multi-Agent Systems: A Mental Model - the decomposition test behind Group A
- Orchestrator/Worker Patterns with the Claude Agent SDK - the dispatch-and-merge design in depth
- Guardrails for Multi-Agent Systems: Bounding Cost and Scope - depth, tool access, and spend limits in depth
- Evaluating Agent Quality: A Checklist for Production Readiness - the evaluation process behind Group G
- ADR Template: Single Agent vs Orchestrator for a New Workflow - a template for the ADR discipline in Group H
- Claude Agent SDK Best Practices - the underlying SDK-level practices this section builds on
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the Claude Agent SDK (latest release). Model names, SDK versions, and pricing move quickly - verify current specifics at platform.claude.com/docs before relying on them.