How Orchestrator and Subagents Divide the Work

A single coding agent is a capable pair-programmer, but it works strictly in sequence and shares one context window across the whole task. That breaks down when work is large or naturally parallel - a multi-service refactor, a coverage sweep across modules, or research spanning dozens of files. Agent teams solve this through a clear division of labour. An orchestrator agent holds the plan and delegates self-contained subtasks to subagents, each effectively a separate Claude Code instance with its own context, tools, and objective. The orchestrator rarely edits much code itself; it decomposes the request, decides what can run concurrently, spawns subagents with precise briefs, and reconciles what they return. Each subagent reports a concise summary rather than its full reasoning trace, keeping the orchestrator's context lean. Anthropic's engineering team describes this orchestrator-worker pattern as the backbone of their multi-agent research system, where a lead agent coordinates specialised subagents in parallel. The five steps below show how a well-run team moves a multi-part task from request to integrated, reviewable result.

Worktree Isolation: Why Agents Need Separate Workspaces

Running several agents against one working directory is a recipe for chaos: their edits collide, one agent's half-finished change breaks another's test run, and git state becomes impossible to reason about. The standard solution is git worktrees - a native git feature that checks out multiple branches into separate directories backed by the same repository. Each subagent gets its own worktree, its own branch, and its own clean slate. Anthropic's Claude Code documentation explicitly recommends worktrees for running multiple agents simultaneously, precisely because the isolation prevents agents from interfering with each other. Because the worktrees share one underlying repository, there is no need to clone the codebase repeatedly or duplicate dependencies, so spinning up a new isolated workspace is cheap. Changes are merged back only when an agent's slice is complete and reconciled, which preserves a clean, auditable history rather than an entangled mess of concurrent edits - and gives reviewers a tidy, branch-by-branch trail of exactly what each agent did.

• •A git worktree checks out a branch into its own directory while sharing one underlying repository.
• •Each subagent works in a dedicated worktree, so concurrent edits never overwrite one another.
• •Isolated test runs mean one agent's failing build cannot corrupt another agent's results.
• •Branches are merged back deliberately, keeping a clean and reviewable git history.
• •Worktrees are a native git capability, so the pattern needs no exotic tooling to adopt.

When Multi-Agent Beats a Single Agent - and When It Does Not

Multi-agent orchestration is not a universal upgrade. It earns its keep when work is genuinely parallel and the value of each subtask justifies the extra token spend - broad research, large refactors, or independent feature slices that touch different parts of the codebase. It is the wrong tool for tightly coupled work where every change depends on the last, because coordination overhead and merge conflicts then outweigh any speed gain; a single agent reasoning through the chain end to end is both cheaper and more reliable. Anthropic notes that multi-agent systems can burn around fifteen times the tokens of a single chat, so the economics only work when the task is high-value and divisible. A useful test before fanning out is to ask whether you could hand each subtask to a different engineer with no further conversation between them - if yes, the work is a good fit for an agent team. The comparison below helps decide which approach suits a given piece of work before you spin up a team.

Controlling Cost and Review Burden

The two real constraints on agent teams are token cost and human review capacity, and both must be managed deliberately. Because parallel subagents multiply consumption, the model-selection discipline we covered previously applies directly: route high-volume, well-scoped subtasks to a cheaper model like Sonnet, and reserve the frontier model for the orchestrator's planning and the genuinely hard slices. Over-buying - routing every subagent to the most expensive model - is the fastest way to make fan-out uneconomical. On the review side, more agents mean more diffs, so the orchestrator should consolidate work into a single coherent change set rather than handing reviewers a pile of disconnected branches. A consolidated review is also safer: it lets a human see how the parallel pieces fit together as a whole, catching integration issues that a branch-by-branch read would miss. It is worth budgeting for review capacity up front, because the speed of fan-out can outpace a team's ability to read the changes it produces. The statistics below put the cost reality in perspective and show why scoping matters before you fan out.

Common Mistakes When Adopting Agent Teams

Most failures with multi-agent orchestration are not model failures - they are process failures. Teams reach for parallelism on work that is not parallel, hand agents overlapping responsibilities, or let automation drift toward production without a human gate. The pattern is familiar to anyone who has managed a delivery team: when ownership is fuzzy and hand-offs are loose, coordination cost swamps the benefit of having more hands. The fix in each case is the same discipline that makes human teams effective - clear ownership, isolated workspaces, honest scoping, and a firm review checkpoint before anything ships. Treating the move from one assistant to a coordinated team as an organisational change rather than a tooling change is what separates the teams that get value from the ones that simply spend more tokens. The four mistakes below are the ones we see most often when organisations make that shift, each paired with the practical guardrail that prevents it.

Adopting Agent Teams Safely with Humans in the Loop

The governance principle that anchored our earlier articles on autonomous ticket resolution and model selection carries straight into multi-agent work: capability raises the stakes of getting oversight right. An orchestrator coordinating several subagents can move a large task quickly, but speed is only an asset when a person still reviews and approves what ships. The same human-in-the-loop discipline that keeps an autonomous ticket agent from deploying unreviewed fixes applies, only now there are several agents producing changes at once, which makes a clear consolidation and review step more important, not less. The teams that succeed start with a scoped pilot on one divisible task, keep every subagent's work on isolated branches, consolidate it into a single reviewable change, and gate production behind a human. They also build an audit trail - which agent touched what, and why - so the work can be reconstructed later. This is exactly how Tech Arion approaches AI development and agent engineering: building orchestrated agent workflows for clients while keeping autonomous changes on staging and final sign-off with people, the same model behind our AI Ticket Agent.

• •Start with a scoped pilot on one genuinely divisible task before scaling to broad fan-out.
• •Keep every subagent on an isolated branch and worktree so changes stay auditable.
• •Consolidate parallel work into a single coherent change set for human review.
• •Gate production behind explicit human approval - automation stops at staging.
• •Pair frontier capability with clear ownership, audit trails, and the right model per subtask.

Frequently Asked Questions

Common questions engineering leaders ask before adopting Claude Code agent teams for parallel work on their codebase.