Claude Code Subagents: Parallel Fleet Guide 2026

The insider's guide to turning one Claude Code session into a coordinated fleet of parallel agents that ship real work.

In Anthropic's own experiment, a lead agent coordinating a team of parallel subagents beat a single agent by 90.2% on the same task - Anthropic Engineering. That result is why every serious Claude Code user in 2026 has stopped thinking about "the agent" and started thinking about the fleet: several specialized agents running at once, each with its own context window, its own tools, and its own slice of the problem.

But here is the catch that the headline number hides: that same multi-agent system burned roughly 15 times the tokens of a single chat. A fleet is not free horsepower. It is a lever that multiplies both output and cost, and pointed at the wrong task it multiplies confusion, merge conflicts, and your monthly bill instead. The difference between a fleet that ships and a fleet that thrashes comes down to a handful of decisions most people never make deliberately.

This guide breaks down exactly what a Claude Code subagent is, the four distinct ways to run agents in parallel, the orchestration patterns that actually hold up under load, the real 2026 pricing of running many agents at once, and the failure modes that have already deleted production databases. It starts high level, then goes deep into config, commands, economics, and the full field of competing tools. By the end you should be able to design, run, and budget a parallel agent fleet on purpose rather than by accident.

Contents

1. What a Subagent Actually Is
2. How Claude Code Subagents Work
3. Four Ways to Run a Fleet in Parallel
4. The Players: Parallel-Agent Coding Tools Compared
5. The Economics of a Fleet
6. Orchestration Patterns That Actually Work
7. Where Fleets Win, and Where They Break
8. Building Your First Subagent Fleet
9. Programmatic and Hosted Fleets
10. The Road Ahead for Agent Fleets

Master Comparison: The Best Parallel-Agent Coding Tools (2026)

Before the deep dives, here is the whole field on one scorecard. This ranks the tools and platforms you can actually use to run multiple coding agents at once, scored from first principles on what matters when you fan out work: how well they parallelize and isolate concurrent agents, whether the cost model survives running many of them, how much control and context you keep over each one, and the ecosystem that surrounds the tool. Scores are 0 to 10 with the real data in each cell, and the final column is the weighted average. Read it as a map, not a verdict: the detailed profiles in section 4 explain when a lower-ranked tool is the right pick.

How to read the criteria. Parallelism and isolation (30%) is the headline capability: can it run many agents at once and keep them out of each other's way. Cost and economics (25%) asks whether running ten agents is predictable or a bill-shock lottery. Control and context (25%) captures how tightly you can steer each agent and how well it protects context, which is where most fleets fail. Ecosystem and maturity (20%) covers models, integrations, and whether the tool will still exist next quarter. Claude Code tops the table because it is the only tool that ships native subagents, git-worktree isolation, headless scripting, and a matching SDK in one place, which is exactly why nearly every rival benchmarks against it. The scores are close in the middle because 2026 turned parallel agents into table stakes; the differences are in cost model and how much control you keep.

1. What a Subagent Actually Is

Start from the constraint, not the feature. A language model has a finite context window, and everything an agent reads, every file, every search result, every stack trace, competes for space in that window. When one agent tries to do everything, its context fills with noise: half-read files, dead-end searches, tool output it will never look at again. Performance degrades not because the model got dumber but because the signal it needs is buried under the exhaust of its own work. This is the fundamental problem that subagents exist to solve, and understanding it is the difference between using subagents as a gimmick and using them as an architecture.

A subagent in Claude Code is a specialized assistant that runs in its own separate context window, with its own system prompt, its own restricted set of tools, and optionally its own model. When the main agent hands a task to a subagent, the subagent does the messy, verbose work inside its own window and returns only a clean summary to the main conversation - Claude Code docs. The main thread never sees the forty files the subagent grepped through or the twelve search queries it ran. It sees the answer. That single design choice, keeping the verbose work quarantined, is why a fleet of focused subagents can outperform one overloaded agent even when they run the same underlying model.

The official documentation lists the concrete payoffs of this isolation, and each one maps to a real limitation of the single-agent approach:

• Preserve context by keeping verbose side-work out of the main window
• Enforce constraints through a restricted, per-agent tool set
• Specialize behavior with a task-specific system prompt
• Control cost by routing narrow work to cheaper models like Haiku
• Reuse configs across projects and teammates by checking them into version control

The cost lever deserves emphasis because it is the one most people miss. A subagent that only reads and greps has no business burning flagship-model tokens; point it at a cheaper, faster model and you get the same answer for a fraction of the price. The tradeoff is equally important and equally underappreciated: because a subagent starts with a fresh, empty context, it cannot see your conversation history, the files the main agent already read, or the decisions you already made together. It has to gather that context itself, which costs time and tokens. Subagents are for self-contained, context-heavy work that returns a summary, not for the iterative back-and-forth where shared history is the whole point. Get that boundary wrong and you will spend more coordinating than you save.

2. How Claude Code Subagents Work

If section 1 was the why, this is the how, and it is refreshingly low-tech. A Claude Code subagent is just a Markdown file with YAML frontmatter. The frontmatter configures the agent and the body becomes its system prompt. There is no framework to learn, no orchestration graph to draw, no Python to write. You either write the file by hand or ask Claude to write it for you, drop it in a directory Claude Code watches, and it hot-reloads within seconds. This simplicity is deliberate: the whole point is that a subagent is a portable, version-controlled artifact your whole team can share, review in a pull request, and improve over time.

