> ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. --- title: "Orchestration Patterns" url: https://daily.dev/agentic-ai-hub/orchestration-patterns/ description: "Once one agent works, the obvious move is to run several. This is where the biggest gains and the biggest self-inflicted wounds both live." lastUpdated: "2026-07-22" --- Once one agent works, the obvious move is to run several. This is where the biggest gains and the biggest self-inflicted wounds both live. The organizing text is Osmani's ["The Code Agent Orchestra"](https://addyosmani.com/blog/code-agent-orchestra/), whose framing is the shift *"from conductor to orchestrator"*. A conductor guides one musician synchronously in real time. An orchestrator coordinates an asynchronous ensemble with specialized roles. *"You used to pair with one AI. Now you manage an agent team."* ## Role separation: don't let the model grade its own homework The foundational pattern is splitting the **implementer** from the **verifier**. Because *"the bottleneck is no longer generation, it's verification,"* and because models systematically overestimate their own completeness, you get materially better results by having a *different* agent (or role, or run) check the work, with fresh context and an adversarial brief, than by asking the author "are you done?" This is the multi-agent version of the same self-grading bias that plagues long-running agents. Concretely, a maker agent implements against a spec. A separate checker agent runs the tests, reviews the diff against the requirements, and tries to break it. The human sits above both, owning the outer-loop verdict. "Don't let the model grade its own homework" is the whole idea in one line. Anthropic's [Claude Code best practices](https://code.claude.com/docs/en/best-practices) document the pattern from the vendor side ("a fresh context improves code review since Claude won't be biased toward code it just wrote") and add a caveat its fans tend to omit, that "a reviewer prompted to find gaps will usually report some, even when the work is sound." Checker agents over-report dutifully, so the human above the pair judges the judge's output too. ## Worktrees for parallel isolation The enabling mechanic for running agents in parallel is **git worktrees** (or equivalent sandboxed checkouts), where each agent gets its own working directory on its own branch so concurrent agents don't clobber each other's files. Worktrees show up in the loop-engineering component list for exactly this reason. The discipline that makes them pay off is *decomposition*. Osmani's Autonomy-Levels L4 names the real challenge as "slicing work into non-overlapping pieces" so parallel agents don't produce merge conflicts or duplicated effort. Worktrees give you isolation for free. They do not give you a clean decomposition, which remains a human design problem. (The mechanic is now vendor-official. The [Claude Code docs](https://code.claude.com/docs/en/best-practices) recommend worktrees by name, "run separate CLI sessions in isolated git checkouts so edits don't collide.") ## The multi-agent debate: reads parallelize, writes don't Whether to go multi-agent *at all* is the field's liveliest open argument, and each side has solid evidence. The strongest published *pro* case is Anthropic's ["How we built our multi-agent research system"](https://www.anthropic.com/engineering/built-multi-agent-research-system), where a lead agent delegating to parallel subagents beat a single-agent baseline by 90.2% on their internal research evals. The post is candid about the bill ("multi-agent systems use about 15× more tokens than chats") and about the boundary, noting that "most coding tasks involve fewer truly parallelizable tasks than research." Cognition (the Devin team) plants the opposite flag in Walden Yan's ["Don't Build Multi-Agents"](https://cognition.ai/blog/dont-build-multi-agents). Parallel subagents without shared context make conflicting implicit decisions, so "running multiple agents in collaboration only results in fragile systems. The decision-making ends up being too dispersed." When you must split, "share context, and share full agent traces, not just individual messages." LangChain's Harrison Chase [reconciles the two](https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems) with the cleanest rule in the debate, that "read actions are inherently more parallelizable than write actions." Research and review fan out. Feature implementation against one shared codebase mostly doesn't, because merging conflicting writes (and the conflicting assumptions behind them) is the expensive part. The academic record backs the caution. The Berkeley MAST taxonomy ([Why Do Multi-Agent LLM Systems Fail?](https://arxiv.org/abs/2503.13657)) annotated 150+ execution traces and catalogued 14 recurring failure modes across three categories (system design, inter-agent misalignment, and task verification), many of them architectural rather than promptable-away. That a whole failure category is *task verification* independently confirms the maker/checker instinct above. ## Swarms, subagents, and teams: three concrete shapes The orchestra piece names three practical patterns, roughly in order of coordination sophistication: 1. **Subagents.** A parent spawns focused children with explicit file ownership and a simple dependency graph. Cost-neutral, but *you* do the coordination. Good when the work fans out cleanly and dependencies are shallow. 2. **Agent teams.** A shared task list with automatic dependency resolution, peer messaging, and file locking, which gives true parallelism *with* coordination. Osmani puts the sweet spot at **3 to 5 teammates**. 3. **Orchestration at scale.** Three tiers, in-process (e.g. Claude Code), local orchestrators, and cloud fleets, for when you genuinely need many agents and reviewable artifacts. The when-to-use heuristic is to reach for multi-agent only when a single agent hits a wall, whether *context overload* on a large codebase, *lack of specialization* (a generalist underperforming focused agents), or *no coordination primitives* for genuinely parallel work. When those walls are real, *"three focused agents consistently outperform one generalist agent working three times as long"* thanks to parallelism, specialization, isolation, and compound learning. When they aren't, multi-agent is pure overhead, and worse, *"small harmless mistakes compound at a rate that's unsustainable"* across an orchestrated army. ## The orchestration tax and your parallel-agent limit Here is the honest counterweight to swarm enthusiasm, from ["The Orchestration Tax"](https://addyosmani.com/blog/orchestration-tax/). Starting more agents is easy, but *"more agents running doesn't mean more of you available, your cognitive bandwidth doesn't parallelize."* Osmani's metaphor is precise and worth remembering. *"You are the GIL of your AI agents. They all can run at once. But when any of their work needs genuine understanding, that work has to acquire the lock."* Judgment is single-threaded, and context-switching between agents reloads your mental model in *minutes* (with incomplete recovery), not microseconds. The consequence is a hard ceiling. *"The right number of parallel agents is how many you can actually code review properly. For most of us this is a low single digit."* Run more and you don't get more output. You get invisible debt and quietly lowered standards. The mitigations are the mitigations of any concurrent system. **Scale agent count to your review rate**, **sort work** (delegate isolated tasks, protect the judgment-heavy ones for serial focus), **batch reviews** to amortize context-switch cost, **automate verification** so your scarce attention goes only to genuine judgment calls, and deliberately **protect serial time** by closing the dashboard and thinking. The uncomfortable through-line is that the human bottleneck was in some sense a feature rather than a bug, because the pain of reviewing was the signal that caught errors early. Orchestrate that signal away and mistakes compound in the dark. Simon Willison arrived at parallel agents a skeptic, and his conversion, in ["Embracing the parallel coding agent lifestyle"](https://simonwillison.net/2025/Oct/5/parallel-coding-agents/), turns the abstract "sort work" mitigation into a concrete menu. Parallelize the low-stakes, low-review-cost work (research spikes, codebase Q&A, proofs of concept, maintenance chores) and keep feature work serial and spec-driven, because "reviewing code that lands on your desk out of nowhere is a *lot* of work," while "code that started from your own specification is a lot less effort to review." The parallel agents that pay are the ones whose output you can judge in minutes.