More roles do not automatically create more work
A planner, researcher, writer, critic, and editor may look like five agents. If the researcher cannot begin until the planner finishes, the writer cannot begin until research is complete, and the critic must wait for the draft, the system still has one long critical path. It now also has four handoffs.
By contrast, comparing five independent contracts can be genuinely parallel. Each worker can receive one frozen document and the same extraction schema. A root agent can then reconcile the five bounded reports. The architecture earns its complexity because the work graph has parallel branches.
Draw the dependency graph first
List the units of work and connect every real dependency. A task is a candidate for delegation only when another agent can complete it from a bounded input without waiting for an unfinished unit.
Good parallel shape
┌─ inspect package A ─┐
frozen inventory ───├─ inspect package B ─┼── reconcile against one rubric
└─ inspect package C ─┘
Mostly serial shape
requirements → schema → migration → application change → integration testThe serial workflow may still use a specialist for a review after the implementation is stable. It usually should not have several agents writing the migration and application code at once unless ownership is cleanly separated.
The six factors that matter
1. Independence
The strongest signal is whether work units can be completed independently. Separate repositories, documents, hypotheses, modules, or test suites are promising. A calculation whose step two needs the exact result of step one is not.
2. Context separation
Subagents can protect focus by keeping unrelated evidence in separate contexts. That helps when one agent studies legal terms, another inspects code, and another reviews data quality. It hurts when every worker needs the same evolving conversation and subtle shared decisions; summaries then become lossy handoffs.
3. Shared-state contention
Read-only exploration parallelizes well. Disjoint writes can also work when file or module ownership is explicit. Frequent writes to the same document, database schema, branch, browser session, or account create conflict and make attribution difficult. A queue does not fix the fact that only one operation can safely own the shared state.
4. Synthesis burden
Parallel work is not finished when the subagents stop. Someone must detect contradictions, normalize evidence, remove duplication, resolve different assumptions, and apply the final acceptance criteria. If that synthesis requires rereading every source, the apparent speedup may vanish.
5. Verification
Delegation is much easier when each output has a clear contract and local test. “Return every deprecated API in this module with file and line” is verifiable. “Make the product strategy better” is not a bounded leaf task. The final integrated result still needs its own test; individually correct pieces can conflict.
6. Latency and cost
Parallel agents can reduce wall-clock time, but they usually consume more total tokens and tool calls. They also add orchestration and synthesis overhead. A small task that one capable agent finishes in a short run rarely benefits from delegation. One slow external operation—waiting for a build, API, or human review—also remains the bottleneck no matter how many agents are waiting.
A practical decision table
| Task property | Prefer one agent | Consider multiple agents |
|---|---|---|
| Dependencies | One ordered chain | Several independent branches |
| Size | Fits comfortably in one focused run | Independent work would otherwise be sequential |
| Context | Shared nuance matters throughout | Separate domains benefit from isolation |
| Writes | Same mutable files, DB, browser, or account | Read-only work or disjoint ownership |
| Output | One integrated artifact | Bounded reports with a clear merge contract |
| Verification | Only an end-to-end test exists | Each branch and final synthesis are testable |
| Budget | Token/tool cost is tight | Wall-clock reduction is worth added cost |
Three worked decisions
Case A: update one configuration and its test
The change touches one setting, one loader, and one integration test. Each step depends on the previous understanding, and the files share state. One agent is simpler. A second agent could review the final diff, but parallel implementation would mostly duplicate context.
Case B: compare eight independent vendor policies
The documents are frozen and each can be extracted into the same evidence schema. Independent read-only work can happen in parallel. A root agent owns the source inventory, assigns non-overlapping documents, and reconciles every required field. This is a good multi-agent trial—as long as the final report preserves source identity and does not hide disagreements.
Case C: perform a database migration
Schema design, migration SQL, application changes, and replay tests form an ordered chain with high shared-state risk. One agent should own the implementation. Parallel read-only review of rollback risks or affected queries may help after the proposed schema is frozen, but multiple writers do not shorten the transactional critical path.
Choose the orchestration pattern deliberately
Two broad patterns recur. In a manager pattern, the root agent retains control, calls specialist agents as tools, and synthesizes the answer. This works when one final voice and central policy ownership matter. In a handoff pattern, one specialist transfers control to another because the next agent should own the continuing conversation or task.
Do not use a handoff to disguise missing synthesis. If the final output must reconcile several independent findings, one accountable agent should receive them all and apply a common contract.
Write leaf tasks like interfaces
A delegable task should state:
- the exact bounded objective;
- the supplied inputs and source boundary;
- allowed tools and whether writes are permitted;
- the required output schema;
- pass, fail, and stop conditions;
- what must be reported as unknown;
- who owns final synthesis.
“Research competitors” is not enough. “For these four frozen pricing pages, return plan name, public monthly price, billing period, included seats, source URL, and an UNKNOWN marker when the page is inaccessible; do not infer annual equivalents” is.
Evaluate the coordination, not only the answer
A multi-agent eval should include ordinary output quality plus architecture-specific behavior:
- Was work delegated only when independent?
- Did each subagent stay inside its source and write boundary?
- Were inputs duplicated or important files left unowned?
- Did the root detect conflicting findings?
- Did handoffs preserve required context and authority?
- Did parallel writes collide?
- How did wall-clock time, tokens, tool calls, and failure rate compare with one agent?
Run matched comparisons on representative tasks. Keep the model, tools, data, acceptance criteria, and attempt count aligned. A single attractive demonstration is a candidate result, not evidence that multiple agents are better in general.
Use a stop rule
Multi-agent systems can continue discovering more branches long after the useful work is complete. Set limits before the run: maximum active subagents, maximum depth, maximum retries, total tool or token budget, and conditions that require the root to synthesize or ask for help.
The current OpenAI documentation describes Multi-agent as a beta capability on supported models and notes that adding subagents can increase token use. Availability and schemas can change, so implementation details should come from the current official page rather than a copied snippet.
The downloadable worksheet
The One Agent or Multiple Agents Decision Worksheet turns these factors into a short design review. It asks for the finish line, dependency graph, shared writes, output contracts, verification, cost tolerance, and one of three decisions: ONE_AGENT, MULTI_AGENT_TRIAL, or INSUFFICIENT_EVIDENCE.
The scores are prompts for judgment, not a universal threshold. A single high-risk shared database can outweigh six favorable factors. Record what evidence would change the decision and revisit it after a matched trial.
Read this article's evidence ceiling
This page applies official architecture guidance to worked task graphs. It does not report a matched performance experiment. No production workload, API latency, token cost, model comparison, or quality benchmark was run for the article. The honest next step for a team considering delegation is a small paired trial on its own representative tasks.
Bottom line: start with one agent. Add another only when you can point to a bounded parallel branch, give it a stable interface, prevent shared-state collisions, and verify that the final synthesis earns back the added cost and complexity.