Location determines scope. Project-level subagents live in .claude/agents/ inside the repo and get checked into git so the whole team inherits them; personal subagents live in ~/.claude/agents/ and follow you across every project. Both directories are scanned recursively, and identity comes from the name field, not the file path, so you can organize them however you like. When names collide, a documented priority order decides the winner: managed org settings outrank a --agents CLI flag, which outranks project agents, which outrank user agents, which outrank plugin agents. That hierarchy is what lets a company enforce a standard code-reviewer across every repo while still letting an individual developer keep their own experimental agents.

Here is a real subagent config, straight from the official documentation, that shows every important field in context:

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---

You are a senior code reviewer ensuring high standards of code quality and security.
When invoked:
1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Only name and description are required, but the full field list is worth knowing because each one is a control surface: tools, disallowedTools, model, permissionMode, maxTurns, skills, mcpServers, hooks, memory, background, effort, isolation, and color. The two that shape a fleet most are tools and model, and they encode the two levers from section 1. The tools field is an allowlist: name the tools and the subagent can use only those; omit it and the subagent inherits every tool, including your MCP servers, which is rarely what you want for a focused worker. The code-reviewer above gets Read, Grep, Glob, Bash and nothing else, so it physically cannot write files or touch the network. That is not a suggestion to the model; it is an enforced boundary.

The description field is the most consequential line in the file, because it is how Claude decides when to delegate. Claude Code reads the description of every available subagent and routes matching tasks automatically, and the documentation is explicit that phrases like "use proactively" or "use immediately after writing code" make delegation more aggressive. Write a vague description and your subagent sits unused; write a precise, trigger-laden one and Claude reaches for it at the right moment without being told. You can also force the matter three ways: name it in plain language ("use the test-runner subagent"), guarantee it with an @agent-name mention for a single task, or adopt it for the whole session with claude --agent code-reviewer. This tiered control, automatic by default, explicit when you need it, is what makes the same file useful for both hands-off and hands-on workflows.

Model selection per subagent is where the cost math gets real. The model field accepts sonnet, opus, haiku, fable, a full model ID like claude-opus-5, or inherit to match the main conversation. You can also override every subagent at once with the CLAUDE_CODE_SUBAGENT_MODEL environment variable, which resolves above the frontmatter value. In 2026 the sensible default is flagship on the main thread, cheaper models on the workers: keep the hard reasoning on Claude Opus 5 or Claude Fable 5, and let read-only Explore and review agents run on Claude Haiku 4.5, which costs $1 per million input tokens against Opus 5's $5 - Anthropic pricing. If you have never configured a subagent, our Claude Code beginner's guide walks through the first setup end to end.

A note on the 2026 mechanics, because they changed. As of the Claude Code 2.x line, subagents run in the background by default, the /agents command no longer opens a creation wizard (you ask Claude or edit the files directly), nesting is capped at three layers deep, a single session can spawn up to 200 subagents total, and the concurrent cap is 20. A related primitive, /subtask, forks a subagent that inherits the full conversation and shares the parent's prompt cache, which is the opposite tradeoff from a normal subagent and useful when shared context matters more than isolation. For the deeper internals of how this all wires together, the community reverse-engineering in our inside Claude Code analysis is the most detailed public account.

Anthropic's own subagents demo, with Addy Osmani walking through creation and orchestration, is the clearest short introduction to everything above and worth the fifteen minutes before you build your own.

3. Four Ways to Run a Fleet in Parallel

"Parallel agents" is not one feature; it is four different mechanisms that solve different problems, and mixing them up is the most common reason people's fleets underperform. The first question to ask is not "how do I parallelize" but "what am I isolating." Sometimes you need to isolate context (keep one agent's reasoning from polluting another's), sometimes you need to isolate files (stop two agents from editing the same code), and sometimes you need to isolate compute (run tasks on separate machines so your laptop stays usable). Each mechanism below is the right answer to exactly one of those questions, and the art of running a fleet is choosing the right one per task.

Before the mechanics, the mental model. A parallel fleet almost always follows the orchestrator-worker shape: one lead agent decomposes the goal, spins up workers to handle the independent pieces at the same time, and then synthesizes their summaries into a single result. This is precisely the architecture behind Anthropic's multi-agent research system, and the official diagram below is the canonical picture of it. Notice that the workers never talk to each other; they report back to the lead, which is what keeps the whole thing coherent.

Mechanism one: subagent fan-out inside a single session. This is the lightest-weight fleet and the one section 2 already set up. Inside one Claude Code session, the main agent launches several subagents in a single turn, and because they are dispatched together they run concurrently, each in its own context window. This is the tool of choice for breadth-first work: investigating a bug across many files, reviewing a diff from three independent angles, or gathering context from separate parts of a large codebase. It isolates context, not files, so it is safe for read-heavy tasks and risky for concurrent edits. The practical ceiling reported by practitioners is around 10 simultaneous subagents before requests queue, comfortably inside the documented cap of 20.

Mechanism two: git worktrees for file isolation. When agents need to write code in parallel, context isolation is not enough; you need file isolation, and that is exactly what a git worktree provides. A worktree is a separate working directory on its own branch that shares the same .git history, so two agents can edit code simultaneously without ever touching each other's files - Claude Code worktrees docs. The manual path is a single command, and the native flag is even shorter:

