$ man how-to/orchestrating-multi-agent-workflows

You are the orchestrator. Claude is the workforce. Your job is not to write code. Your job is to plan the work, assign the agents, provide the context, and verify the output. Think of yourself as a project manager who happens to have an infinite supply of capable workers available instantly. The bottleneck is not labor. It is planning. A well-planned multi-agent workflow finishes in minutes. A poorly planned one finishes in hours (or not at all) because agents step on each other, produce conflicting output, or miss requirements that were not in their instructions.

PATTERN

Start every multi-agent workflow in plan mode. Ask Claude to analyze the task, identify all the files that need to be created or modified, map the dependencies between them, and group independent tasks into parallel waves. The plan should include: files to create (with full paths), files to modify (with specific changes), the wave structure (which tasks run in parallel, which run sequentially), model recommendations per agent, and verification steps. Review the plan before executing. If a dependency is wrong, fix it now. If a task grouping does not make sense, adjust it now. Changes to the plan cost nothing. Changes after agents have started cost time and context.

PATTERN

Each agent gets its own prompt with its own context. Agents do not share context with each other. Agent B does not know what Agent A is doing. That is a feature, not a bug. It means you have full control over what each agent sees and does. A good agent prompt includes: the specific task ("Create the file website/packages/shared/data/how-to-wiki.ts"), the pattern to follow ("Mirror the structure of clay-wiki.ts"), the specific data or content to include, references to files it should read for context, and the success criteria ("The file should export a typed array of 17 entries with full WikiSection content"). Bad agent prompts are vague. "Build the wiki." Good agent prompts are specific. "Create how-to-wiki.ts with the HowToWikiEntry interface, 6 categories, 17 entries, and helper functions following the exact pattern of context-wiki.ts."

FORMULA

Launch Wave 1 agents in parallel. Monitor their progress. When all Wave 1 agents complete, verify their output before launching Wave 2. Verification between waves catches errors early. Verification checklist per wave: - Do the created files exist at the expected paths? - Do the types and interfaces match what downstream consumers expect? - Does the build still pass after the wave's changes? - Are there any TypeScript or linting errors? Only after verification passes do you launch the next wave. If an agent produced bad output, fix it before proceeding. A bad foundation from Wave 1 means every Wave 2 agent builds on broken assumptions. Final verification after all waves: build the entire project, check all routes render, verify cross-links resolve, confirm SEO metadata is correct. This is the last quality gate before the feature ships.

PRO TIP

When I built the Clay Wiki, the orchestration was: Wave 1 — one agent wrote the data file (all 17 entries, types, helpers). Wave 2 — three agents ran in parallel: hub page component, detail page component, and ShawnOS route setup. Wave 3 — two agents ran in parallel: navigation updates and cross-link backfills. Wave 4 — one agent ran the build and verified all routes. Total time: under 15 minutes. Sequential time estimate: over 45 minutes. The speed difference came from planning. Identifying which tasks were independent. Grouping them into waves. Giving each agent exactly the context it needed. The actual execution was fast. The planning is what made the execution possible.