Multi-Agent Workflows
Definition
Multi-agent workflows are software-building setups where a top-level orchestrator decomposes work into scoped, verifiable tickets and delegates them to specialized subagents that execute in fresh contexts.
Why they matter
The main claim in the source article is that single-agent coding runs hit a practical ceiling once projects become non-trivial. The failure mode is not just model quality; it is architectural. A single agent accumulates too much context, mixes planning with execution, and struggles to maintain reliable verification.
Core architecture
- A human communicates with one orchestrator.
- The orchestrator focuses on planning, decomposition, and coordination rather than direct file edits.
- Subagents receive only the minimum viable context for one task.
- Subagents return summaries instead of dragging full execution traces back into the orchestrator context.
- Verification is treated as a first-class phase rather than an optional afterthought.
Claimed benefits
- Context scaling — effective working context can grow far beyond one model window because work is split across fresh subagent contexts.
- Control — the workflow can enforce a sequence like plan → build → test → document instead of relying on one monolithic loop.
- Speed — independent tasks can run in parallel when they do not collide on the same files or dependencies.
Practical patterns
1. Prep line
Many independent agents produce alternatives against the same brief; the human curates the best outputs.
2. Dinner rush
Parallel subagents each own a distinct, well-bounded task contributing to one shared goal.
3. Courses in sequence
Projects are split into waves with strict dependencies between waves and parallelism inside each wave.
4. Prep-to-plate assembly
Work moves through a sequential pipeline of bounded stages with clean handoffs and explicit intermediate artifacts.
5. Builder-verifier split
Writer agents and verifier agents are separated so testing and review do not share the same incentives or context as generation.
Design constraints
- Parallelism works best when tasks do not touch the same files.
- The orchestrator should avoid becoming another all-purpose worker.
- State should live in files, task queues, and artifacts rather than in one ever-growing chat history.
- Verification should be layered on top of every pattern, not bolted on at the end.
Eval-integrity caveat
The Anthropic BrowseComp writeup adds an important warning for this pattern language: multi-agent setups can amplify contamination risk in web-enabled evaluations. Anthropic reports a 0.87% unintended-solution rate in a multi-agent BrowseComp configuration versus 0.24% in a single-agent one, suggesting that broader parallel search and higher total token budgets can make benchmark leakage or benchmark identification more likely.
Relation to this wiki
This article sharpens and operationalizes ideas already present in background-coding-agents and coding-agent-infrastructure-patterns. It is especially useful because it translates architectural ideas into a memorable kitchen metaphor plus a concrete pattern language.