# Manual: create a worktree on a new branch, then start Claude there
git worktree add ../project-feature-a -b feature-a
cd ../project-feature-a && claude

# Native flag: Claude creates and enters an isolated worktree for you
claude --worktree feature-auth

Claude Code actively enforces the boundary: while it runs inside a worktree, it blocks edits and shell commands that would redirect into the main checkout, and the same guardrail applies to every subagent it spawns. There is one trap that catches everyone, and it is worth stating plainly. Worktrees isolate files, not your database, environment variables, or running services. Two agents running migrations against the same local database will collide no matter how many worktrees you create; give each worktree its own schema, container, port, and .env (a .worktreeinclude file copies gitignored files like .env.local into every new worktree automatically). Practitioners routinely run four to five worktree agents in parallel, and one documented setup scaled to hundreds of worktrees on a single machine.

Mechanism three: headless mode for scripted fleets. When you want to fan out from a shell script, a CI pipeline, or a cron job rather than an interactive session, headless mode is the answer. The claude -p "prompt" form runs non-interactively, returns a real exit code so scripts can branch on success, and with --output-format json emits a machine-readable result including the session ID and the total cost in dollars - headless docs. You pipe it through jq, loop over a list of tasks, and background each invocation to build a fleet out of nothing but shell:

# Capture a session, then resume it later; parse the result with jq
session_id=$(claude -p "Review the auth module" --output-format json | jq -r '.session_id')
claude -p "Summarize this project" --output-format json | jq -r '.result'

This is the substrate underneath most homegrown automation, and it composes with everything else: a headless orchestrator can create worktrees, dispatch a subagent fleet in each, and collect the JSON results. If you are building loops like this, our guide to writing loops for AI coding agents covers the control-flow patterns that keep them from running away.

Mechanism four: cloud and native multi-session. The newest tier moves compute off your laptop entirely. Claude Code on the web runs each task in an isolated Anthropic-managed VM with your repo cloned in, limited network by default, and credentials held outside the sandbox behind a scoped proxy - Claude Code on the web docs. From the CLI, claude --cloud "fix the auth bug" starts a cloud session, running several at once fans out across machines, /tasks monitors them, and claude --teleport <id> pulls one back to your local terminal. The 2026 desktop redesign added multiple parallel sessions in one window with a sidebar manager, and the /rewind checkpoint system (auto-saved before every edit) lets you undo an agent's work across code and conversation together - checkpointing docs. Around all of this, a small ecosystem of orchestration layers has grown up: Conductor for a native macOS worktree manager - conductor.build, Vibe Kanban for a board that plans and reviews agents - Vibe Kanban, and Claude Squad for managing agents as tmux sessions over SSH - Claude Squad. They all solve parallelism through worktrees under the hood; they differ mainly in how much coordination they layer on top.

4. The Players: Parallel-Agent Coding Tools Compared

The master table ranked the field; this section explains each row so you can pick the right tool for your situation rather than the highest score. The through-line for 2026 is that parallel agents stopped being a differentiator and became a checkbox. Almost every serious tool now fans out work somehow, so the real questions are how it fans out (subagents, worktrees, cloud tasks, or async jobs), what it costs to run many at once, and how much control you keep. Keep the table's four criteria in mind as you read, because the profiles below are really just the justifications behind those scores expanded into context.

Claude Code is the reference implementation and the reason this guide exists. It is the only tool that ships native subagents, git-worktree isolation, headless scripting, cloud sessions, and a matching SDK as one coherent product, running on the current Claude model lineup with first-class MCP support. Its weakness is the flip side of its power: parallel subagents multiply token burn linearly, so a wide fan-out on the pay-as-you-go API can run into the thousands of dollars for a single ambitious session. On a flat Max plan it is throttled by usage limits instead, which is often the saner way to run a fleet. Full pricing and quota detail is in our dedicated Claude Code pricing guide.

OpenAI Codex is the co-dominant agent and the strongest pure cloud fan-out story. Its model is fire-and-forget: describe several independent tasks and Codex spins up an isolated sandbox for each, each producing its own pull request. Since an April 2026 shift it meters usage by token-based rate limits rather than flat message counts, and it comes bundled inside ChatGPT subscriptions from Plus at $20 per month up through the $200 Pro tier - OpenAI Codex. The tradeoff is predictability: the token realignment made per-window limits harder to reason about, and the cloud tasks are capped per rolling window.

Factory Droid has become the rising enterprise favorite by making a subtle but important bet: its parallel Droids share org-level context rather than each running in an isolated sandbox, so agents working on the same codebase understand it the same way. It routes each task to the best model (Claude, Codex, or Kimi), meters usage by token, and reviewers consistently call the $100 Plus tier the best value in the category - Factory pricing. The risk is the usual one for token billing: long agentic runs can consume more than you expect.

Sourcegraph Amp earns its place with two ideas: parallel subagents for throughput, and an Oracle escalation model that a subagent can hand a genuinely hard problem to a slower, stronger, more expensive model on demand. Its pricing is the most transparent in the field, pure pass-through of provider API rates with zero markup and a $5 minimum top-up, no subscription required - Amp. That transparency is also its only downside if you want a predictable flat monthly cost, because there is not one.

