Anthropic shipped Agent Teams in Claude Code as a way to let multiple Claude instances work on different parts of a problem at once, coordinated by a lead agent that assigns subtasks and merges results. The pattern shipped to mixed reception: brilliant for some workloads, slower than a single agent for others, occasionally producing the worst of both worlds. The signal from the first months of real use is that multi-agent orchestration is genuinely useful — for a specific shape of problem, with a specific kind of discipline. This post is the practical shape that works.
The shape of problem that benefits
Multi-agent orchestration helps when the problem decomposes into chunks that are:
- Independent. Subagents work on different files, different modules, different topics without needing to coordinate with each other in real time.
- Comparable in size. Three subtasks of roughly equal complexity beats one tiny subtask and one huge one.
- Mergeable. Their outputs combine cleanly at the end without subtle interactions that require renegotiation.
Classic fits: writing tests for several independent modules, generating documentation for several services, refactoring a function across files where the changes are mechanical, running parallel research questions whose answers feed a final synthesis.
Classic anti-fits: anything where step two depends on the outcome of step one, anything where the agents need to negotiate a shared design decision, anything where the natural unit of work is small enough that the coordination overhead exceeds the parallelism gain.
The lead-and-subagents architecture
The architecture that holds up across vendors is consistent. One lead agent:
- Reads the request and decides how to decompose it.
- Writes a structured task spec for each subagent — inputs, expected outputs, constraints.
- Dispatches subagents in parallel.
- Receives their outputs.
- Merges, reconciles, and synthesises into the final answer.
The lead is not just a router. It is the only component with the full context, the merge logic, and the responsibility for output quality. Subagents do not talk to each other. They each get a self-contained brief, do their work, return.
Why the decomposition is where most projects fail
The temptation is to ask the lead agent to "split this up however makes sense." Sometimes that works. Often the lead picks a decomposition that is technically defensible but operationally bad — chunks that turn out to depend on each other halfway through, or chunks that produce overlapping output that the merge cannot reconcile cleanly.
The pattern that holds up: the developer specifies the decomposition explicitly, or at least the decomposition strategy. "Split by file" works for some tasks. "Split by feature" for others. "Split by research question" for yet others. The decomposition strategy is a design decision the developer makes; the agent's job is to execute it, not invent it.
The lead agent is excellent at executing a decomposition you specify. It is much worse at choosing the decomposition strategy you did not specify.
The merge step is the bottleneck
Three subagents producing in parallel sounds three times as fast as one. In practice the speedup is often closer to 1.5× because the merge step dominates the total time. The lead agent has to read three outputs, identify inconsistencies, resolve them, and produce a coherent final result. That work is single-threaded and proportional to total subagent output volume.
Two practical mitigations: keep subagent outputs structured and bounded (a JSON-shaped report beats an essay), and give the lead a clear merge rule for predictable conflict types (which subagent wins when they disagree about a shared term).
Where this beats a single agent
Concrete examples where multi-agent orchestration consistently beats the single-agent baseline:
- Test generation for a modular codebase. Five subagents each owning a module produce comprehensive tests in roughly the wall-clock time of one agent doing one module.
- Cross-document research. Three subagents each digging into one source produce broader coverage than one agent reading sequentially.
- Multi-language documentation. Subagents per target language work in parallel where a single agent would serialise.
- Independent refactors across a large codebase. When the changes do not interact, splitting by directory delivers near-linear speedup.
Where it loses to a single agent
Honest counter-examples:
- Tightly-coupled design work. A single agent holding the full context produces a more coherent design than two agents producing two halves that the lead has to reconcile.
- Short tasks. The coordination overhead exceeds the parallelism benefit for anything that fits in a single agent's context comfortably.
- Tasks with shared mutable state. If subagents need to read each other's progress as they go, the orchestration breaks down. That class of problem wants a different architecture (long-running collaboration, not parallel decomposition).
Governance considerations
The same hook and audit patterns that govern single-agent work apply to multi-agent setups, with one addition: the orchestration topology itself is part of the audit story. Capture not just what each agent did, but how the work was decomposed and how outputs were merged. The first time you have to explain a multi-agent result to a compliance reviewer, that topology log is the artefact that lets you answer.
A practical starting playbook
- Pick a task that obviously decomposes into independent chunks of comparable size.
- Specify the decomposition strategy in your prompt to the lead agent — do not leave it open.
- Bound each subagent's scope tightly. Self-contained brief, structured output format, clear acceptance criteria.
- Give the lead a merge rule for predictable conflict types.
- Run a single-agent baseline on the same task and compare. The comparison is the only honest way to know whether multi-agent helped.
- Iterate on the decomposition strategy based on what you observe, not on what feels right.
The wider lesson
The interesting truth about multi-agent orchestration in 2026 is that the architecture has matured faster than the discipline of using it. The tools — Claude's Agent Teams, OpenCode's plan/build split, custom orchestration over MCP — are credible. The teams that get value from them are the ones treating multi-agent setups as a deliberate engineering choice with its own design discipline, not a magic accelerator.
For DACH enterprise teams, that discipline maps naturally onto how serious engineering already works. Specify the structure, bound the scope, measure the result, iterate honestly. Multi-agent orchestration is not a new mental model; it is the old mental model applied to a new kind of worker. The teams that approach it that way are the ones whose AI work compounds across quarters.