Monday, November 18, I was deep in the Claude Code documentation.
The testing bottleneck was killing me. Workflows taking 20-50 minutes with wildly inconsistent times. I needed to understand how agent execution actually worked.
That’s when I found it: parallel agent invocation.
The Discovery
I’d been invoking agents sequentially. One at a time. Wait for it to finish. Invoke the next one. Wait for that to finish. And so on.
The documentation showed a different way:
Same message, multiple Task tool calls All agents launch simultaneously Results come back when each completes
I could invoke multiple agents at once.
Why It Could Work
I analyzed my workflows to find where parallel execution made sense.
Each worker was fixing a single class. No other worker was touching that same class. Worker A fixes Class A. Worker B fixes Class B. Worker C fixes Class C. All at the same time.
No conflicts. No competition. No workers stepping on each other’s changes.
That isolation made parallel execution safe. Multiple workers could run simultaneously because they weren’t interfering with each other.
The Implementation
Parallel invocation isn’t automatic. You have to explicitly design for it.
The key is putting multiple Task tool calls in the same message:
Message to Claude: "Launch these workers in parallel: - Task: Fix Class A - Task: Fix Class B - Task: Fix Class C"
Claude sees multiple Task calls in one message and launches them all simultaneously.
If you send them in separate messages, they run sequentially. Same message, same moment—that’s what triggers parallel execution.
Where It Helped
The impact was dramatic.
Multi-file processing: 10 files × 2 minutes each = 20 minutes sequential. All 10 files parallel = 2 minutes total (90% faster)
Same work. Same results. Just all happening at once instead of one after another.
The more independent work you have, the more parallel execution helps.
The Limitations
Parallel execution doesn’t solve everything.
You still need to wait for all workers to complete before you can continue. If one worker takes 10 minutes and nine others take 1 minute, you’re waiting 10 minutes.
Parallel execution helps with independent work. It doesn’t eliminate waiting. It just makes better use of time by doing multiple things at once instead of one thing at a time.
The Consistency Benefit
Parallel execution didn’t just make workflows faster. It made them more predictable.
Sequential execution had wild timing inconsistencies. The time depended entirely on how many classes were in each repo. Some repos had 3 classes. Others had 15. Timing varied dramatically from run to run.
With parallel execution, I could run up to 10 classes simultaneously. That normalized the timing. Instead of wildly different durations, runs became more consistent. Not perfectly predictable, but far more stable than sequential execution.
Parallel execution reduced both time and variability.
Monday Evening
Monday, November 18, I redesigned my workflows to use parallel invocation wherever possible.
Independent workers launched simultaneously. Sequential dependencies stayed sequential. Clean separation between parallel and serial execution.
Workflows got noticeably faster and more consistent.
But I kept noticing something odd. Sometimes runs seemed longer when there was more output. More explanations. More status updates. I couldn’t be completely sure, but it seemed like the verbosity was a factor in timing.
Was the interactive mode itself adding variability?