Gemini CLI is Google's open-source answer to Claude Code, and as of April 2026 it ships native parallel subagents: an orchestrator delegates to specialized subagents that run at the same time, each with up to a million tokens of context, in a free Apache-licensed binary - Gemini CLI. The catch arrived mid-2026, when Google discontinued the free hosted sign-in tier, so real use now needs a paid Gemini API key. For open-source terminal developers who want native fan-out without a subscription, it is the strongest free option.

Google Jules takes the opposite shape: fully async cloud agents. Each task runs in its own Google VM in the background, and concurrency is the parallelism knob, three concurrent tasks on the free tier up to 60 concurrent on Ultra, the highest ceiling of any async agent in the field - Jules. You dispatch a batch of tasks, close your laptop, and come back to finished pull requests. It is not for interactive work, and it is tied to the Gemini ecosystem, but for repo-level batch jobs the concurrency ceiling is unmatched.

o-mega approaches the problem from a different altitude. Rather than handing you a CLI to drive a fleet by hand, it runs teams of agents in the cloud across whole business functions, spawning parallel working sessions the way this guide spawns subagents, and coordinating them through a managed orchestration layer - o-mega. It sits in the table as an honest alternative for teams who would rather deploy a managed autonomous workforce than hand-run a local fleet: you trade some low-level control for not having to build the orchestration, the isolation, and the cost governance yourself. It is less a code editor than a platform for standing up agent teams that keep running after you close the laptop.

Warp reframes the terminal itself as an agentic hub. Its Oz platform coordinates parallel local and cloud runs, and its universal-agent support hosts Claude Code, Codex, and Gemini CLI side by side in vertical tabs so you can run and compare them in one place - Warp pricing. Warp open-sourced its client in 2026 and supports bring-your-own-key, so it is a natural home for a mixed fleet. Because its credits map to raw API cost, heavy parallel use reaches the $200 Max tier quickly.

OpenHands, formerly OpenDevin, is the leading open-source agent platform, with 70,000-plus GitHub stars and a Series A behind it. It is free to self-host under an MIT license, and self-hosting is exactly what unlocks unlimited parallelism: run as many agent instances as your own compute allows - OpenHands. The free cloud tier caps daily conversations, and the whole thing is more do-it-yourself than the polished commercial tools, which is the price of zero lock-in.

Cursor remains the most-used AI editor, and its parallel story runs through background and cloud agents plus Bugbot, which reviews many pull requests in parallel. It is editor-first, which is a strength for interactive steering and a limitation for headless fleets, and its usage-based overages push heavy parallel users toward the $200 Ultra tier - Cursor pricing. For developers who live in the editor and want parallel work as a background convenience, it is the smoothest experience.

Devin pioneered the autonomous-engineer framing and now orchestrates multiple managed Devins in parallel, each with its own IDE, shell, and browser. Its 2026 repositioning matters: the entry point dropped from a $500 floor to a $20 Core tier billed by ACU, with up to ten concurrent sessions, while unlimited concurrency lives on the $500 Team plan - Devin pricing. The ACU consumption model is its weak point, opaque and prone to ballooning on long runs.

Roo Code deserves its place for historical reasons: its orchestrator/boomerang mode, where a top-level agent decomposes a goal, spawns isolated subtask agents, and boomerangs their summaries back, was the pattern many tools later copied - Roo boomerang docs. The original extension was retired in May 2026, with migrants pointed at a community fork, so include it for the concept and note the sunset. Cline rounds out the field as the leading open-source VS Code agent, fully bring-your-own-key with a transparent real-time cost display that many developers prefer precisely because it hides nothing - Cline. It is single-agent per task rather than a fleet tool, but it is the honest baseline for cost-conscious BYOK work. For the full landscape beyond the parallel-specific tools, our top 50 AI coding agent frameworks benchmark ranks the wider field, and the LangGraph vs CrewAI vs AutoGen comparison covers the framework layer underneath.

5. The Economics of a Fleet

Here is the uncomfortable truth that turns most enthusiastic fleet experiments into cautionary tales: a fleet multiplies your token bill by roughly the number of agents you run. Anthropic measured it directly. In their research on multi-agent systems, general agents used about 4 times the tokens of a chat, and their full multi-agent system used about 15 times the tokens of a chat - Anthropic Engineering. In a regression on their evaluation, token usage alone explained 80% of the performance variance, which is a polite way of saying the multi-agent system won mostly because it spent more. That is not a reason to avoid fleets; it is a reason to run them only when the task is worth the spend, and to know the numbers before you start.

The numbers start with the models. As of August 2026 the Claude lineup that matters for a fleet spans a 10x price range from top to bottom, which is precisely what makes model selection per subagent so powerful. The table below is first-party API pricing per million tokens, and the spread is the whole argument for running cheap workers under an expensive lead.

A few facts change the math more than the sticker prices suggest. Sonnet 5 carries an introductory $2/$10 rate through August 31, 2026, reverting to $3/$15 the next day, so time-sensitive workloads should budget for the higher number. Cached reads bill at roughly 10% of the input price, which for a production agent loop with a stable system prompt and tool definitions means an 85-to-90% sustained discount on the repeated prefix - Anthropic pricing. And the 1M-token context carries no long-context premium, so a fleet that leans on large context is not penalized for it. Prompt caching is the single biggest lever for making a fleet economically viable, because every worker that reuses the same static scaffold pays full price for it once and a tenth of the price forever after. For the deeper cost breakdown across the whole agent ecosystem, our report on the true cost of agentic AI traces where the money actually goes.

