Domain 1 · Task Statement 1.4

Sub-Agents & Parallel Execution

TL;DR

Understand how Cowork's sub-agent architecture enables parallel task execution, when parallelism genuinely accelerates work, and when it introduces costly failures.

What You Need to Know

Most people discover Cowork's parallel execution by accident — they ask Claude to process a batch of files and notice multiple progress bars moving at once. Impressive. But the exam demands more than awe. You need to understand what is happening underneath, why it costs more than you expect, and when it quietly makes things worse.

How Sub-Agents Work

Hand Cowork a task involving repetitive, independent work — summarising 20 documents, say — and Claude won't plod through them one at a time. It decomposes the job and spins up sub-agents: parallel workers that each handle a slice of the batch simultaneously. Twenty files might become five sub-agents processing four files each. What took 30 minutes now finishes in under five.

Each sub-agent is its own reasoning process — it receives a portion of the work, executes independently, and returns results. The parent agent acts as coordinator: splitting the work, launching sub-agents, collecting outputs, assembling the final result. Picture a team lead who breaks a project into work packages, assigns each to a different person, then compiles everything into one report.

[!]

Sub-Agents Run Locally

Every sub-agent runs inside the sandboxed VM on your machine — not on Anthropic's cloud servers. Close the Desktop app or let your machine sleep and every sub-agent stops immediately. No background cloud process keeps things alive. Running a 40-file batch extraction? Your machine must stay awake until it finishes.

Triggering Parallelism: No Special Syntax Required

A common exam trap: the belief that you need a slash command like /parallel to activate sub-agents. You don't. No special syntax exists. Claude picks up on natural language patterns that imply batch work:

  • "For each one..." — signals iteration across a collection
  • "Analyse all..." — signals a batch operation
  • "Process these..." — signals multiple items to handle
  • "Do this in parallel" — an explicit instruction that removes any ambiguity

You can also just say it outright: "Process these in parallel — don't do them one at a time." Explicitness never hurts. But the key insight is that Claude infers parallelism from the shape of your request. If the work is naturally decomposable, it will typically parallelise on its own.

When Parallelism Helps

Sub-agents shine when the work consists of independent units — tasks where one unit's output has no bearing on another's inputs. The pattern to recognise:

  • Batch file processing — analysing, renaming, converting, or summarising many files where each file stands alone
  • Multi-document research — reading and synthesising 10+ sources where each source can be summarised independently before the synthesis step
  • Data extraction — pulling structured information from dozens of invoices, receipts, contracts, or reports
  • Report generation — building sections independently (executive summary, financial overview, risk analysis) before combining them

The common thread: you could hand each unit to a different person and they wouldn't need to talk to each other until the final assembly step.

When Parallelism Hurts: Sequential Dependencies

Parallelism fails — sometimes silently — when Step 2 requires the completed output of Step 1. The exam hammers this concept.

Take this task: "Analyse each document's content, then rename the files based on what you found." The analysis must finish before renaming can begin. If Claude parallelises both steps, a sub-agent might try to rename a file before its content has been analysed — producing nonsensical filenames or outright errors.

Claude usually recognises these dependencies. Usually. Not always. When you see issues, add explicit sequencing: "Do these steps in order — finish all the analysis before starting the renames." The exam tests whether you can spot which tasks have dependencies and which don't.

[!]

Sub-Agents Cannot Communicate Mid-Process

Once launched, sub-agents work in isolation. They cannot share intermediate findings or coordinate during execution. If File B's processing genuinely depends on what was found in File A, parallelism will produce errors or hallucinated data. This is the single most important constraint to internalise.

The Token Cost Trade-Off

Here is what catches people out: parallel execution uses more tokens, not fewer. Each sub-agent needs its own reasoning stream, its own context window, its own tool calls. Five sub-agents processing four files each burn considerably more of your usage allocation than one agent working through 20 files sequentially.

Speed for cost — that's the trade-off. A sequential run of 20 files might take 30 minutes and consume X tokens. A parallel run finishes in 5 but burns 3-4X. On a Pro plan with tighter rate limits, that difference bites. One ambitious batch job can exhaust your daily allocation entirely.

The expert move: knowing when speed justifies the cost. Urgent deadline, 50 client reports due today? Parallelise aggressively. Routine weekly tidy-up of your Downloads folder? Run it sequentially and save your allocation for when it counts.

The Error Multiplication Problem

