Running Claude Agents in Parallel: A Practical Guide to Doing More Than One Thing at Once Without Creating Chaos

There is a specific moment when working with a coding agent stops feeling like a chat and starts feeling like managing a team. You realize you are sitting and watching one agent grind through a task while four other things you could be doing wait in line. The agent is fast, but it is serial, and you are the bottleneck holding the queue. The obvious next thought is “why am I only running one of these?” That question is the doorway to parallel agent work, and like most doorways, walking through it carelessly is how you end up in a worse place than you started.

Running many agents at once multiplies your output, but it also multiplies every problem: two agents editing the same file, a runaway loop quietly burning your rate limit, ten background sessions and no idea which one produced the change you actually want. So this is the detailed version of how to do it well. We will cover the three fundamentally different ways to parallelize, the isolation that keeps parallel edits from colliding, how to watch and control what is running, and the operating rules that separate “leveraged” from “chaotic.” Everything here maps to features in Claude Code, and the official reference lives at code.claude.com/docs/en/agents if you want exact flags.

“

Parallelism is free output only when the work is genuinely independent. The moment two agents share a file, a goal, or a dependency, you are not parallelizing, you are coordinating, and coordination needs design.

”

Three ways to parallelize, and why the difference matters

The single most common mistake is treating “run agents in parallel” as one thing. It is actually three different patterns, and choosing the wrong one is the root of most of the pain. They differ along one axis: how much the agents need to know about each other.

Agent View: many independent sessions

Agent View is for the simplest and most common case: several independent Claude Code sessions you want to dispatch, monitor, and come back to. Think of it as a control panel for a row of workers who do not need to talk to each other. You open it with claude agents, type a task and hit enter to dispatch one, and you can fire tasks straight from your shell with claude --bg "investigate the flaky checkout test". You can name a session so you can find it later, run a specific named agent against a task, peek at any session with the space bar, attach to one to take over, detach, pin the important ones, and stop or delete the ones you are done with.

The reason Agent View is the right default is that it matches how most real backlogs look: a pile of unrelated chores. Investigate a flaky test, bump a dependency, draft release notes, refactor a tired module. None of these depend on each other, so there is nothing to coordinate. You dispatch all four, go do something else, and the best rule is to only step in when one of them gets blocked. The mental model is a kitchen with four burners, not four cooks sharing one pot.

A few settings are worth knowing because they save real pain. You can scope a session to a directory, set defaults like the permission mode, model, and effort level so every dispatched agent inherits them, and set a default agent so you are not retyping it. There are also two caveats that bite people. First, auto-accept and bypass-permission modes have to be accepted once interactively before a background session can use them, so a fully unattended agent will silently stall on its first risky action if you skipped that. Second, on macOS, background sessions cannot read your Desktop, Documents, or Downloads unless you grant file access, which is a baffling failure until you know it.

Agent Teams: agents that coordinate

Sometimes the work is not independent. You want several agents pointed at one goal, sharing context, challenging each other’s findings, and dividing a problem by expertise rather than by task. That is Agent Teams, and it is experimental and off by default for a reason: coordination is where multi-agent systems get genuinely hard. You enable it with an environment flag or in settings.

The canonical example is a code review. You create a team to review a pull request with one teammate focused on security, one on performance, and one on tests. Each looks at the same change through a different lens, and crucially they can disagree, which is the entire point. A single agent reviewing its own analysis tends to agree with itself; three agents with different mandates surface the things one would have rationalized away. You can require a planning step so teammates get plan approval before they make changes, talk to a specific teammate, and clean up the team when you are done. The sweet spot is three to five teammates; past that, the coordination overhead eats the benefit.

The settings that matter here are subtle and have caused confusion. Teammates do not always inherit the lead agent’s model, so you may be running a weaker model than you think unless you set the default teammate model explicitly. They start with the lead’s permission settings. And the important one: Agent Teams do not isolate teammates in separate worktrees by default, so if several teammates can write files, you must partition who owns what or they will collide. The rule of thumb is to use Agent Teams only when coordination between agents genuinely adds value over simple parallelism. If the agents never need to talk, you wanted Agent View.