The other half of the economics is the subscription question. You can run Claude Code two ways, and they behave completely differently under a fleet. On the API, you pay per token at the rates above, which means a wide fan-out has no ceiling; ten Opus workers cost ten times one. On a subscription, you pay a flat monthly fee and are throttled by usage limits instead: Pro at $20 per month, Max 5x at $100, and Max 20x at $200, with Claude Code included in all three - claude.com/pricing. In 2026 Anthropic layered a rolling weekly cap on top of the existing five-hour window, and the Max plans carry two weekly caps, one across all models plus a separate Sonnet-only cap. Anthropic no longer publishes exact hourly quotas, only the plan multipliers, so treat any specific "hours per week" figure you see as an unofficial community estimate rather than a promise. The practical upshot is simple: for heavy parallel work, a Max subscription is usually cheaper and more predictable than the API, because it converts an unbounded per-token bill into a fixed monthly cost you cannot blow past.

It helps to make this concrete with a worked example. A single heavy Opus 5 coding session might consume 2 million input tokens and 500,000 output tokens, which at $5 and $25 per million works out to $10 plus $12.50, about $22.50. Fan that into a five-agent fleet, one Opus lead plus four Sonnet workers, and the shape shifts: the lead still costs its $22.50, but four Sonnet workers at $3/$15 handling narrower slices might add roughly $8 each, near $55 for the session. Then apply caching. If 80% of each agent's input is a shared static prefix billed at a tenth of the rate, the input side collapses and the same fleet can land closer to $20. The lesson is that the 15x multiplier is a ceiling, not a fixed toll, and the two levers that pull it down, cheaper worker models and aggressive prompt caching, are precisely the ones the subagent config file exposes.

The last economic reality is rate limits, which behave in a fleet-friendly way once you understand them. API limits are per model, so different models draw from independent buckets and Opus 5 has its own pool separate from the older Opus family - rate limits docs. Only uncached input counts toward your input-tokens-per-minute limit, so heavy caching multiplies your effective throughput; a fleet with an 80% cache hit rate can push far more real work through the same limit. There is no published concurrency cap, only throughput limits, which means many parallel agents on one model share that organization bucket and will hit 429s together if you fan out too aggressively on a single model. The fix is to spread the fleet across models (Opus lead, Sonnet and Haiku workers) so each draws from its own bucket, which conveniently is also the cost-optimal configuration. The chart below makes the core multiplier concrete.

6. Orchestration Patterns That Actually Work

Knowing how to spawn agents is not the same as knowing how to coordinate them, and coordination is where fleets earn or lose their keep. The patterns below are the ones that survive contact with real work, drawn from Anthropic's own system and from the practitioner consensus that has hardened over 2026. They share a single principle: the orchestrator owns the plan and the synthesis; the workers own only their narrow slice. When that boundary blurs, when workers start making cross-cutting decisions or the lead starts doing the detailed work itself, the fleet degrades into an expensive single agent with extra steps.

The foundational pattern is fan-out, then verify. The lead decomposes the goal into independent pieces, dispatches a worker per piece so they run at once, and then, crucially, runs a separate fresh-context agent to check the combined result. The verification step is not optional polish; it is where a fleet's quality comes from. A reviewer that did not write the code catches more, because it does not inherit the writer's assumptions about what the code is supposed to do. Anthropic's parallelization of tool calls, a lead spinning up three to five subagents at once, each calling several tools in parallel, cut research time by up to 90% on complex queries, which shows the pattern's ceiling when the work genuinely decomposes.

Anthropic's guidance also bakes in scaling heuristics that stop the two opposite failure modes, and they are worth memorizing because they are the difference between a right-sized fleet and a wasteful one:

• Simple fact-finding: one agent, three to ten tool calls
• Direct comparisons: two to four subagents, ten to fifteen calls each
• Complex, open-ended research: ten-plus subagents with clearly divided responsibilities
• Never fan out on a task whose pieces depend on each other's real-time output

The reason these bounds matter is that the early version of Anthropic's own system failed in a memorable way: it spawned 50 subagents for simple queries, drowning a trivial task in coordination overhead. The corrective is to make the lead reason explicitly about effort before it delegates, and to keep spawn counts bounded by the value of the task. In practice the community sweet spot for coding fleets is tighter than the research heuristics suggest, three to five concurrent agents, because beyond that you spend more time merging summaries than the parallelism saves. Our guide to long-running coding agents goes deeper on pacing and budget for the extended-horizon case.

The second durable pattern is the loop-until-dry discovery fleet, useful when you do not know the size of the work in advance. Instead of guessing how many bugs, edge cases, or dead links exist, you keep dispatching finder agents until two consecutive rounds turn up nothing new, deduplicating against everything seen so far. This is how you get exhaustive coverage without a fixed cap, and it pairs naturally with the fan-out-then-verify pattern: finders surface candidates in parallel, a verification pass confirms each, and the loop continues until the finders come back empty. The key discipline is deduplicating against the seen set rather than the confirmed set, so that a rejected finding does not reappear every round and stall the loop forever.