Skip the plan review and any error in Claude's approach gets multiplied instantly. Sequential processing gives you an early warning — you spot the mistake on file 2 and stop before it reaches file 20. Parallel processing offers no such safety net. A wrong naming pattern hits 50 files at once. A misidentified column gets extracted from 30 spreadsheets simultaneously. The damage is instant, total, and entirely avoidable.

Thirty seconds reading the execution plan before you approve it. That is the difference between a quick fix and an hour of manual cleanup.

Common Mistakes

Common Mistake

Closing the Desktop app or letting your machine sleep during a parallel batch job, assuming Cowork continues processing in the cloud.

Instead: Keep the app open and your machine awake for the entire duration. All sub-agents run locally in the sandboxed VM — close the app and every sub-agent stops immediately with no recovery option.

Common Mistake

Forcing parallelism on tasks with sequential dependencies, such as asking Claude to 'analyse content and rename files based on the analysis — do everything in parallel.'

Instead: Identify whether steps depend on each other. If Step 2 needs Step 1's output, instruct Claude to finish the first phase before starting the second. Use explicit sequencing: 'Complete all the analysis first, then rename the files based on the results.'

Common Mistake

Skipping the execution plan review for batch operations because the task looks straightforward.

Instead: Always review the plan before approving parallel execution. A single error in the approach gets multiplied across every sub-agent simultaneously. Sequential processing lets you catch the mistake on file 2; parallel processing means all 50 files are already wrong.

You need to summarise every document in a project folder and compile the summaries into a single research digest.

Before

Read file 1, summarise it. Then read file 2, summarise it. Then file 3. Continue until every file is done. Then combine them into one document.

After

Summarise every document in this folder. Create a one-paragraph summary for each and compile them into a single Research Digest. Process the summaries in parallel.

You need to clean up a folder: rename files to include today's date, move images to an /Images subfolder, and create an inventory list.

Before

I need you to clean up this folder. First, rename all files to include today's date. When that is completely finished, move images into an /Images folder. Finally, create a list of all the files you moved.

After

Clean up this folder: rename all files to include today's date, move images into /Images, and create an inventory list. The renaming and the image move are independent — do those in parallel. Create the inventory list after both are done.

Hands-On Activity

Hands-On Activity

Trigger and Observe Parallel Sub-Agents

10 min

Create a batch of files, trigger parallel processing, and observe the difference between parallel and sequential execution patterns.

What you will learn

  • Recognise the natural language patterns that trigger sub-agent parallelism
  • Observe multiple sub-agent progress bars running simultaneously
  • Understand the relationship between file count and parallelisation behaviour
  1. 01

    Create a folder on your desktop called 'Parallel-Test'. Add 10-15 small text files — copies of the same document, random notes, or placeholders. The content doesn't matter; you just need enough files to trigger parallelisation.

    Why: With fewer than 5 files, Claude may process them sequentially because the overhead of spinning up sub-agents outweighs the speed gain. You need a large enough batch to make parallelism worthwhile.

    Expected: A folder containing 10-15 text files ready for processing.

  2. 02

    Open Cowork, select the 'Parallel-Test' folder as your working directory, and enter: 'Look at every file in this folder. For each one, write a two-sentence summary and save it as [original-name]-summary.txt. Do this in parallel.'

    Why: The phrase 'for each one' combined with 'in parallel' explicitly triggers sub-agent coordination. Watch how the execution plan reflects the parallel approach.

    Expected: An execution plan showing multiple files will be processed simultaneously, not one at a time.

  3. 03

    Click Run and watch the progress indicators. Count how many sub-agent progress bars appear simultaneously.

    Why: This makes parallelisation visible. Multiple progress bars advancing concurrently is direct evidence of sub-agents working in parallel.

    Expected: Multiple sub-agent progress bars running at the same time. Total execution time noticeably faster than processing 10-15 files individually.

  4. 04

    Once complete, open the folder and verify that every original file has a corresponding [name]-summary.txt with an accurate two-sentence summary.

    Why: Parallel execution should produce identical quality to sequential processing — the only difference is speed. Missing or incorrect summaries suggest the batch was too large or a sub-agent hit an error.

    Expected: One summary file per original, with accurate two-sentence summaries reflecting the actual content.

Practice Question

Practice Question

A project manager has 40 individual weekly status report PDFs. They need to extract the 'Current Blockers' section from every PDF and compile them into one 'Risk Registry' Excel file. Which approach is most efficient?

Sources