Subagents are having a moment. Spin up workers. Parallelize the grind. Feel like a conductor.
Sometimes that saves real money and time. Sometimes it is a fancy way to multiply confusion and token burn.
The difference is usually whether the tasks are independent or share state.
When subagents save money
Parallel workers shine when:
- tasks do not need each other’s partial outputs
- each unit of work has a clear brief and clear done criteria
- merges are mechanical (summaries into a list, file-by-file edits in isolated paths)
- failure in one worker does not corrupt the others
- you can cap spend per worker
Examples you like:
- reviewing five unrelated docs for the same checklist
- generating first-pass summaries of separate meeting transcripts
- scanning different packages for a simple pattern
- producing draft alternatives you will judge serially afterward
Independence is the unlock. Without it, parallelism is theater.
When subagents waste it
Shared state kills the dream.
If worker A refactors a module while worker B edits the same module’s types, you are not faster. You are creating merge pain and billing both of them for the privilege.
Waste also shows up when:
- the parent agent spends more tokens coordinating than the workers save
- workers duplicate research because they cannot share memory cleanly
- you parallelize a fundamentally serial debugging chain
- nobody aggregates results into a single verified outcome
- you run five weak passes instead of one strong brief
At that point a single agent with a better checklist beats a committee.
A decision rule you use
Ask: Can these tasks pass in separate rooms without talking, then be stapled together by a human or a thin merge step?
If yes, consider subagents.
If they need continuous consensus about the same files, types, or customer record, stay serial.
Cost model in plain English
Parallelism can reduce wall clock and increase spend. Those are different goals.
If you care about latency for a user waiting, paying more for parallel drafts can be rational.
If you care about overnight batch cost, parallel may be optional. Serial with a queue may be cheaper and easier to debug.
Write down which goal you are buying before you spawn workers.
Practical orchestration tips
- Give each worker a narrow filesystem scope.
- Forbid overlapping write paths.
- Require structured outputs (JSON/markdown sections) for easy merge.
- Put a spend ceiling on each worker.
- Keep one judge/aggregator step at the end, preferably explicit.
Checklist
- Tasks listed as independent or dependent
- Write scopes do not overlap
- Merge plan written before launch
- Budget per worker set
- Serial fallback identified
Story
I once parallelized “cleanup” across a repo and created four elegant incompatible styles. It looked productive in the logs. It was a weekend to untangle.
Next time I parallelized only the research notes, then did the code edits serially. Cheaper. Faster in human time. Less heroic.
Closing
Subagents save money when work is independent and mergeable. They waste money when they fake independence on shared state.
Conductor metaphors are fun. File locks and clear briefs are profitable.
Use the committee only when the committee does not need to share a pencil.
Parent agent discipline
The parent should write contracts, not vibes: inputs, outputs, deadlines, budgets, forbidden paths.
If the parent prompt is mushy, parallel workers become five mushy children. Tight contracts make parallelism look intelligent. Loose contracts make it look expensive.
Closing
Independent tasks: parallelize. Shared state: serialize. Your wallet can tell the difference even when the demos cannot.
Debugging parallel runs
When parallel runs go weird, log worker ids, prompts, and outputs as separate artifacts. Otherwise you will try to debug a blur. Blurry failures create folklore. Artifacts create fixes.
Closing reminder
If you cannot draw the merge step on a napkin, you are not ready to spawn workers. Draw first. Parallelize second.
Bottom line
If wall-clock speed is not the bottleneck, default to one careful agent. Boredom with serial work is not a business case for a token fireworks show.