The third pattern is the judge panel for decisions rather than discovery. When the task is to choose an approach rather than find a defect, you generate several independent attempts from different angles, score them with parallel judge agents, and synthesize the winner while grafting the best ideas from the runners-up. This beats one-attempt-iterated whenever the solution space is wide, because a single agent tends to anchor on its first idea. For the harder end of this, where the fleet keeps refining its own strategy, our analysis of self-improving AI agents covers the ratchet mechanisms that make iterative improvement converge instead of drift. Across all three patterns the same rule holds: bound the fan-out, restrict each worker's tools, downshift its model, and keep synthesis and verification with dedicated agents. That is the whole craft.

7. Where Fleets Win, and Where They Break

The single most important skill in running a fleet is knowing when not to. Reasoning from first principles: a fleet works by splitting a problem into pieces that can be solved independently and recombined. That means a fleet's value depends entirely on how decomposable the problem is. When the pieces are truly independent, parallelism is close to free speedup. When the pieces are entangled, when solving one requires knowing the current state of another, forcing them into separate agents does not just fail to help; it actively injects error, because each agent is now reasoning from a stale or partial view of a shared reality. This is not a tuning problem you can prompt your way out of. It is structural.

The wins cluster on the breadth side, and they are real. Multi-file investigation is ideal: read-only Explore agents on cheap models sweep different parts of a codebase in parallel and report back, never colliding because they only read. Independent features built in separate worktrees parallelize cleanly because each agent owns its own files. Fresh-context review and red-teaming are among the highest-value uses, precisely because the value comes from the reviewer not sharing the writer's context. And wide migrations across many files, where the same mechanical change repeats, fan out beautifully. Anthropic's June 2026 dynamic-workflows upgrade lets a lead fan out tens to hundreds of parallel subagents in a single session for exactly this class of work.

The failures cluster on the depth side, and they are equally structural. The most articulate warning came from Cognition, the makers of Devin, who published a piece titled "Don't Build Multi-Agents" within about 48 hours of Anthropic's post - Cognition. Their argument is that multi-agent systems are fragile because decisions get dispersed and context cannot be shared thoroughly enough. Their example is sharp: ask one agent to build a game's background and another to build the character, and without shared visual and gameplay expectations, the two outputs do not align. Their principle, "every action must be informed by the full record of prior actions," is exactly the condition a fleet cannot satisfy, which is why they argue for keeping tightly coupled work in a single agent.

The concrete failure modes practitioners hit follow directly from that principle, and each one has a mitigation you should apply before you fan out:

• Merge conflicts when two agents edit the same file, sometimes forcing a full rerun
• Stale context, where a subagent reads code the main session is mid-edit and hallucinates lines that no longer exist
• Compounding error, where chained agents drop to a 20-to-40% success rate as hallucinations and drift propagate silently
• Cost blowup, where every hop bills the previous agent's output as input and every failed turn retries with the full accumulated history

The mitigations are unglamorous but decisive. Map file ownership before you fan out: if two tasks touch overlapping files, run them sequentially, not in parallel. Never run a read-only subagent against files the main session is actively editing. Keep chains short, because the compounding-error math is brutal past a few hops; the analysis in the true cost of agentic AI report and the cost-compounding writeups from Augment quantify how "three agents cost ten times" once retries and re-passed context are counted - Augment.

A concrete partitioning example shows how much of this is preventable at the planning stage rather than the merge stage. Suppose you want to add a search feature, an export feature, and a shared pagination helper all three touch. The naive fleet fans out three agents and hits a three-way conflict on the shared helper. The disciplined version does the opposite: it runs one agent first to build the pagination helper and merge it to the main branch, then fans out the search and export agents in separate worktrees that both branch from the now-updated main. The two feature agents never touch the same files, so they run cleanly in parallel, and the sequential step cost you one short serial hop to buy conflict-free parallelism for the expensive work. This is the general move: find the shared dependency, resolve it once up front, then parallelize everything downstream of it. Most merge disasters are not tooling failures; they are planning failures that a five-minute ownership map would have caught.

None of this is hypothetical, and the cautionary cases deserve to be named because they change how you set permissions. Between mid-2025 and mid-2026 there are at least nine publicly documented cases of coding agents destroying data - Adversa. In one April 2026 incident, an agent editing a production system deleted a company's database and all of its backups in about nine seconds, wiping months of live data. The nuance that should reshape your practice is this: almost none of these were hallucinations. The model's intent was usually correct and boring, clear a cache, diff a migration; the damage happened one layer below, in shell quoting, tilde expansion, exit-code parsing, and blurred production-versus-development boundaries, amplified by over-broad permissions. A fleet multiplies this exposure by the number of agents that can run destructive commands. The lesson is not "don't use fleets"; it is restrict tools per agent, keep production credentials out of agent reach, and never give a worker write access it does not strictly need. Cole Medin's 2026 walkthrough of agent teams coding in parallel is a good watch on how this looks when it goes right, and it shows the coordination discipline that keeps the failure modes above at bay.

8. Building Your First Subagent Fleet

Theory earns its keep only when it turns into a working setup, so this section is a concrete walkthrough you can follow today. The goal is a small, safe, useful fleet: a read-only explorer that maps unfamiliar code, a fresh-context reviewer that checks diffs, and an orchestration habit that fans them out without collisions. The order matters. You build the workers first, prove they behave in isolation, and only then wire them into parallel runs, because a fleet that misbehaves is much harder to debug than a single agent that does. This is the same build-then-verify discipline the orchestration patterns preach, applied to your own tooling.