Dynamic Workflows: a repeatable plan, not turn-by-turn judgment

The third pattern is for when you do not want the agent improvising the plan at all. Dynamic Workflows are for audits, migrations, deep research, cross-checking, and large repeatable work, the kind of thing where the steps are known and you want them executed the same way every time rather than rediscovered on each run. There is a built-in deep-research workflow, and you can ask for a workflow in plain language (“audit every API endpoint under the routes directory for missing auth checks”) or trigger one directly with the workflow keyword. You monitor running workflows, inspect their phases, pause and resume, stop, restart a stuck agent, and save a workflow so it becomes reusable. Project workflows live in the repo so the team shares them; personal ones live in your home directory.

The mental shift with workflows is from judgment to script. An agent decides what to do next based on what it sees; a workflow follows a plan you defined. When the task is repeatable and you have done it enough to know the steps, encoding it as a workflow makes it reliable and shareable in a way that re-prompting an agent never is. The best rule: reach for a Dynamic Workflow when the plan should live in a repeatable script instead of the agent’s moment-to-moment judgment. One caveat worth internalizing: a workflow’s intermediate results live in the script’s own variables, not in Claude’s context window, which is a feature for keeping the context clean but a surprise if you expected the agent to “remember” what an earlier phase found.

Isolation: the thing that makes parallel edits safe

Here is the failure mode that ruins parallel work faster than any other: two agents editing the same files at the same time, silently overwriting each other. The fix is isolation, and the primary tool is the git worktree.

A worktree is a private checkout of your repository on its own branch, so an agent can edit freely without touching what any other agent or you are doing. You start a session in a worktree with claude --worktree feature-auth, start another in its own worktree, and tell subagents to use worktree isolation. Because a fresh worktree does not carry your untracked local files, there is a .worktreeinclude mechanism to copy across the ones an agent actually needs, like environment files or local secrets config. You list worktrees and remove them with normal git commands when you are done.

A handful of worktree settings save headaches. Run Claude once in the repo first to accept the workspace trust dialog, because a worktree session will stumble on trust otherwise. Add the worktrees directory to your gitignore so they do not pollute status. New worktrees branch from the repository default by default; you can tell them to branch from the current HEAD instead when that is what you want. And for the rare case where background isolation is genuinely impractical, you can disable it, though that is a last resort, not a default.

For one particular shape of work there is a packaged version of all this: the batch command. When you have one large change that naturally splits into many isolated pull requests, you describe the large change and Claude spins up somewhere in the range of five to thirty worktree-isolated subagents, each opening its own PR. It is the right tool when you want parallel implementation that flows into a normal PR review process. Treat it as a skill for that specific situation, not as a general coordination style.

Watching and controlling what is running

The moment you have more than one or two agents going, “what is even happening right now?” becomes the real question, and a set of monitoring commands answers it. You can list subagents, see current-session background work, list background sessions, and view running workflows. For any individual run you can attach to it to take over, read its logs, stop it, restart it, or remove it, and you can check the status of the background daemon that keeps it all alive.

There is also a lighter-weight tool for the common case of “run this one shell command without blocking my conversation”: background bash. Firing a long test run in the background from a session or the shell is the right call for plain commands. The line to hold is that background bash is for commands, not for reasoning or agent work. If the thing needs to think, it is an agent; if it just needs to run, it is background bash.

The operating rules that keep this sane

All of the above is mechanism. The judgment is in a small set of operating rules, and they are what separate someone who gets real leverage from someone who creates an expensive mess.

“

Running many agents does not reduce your work. It changes it, from doing the work to designing, partitioning, and reviewing it. That is a better job, but it is still a job.

”

If you take one thing from all this, let it be the progression. Start with a single agent until you feel the queue back up. Move to Agent View for independent tasks, which covers most of what you need. Reach for Agent Teams only when agents genuinely have to coordinate, and Dynamic Workflows only when the plan deserves to be a reusable script. Isolate with worktrees the instant edits might overlap. And scale the number of agents slowly, watching cost and your own review capacity, because the goal was never to run the most agents. It was to get more real, reviewed, trustworthy work out the door, and that goal punishes carelessness exactly as fast as it rewards good design.