PARALLELISM CONTROL PLANE · 2026

Parallel work is not a speed button.
It is a coordination model.

Choose by who coordinates, whether workers must communicate, and which state can collide. More agents only help after the work has clean boundaries.

SOURCE REVIEWED · 2026-07-19

Capabilities and product states below come from current official Claude Code documentation. Decision rules, costs, and failure patterns are ClaudeWorld analysis—not performance guarantees.

CHOOSE THE CONTROL MODEL

Five surfaces. Different ownership.

Subagents, Agent View, Agent Teams, and Dynamic Workflows run work differently. Worktrees are the file-state isolation layer that can support several of them.

MODE / 01 Documented

DELEGATED SIDE WORK

Subagents

Use when: A bounded side task would flood the main context with searches, logs, tests, or file contents.
Coordinator: The parent conversation delegates and synthesizes.
Communication: Each worker returns a result to its caller; peers do not share a team channel.
State boundary: Fresh context by default; a worktree can isolate edits.
Cost shape: Startup plus one active context per worker.
Watch for: Keep tightly coupled phases in the main conversation when they need the same working context.

Official source

MODE / 02 Research preview

HUMAN-SUPERVISED SESSIONS

Agent View

Use when: You have several independent jobs and want to dispatch, inspect, reply, attach, and return later.
Coordinator: You supervise complete background sessions.
Communication: Sessions report to you, not directly to one another.
State boundary: Dispatched editing sessions use separate worktrees.
Cost shape: A full session and quota usage for every active job.
Watch for: This is an operations console, not a peer-to-peer team protocol.

Official source

MODE / 03 Experimental

COORDINATED PEERS

Agent Teams

Use when: Workers must share tasks, manage dependencies, message peers, or challenge competing hypotheses.
Coordinator: A team lead plans, assigns, and supervises.
Communication: Shared task list plus direct teammate messaging.
State boundary: No automatic teammate worktrees; partition file ownership.
Cost shape: Highest interactive cost: a full context per teammate plus coordination.
Watch for: Experimental and disabled by default. More communication can become noise; same-file edits can still overwrite one another.

Official source

MODE / 04 Documented

SCRIPTED EXECUTION GRAPH

Dynamic Workflows

Use when: The job outgrows a handful of workers or needs a repeatable graph with cross-checking.
Coordinator: A JavaScript workflow holds the execution plan.
Communication: Structured phase outputs and scripted validation replace free-form peer chat.
State boundary: Defined by the workflow and the workers it launches.
Cost shape: Scales across many agent runs; budget and failure policy must be explicit.
Watch for: Best for stable work shapes, not tasks that need constant human steering mid-run.

Official source

LAYER / FS Supporting layer

FILE-STATE ISOLATION

Worktrees

Use when: Two sessions or subagents may modify the same repository at the same time.
Coordinator: Pairs with a human, subagent, or session control model.
Communication: None. A worktree does not coordinate workers.
State boundary: Separate checkout and branch; shared repository history.
Cost shape: Environment setup, disk, dependency, review, and merge overhead.
Watch for: It prevents direct file collisions, not semantic conflicts, unsafe actions, or bad merges.

Official source

ROUTING LOGIC

Ask these questions in order

Start with the smallest control surface that closes the responsibility. Add workers only when the next answer requires them.

Q01
Does one bounded result return to this conversation?

YES Subagents
Best default for isolated research, logs, tests, and focused review.
Q02
Do you want to supervise separate, independent conversations?

YES Agent View
Pair editing work with the worktrees Agent View provisions.
Q03
Must workers coordinate dependencies or message one another?

YES Agent Teams
Use only when the shared task list and mailbox repay their token cost.
Q04
Is the work shape large, repeatable, and cross-checked?

YES Dynamic Workflows
Put the plan, fan-out, barriers, and validation into code.
Q05
Could two branches edit overlapping files or state?

YES Partition first · add Worktrees
If ownership cannot be separated, serialize the write phase.

PARALLELISM ADMISSION TEST

Every branch needs a contract

A worker is not a plan. Before fan-out, make the dependency, ownership, output, and merge boundaries explicit.

GATE / 01

Independent dependency

No branch waits for another branch’s unfinished output.

GATE / 02

Exclusive ownership

One owner per file set, state surface, or external side effect.

GATE / 03

Bounded return

Return evidence, a patch, or a decision—not an unfiltered transcript.

GATE / 04

Isolated state

Use read-only work or a worktree when file changes can collide.

GATE / 05

Single merge gate

One lead synthesizes, tests, resolves conflict, and verifies the outcome.

Do not parallelize by reflex

These shapes usually lose more to coordination than they gain from fan-out.

Serial dependency chain

B needs A’s result, so concurrent starts only create rework or waiting.

Shared mutable surface

Several workers edit the same files, schema, environment, or external record.

Tiny task

Startup and synthesis cost exceed the work itself.

Unclear question

Workers multiply the ambiguity and return incomparable answers.

Tight budget

Every active context consumes quota; concurrency is not free throughput.

REFERENCE DISPATCH

Parallelize evidence. Serialize the decision.

A safe investigation fans out independent evidence gathering, then crosses one synthesis barrier before any shared write.

MISSION Find the cause of a checkout latency regression without letting three workers race to patch the same code.

A / RUNTIME

Inspect logs and latency metrics

Return the first divergent signal with timestamps and evidence.

B / HISTORY

Review recent changes

Return the smallest suspect commit set and why each could affect latency.

C / PATH

Trace the request path

Return the measured or reasoned bottleneck boundary; do not edit.

BARRIER → SYNTHESIS → ONE OWNER

The lead compares evidence, chooses one hypothesis, assigns one implementation owner, then runs tests and production-shaped verification.

PROMPT PATTERN

First identify independent evidence branches. Run only those branches in parallel. Give each worker one bounded return contract and no overlapping write ownership. Synthesize the evidence before implementation, then let one owner edit and verify.