Step one is the explorer, and it is the safest possible agent to start with because it cannot change anything. Create .claude/agents/explorer.md with a read-only tool set, a cheap model, and a description that triggers proactively:

---
name: explorer
description: Read-only codebase investigator. Use proactively to map unfamiliar code, trace how a feature works, or find where a symbol is defined, without editing anything.
tools: Read, Grep, Glob
model: haiku
---

You are a fast, thorough code explorer. Investigate the question, then
return a concise summary: the relevant files, the key functions, and how
they connect. Cite file paths and line numbers. Do not propose edits.

Because its tools list omits Write and Edit entirely, this agent physically cannot modify code, which makes it safe to run many copies at once against the same files. Put it to work immediately: ask Claude to "use the explorer to map how authentication flows through this codebase, and separately how the billing module is structured." Those two investigations are independent and read-only, so Claude dispatches them as concurrent subagents, each burning cheap Haiku tokens in its own context window, and returns two clean summaries without ever cluttering your main thread. That is a two-agent fleet, and you built it with one Markdown file and one sentence.

Step two is the reviewer, which introduces the verification half of the pattern. Create .claude/agents/reviewer.md with the ability to read and run git, but not to write:

---
name: reviewer
description: Fresh-context code reviewer. Use immediately after code is written or modified to check for bugs, security issues, and missed edge cases.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You are a senior reviewer who did NOT write this code. Run git diff, focus
on the changed files, and report every issue with a severity and a one-line
fix. Do not rewrite the code yourself.

The magic is in the phrase "who did NOT write this code." Because the reviewer starts with a fresh context, it genuinely does not carry the writing agent's assumptions, and that independence is what makes its review valuable rather than a rubber stamp. Run it after any significant change: "use the reviewer to check the diff." For a full second opinion on quality rather than correctness, you can layer in the review disciplines from our Claude Code skills collection, which packages many of these patterns as reusable skills.

Step three is parallel writing, which is where worktrees become non-negotiable. Once you want two agents to build different things at once, they need file isolation, so give each its own worktree:

# Two isolated worktrees, one Claude session each, both writing safely
git worktree add ../app-feature-search -b feature-search
git worktree add ../app-feature-export -b feature-export
# In terminal 1:  cd ../app-feature-search && claude
# In terminal 2:  cd ../app-feature-export && claude

Before you start them, do the one step that prevents the most common disaster: map file ownership. If the search feature and the export feature both need to touch a shared types file, do not run them in parallel; sequence them, or have one agent make the shared change first and the other rebase onto it. When they finish, review each branch with git diff main..feature-search and judge the changes on their merits rather than trusting green CI. This is the entire loop, worker, verify, isolate, merge, and it scales from two agents to a dozen without changing shape, only in how carefully you partition the work. The full architecture behind Claude Code's terminal experience, for readers who want to understand what they are driving, is captured in our inside Claude Code piece.

9. Programmatic and Hosted Fleets

The subagent fleet in section 8 lives inside the interactive Claude Code tool, but that is only one of three surfaces where the same engine runs, and choosing the right surface is a real architectural decision. The difference comes down to two questions: who runs the agent loop, and who hosts the infrastructure it runs on. The interactive tool answers "you and your laptop." The Agent SDK answers "your code, your infrastructure." Managed Agents answers "Anthropic, on Anthropic's infrastructure." Each is the right answer for a different situation, and understanding the split keeps you from reaching for a heavyweight platform when a Markdown file would do, or hand-rolling orchestration that Anthropic would run for you.

The Claude Agent SDK, renamed from the Claude Code SDK, packages the same harness as a library you call from your own code. The TypeScript package is @anthropic-ai/claude-agent-sdk and the Python package is claude-agent-sdk, and the core primitive is the query() function, an async loop that runs the model, executes its tool calls, and streams every step until it returns a result - Agent SDK subagents docs. Subagents come three ways here: defined programmatically through the agents option, loaded from the same .claude/agents/ Markdown files as the interactive tool, or invoked as the built-in general-purpose agent through the Agent tool (renamed from Task in a 2026 release). Programmatic definitions take precedence over filesystem ones with the same name, which lets an application ship its own agents while still respecting a repo's checked-in configs. Subscription plans now include a separate monthly Agent SDK credit, $20 on Pro up to $200 on Max 20x, so you can build on it without immediately reaching for pay-as-you-go billing - our Agent SDK deep dive and the companion Agent SDK credit guide cover the full setup.

Managed Agents removes the infrastructure question entirely: Anthropic hosts the sandbox and runs the loop, and you define a coordinator that delegates to a roster of other agents. The multiagent shape has hard, documented limits that are worth knowing before you design around it: a roster holds a maximum of 20 unique agents (though the coordinator can spawn multiple copies of each), you can run up to 25 concurrent threads, and delegation goes only one level deep, so a roster agent cannot itself carry a roster - Managed Agents multiagent docs. All agents share one filesystem and vault but each runs in its own context-isolated thread, which is the same isolation principle as Claude Code subagents applied to a hosted setting. For teams who want fleet orchestration without running the compute, our Claude Managed Agents guide is the practical starting point, and the broader Anthropic ecosystem guide maps how all three surfaces fit together.

