$ man how-to/parallel-agent-patterns

Parallel agents means running multiple AI agents at the same time on different tasks. Not one after another. All at once. The key word is independent. If Agent A needs the output of Agent B, they cannot run in parallel. If they touch different files, different data, different concerns — launch them simultaneously. This is the single biggest speed multiplier in AI-assisted development. A task that takes 45 minutes sequentially can finish in under 10 minutes with parallel agents. The speed gain is not theoretical. I build wiki pages, data files, and site routes in parallel every week.

PATTERN

Before launching parallel agents, check three things for each pair of tasks: 1. Do they write to the same files? If yes, they cannot run in parallel. File conflicts corrupt output. 2. Does one need the output of the other? If yes, they must run sequentially. The dependent task runs after the dependency completes. 3. Do they import from something that does not exist yet? This is the subtle one. If Agent A creates a data file and Agent B imports from it, they seem dependent. But if Agent B copies a known pattern (like mirroring an existing wiki page), it can run in parallel because the import structure is predictable. If all three checks pass, launch them in parallel. If any fail, sequence them. Do not force parallelism on dependent tasks. That creates more work, not less.

PATTERN

Complex features decompose into waves. Each wave contains tasks that can run in parallel. Waves run sequentially because later waves depend on earlier ones. Wave 1: Foundation — data files, shared components, type definitions. These have no dependencies on each other but everything downstream depends on them. Wave 2: Consumers — pages, routes, components that import from Wave 1 output. Multiple consumers can run in parallel because they touch different files. Wave 3: Integration — navigation updates, cross-links, export updates. These connect the Wave 2 outputs together. Wave 4: Verification — build, test, deploy. Sequential because each step depends on the previous. Mapping your feature into waves before you start is the planning step that makes parallel execution possible.

PRO TIP

Not every parallel agent needs the same model. Assign models based on task complexity, not uniformly. The orchestrating agent (the one that plans and launches the others) uses the capable model. It needs to reason about dependencies, context, and sequencing. Sub-agents doing copy-paste-and-adapt work use fast models. Building a route that mirrors an existing one. Updating a config file. Running a build check. These are mechanical tasks. Sub-agents doing creative work use the capable model. Writing 17 wiki entries with rich content. Architecting a new component. Anything that requires judgment or nuance. The result: you get speed (fast models complete quickly) and quality (capable models handle the hard parts) simultaneously.

ANTI-PATTERN

The most common mistake is launching agents on tasks that depend on each other. Agent A creates the type definitions. Agent B creates a component that uses those types. If they run in parallel, Agent B guesses the types instead of reading them. Sometimes the guess is right. Often it is not. And the debugging time wipes out any speed gain from parallelism. Another mistake: five agents all editing the same config file. Merge conflicts, overwritten changes, corrupted output. Each agent's changes look correct in isolation but break when combined. The fix: plan first. Map the dependencies. Group independent tasks into parallel waves. Sequence dependent tasks into separate waves. The planning takes 5 minutes. The debugging from bad parallelism takes 30.