The economics of these programmatic fleets hinge on the same lever as the interactive ones, only more so: prompt caching plus context management. Production agent loops keep 80 to 95% of their prompt static (the system prompt, tool definitions, planning scaffold), and caching that prefix drops its cost by roughly 90% on every subsequent step, which is what makes a 20-step loop across a fleet affordable at all. For long-running fleets, the harness compacts the main conversation while subagent transcripts persist separately, unaffected by that compaction, so the lead stays lean without losing the workers' detailed records. The full end-to-end orchestration flow, including how the lead persists memory and runs a dedicated citation pass, is captured in Anthropic's detailed workflow diagram below.

10. The Road Ahead for Agent Fleets

Where does this go from here? The honest first-principles answer starts by asking what has actually been changing, and the answer is not the models alone but the cost of coordination. In 2024, running two coding agents in parallel meant hand-managing terminals and manually resolving conflicts. By mid-2026, claude --worktree isolates files in one flag, dynamic workflows fan out hundreds of subagents in one session, and cloud sessions run tasks on separate machines you never provision. The trajectory is clear: the friction of running many agents is falling faster than the cost of the tokens they burn. That reframes the question every builder should be asking. It is no longer "can I run a fleet" but "what is worth running a fleet on," and that is fundamentally an economics question, not a tooling one.

The second force is verification becoming the bottleneck. When one agent wrote code, a human reviewed it. When a fleet writes ten branches in parallel, no human can review at that rate, so review itself is being handed to agents, the fresh-context reviewer pattern generalized into a standing verification tier. This is why the highest-leverage investment in 2026 is not a bigger fleet but a better verifier, because output that cannot be trusted at scale is worse than less output that can. Expect the tooling to keep moving in this direction: more red-team agents, more automated judge panels, more of the loop-until-dry discovery pattern applied to catching what the writing agents miss. The frameworks landscape underneath, tracked in our agent frameworks comparison, is converging on exactly these primitives.

The third force is the move from coding fleets to operating fleets. The same orchestration that fans out subagents across a codebase generalizes to fanning out agents across a business: one team researching, one drafting, one executing, coordinated by a lead. This is the bet behind managed cloud-workforce platforms, and it is where the line between a coding tool and an autonomous-operations platform blurs. Yuma Heymans, founder and CEO of the autonomous-workforce platform o-mega and co-founder of the AI recruitment engine HeroHunt.ai, has spent 2026 building exactly these production fleets, agents that run business functions end to end rather than just editing files, which is about as direct a source of ground truth on orchestrating parallel agents at scale as the field has. Follow his work at @yumahey. The wider shift toward agents that operate rather than merely assist is mapped in our survey of the most popular use cases for agentic systems.

The counter-narrative deserves the last word, because pressure-testing the optimism is the point of first-principles thinking. Cognition's "don't build multi-agents" argument has not been refuted; it has been scoped. Fleets did not win everywhere, and the practitioners who ship the most have converged on a narrower, more disciplined use than the early enthusiasm suggested: bound the fan-out, isolate ruthlessly, verify independently, and reserve the 15x token spend for tasks whose value clearly clears the bill. The future of agent fleets is not "more agents." It is the right number of agents, aimed at the right kind of problem, with a verifier you trust. The teams that internalize that will get the 90% speedups; the teams that fan out reflexively will get the 20-to-40% success rates and the surprise invoices.

Conclusion: A Decision Framework

Everything above collapses into a short, honest decision framework you can apply before you spawn a single agent. Ask three questions in order, and let the answers, not the excitement, decide.

First, is the work decomposable? If the pieces are genuinely independent, read-heavy investigation, independent features, mechanical migrations, fan out and enjoy near-linear speedup. If the pieces are entangled by shared state or shared design decisions, keep it in one agent; a fleet will inject error, not remove it. Second, is it worth the tokens? A fleet costs roughly 4 to 15 times a single agent, so run one only when the task value clears that multiplier. For heavy recurring work, a flat Max subscription converts the unbounded API bill into a predictable monthly cost. Third, can you verify the output? If you cannot check a fleet's combined result with a fresh-context reviewer or a real test suite, you are not running a fleet, you are running a risk; build the verifier before you scale the writers.

On the tooling itself, the ranking is clear but the choice is yours. Claude Code is the most complete parallel-agent system in 2026, native subagents, worktree isolation, headless scripting, cloud sessions, and a matching SDK in one place, which is why it anchors the top of the table. OpenAI Codex and Google Jules lead on pure cloud fan-out, Factory Droid and Sourcegraph Amp on transparent economics and shared context, and the open-source options (Gemini CLI, OpenHands, Cline) win on cost and control for those willing to run their own compute. For teams who would rather deploy a managed cloud workforce than hand-run any of it, platforms like o-mega are the honest alternative. Start small, one explorer and one reviewer, prove the loop, then widen it only as far as your verifier and your budget allow. The fleet is a lever. Pointed well, it is the biggest productivity multiplier in software right now. Pointed carelessly, it is the fastest way yet invented to make ten mistakes at once.

This guide reflects the parallel-agent and Claude Code landscape as of August 2026. Model names, pricing, usage limits, and tool features in this space change constantly, verify current details against the official sources before you commit budget or architecture to them.