Multi-Agent Orchestration: When Two Agents Beat One

Multi-agent orchestration is useful when a task contains work that can be separated, checked, and recombined without constant negotiation. A second agent is not automatically a second opinion or a speed improvement. It is another execution context, another budget, and another possible source of inconsistent state.

The takeaway: add an agent only when an independently verifiable work boundary earns back the cost of delegation and integration. Keep one owner accountable for the final result and any external effects.

This is architecture guidance, not a benchmark report. The examples below are illustrative designs; no new comparative runs or performance measurements are being claimed.

Multi-agent systems need a task boundary, not a cast

A team of agents named researcher, critic, architect, and executor can still be one tightly coupled task spread across four conversations. Role names do not establish independence. Start by drawing the dependencies between outputs.

Consider a documentation migration. One worker can inventory broken links while another checks whether example commands match the current CLI documentation. Both can read the same fixed revision and return findings with file locations. The coordinator can validate and integrate those findings afterward.

By contrast, asking two workers to rewrite the same introductory section creates shared ownership. Each must account for the other’s edits, terminology, and assumptions. Unless the workflow deliberately produces separate alternatives for a later selection step, the split has created a merge problem rather than removed a bottleneck.

A useful delegation boundary has three properties:

• Inputs are stable enough: the worker knows which snapshot, revision, or source set its answer describes.
• Outputs have an acceptance test: the coordinator can distinguish a complete result from a plausible summary.
• Ownership is explicit: another worker cannot silently overwrite the same artifact or perform the same external action.

These properties matter more than whether the agents use different models or elaborate personas.

Parallel research is a good candidate, not a universal proof

Anthropic’s account of its multi-agent research system describes a lead agent delegating independent research directions to subagents. It identifies breadth-first queries as a strong fit while discussing token overhead, context sharing, and coordination difficulties.

That is evidence about a particular research system, not a promise that duplicating your agent will improve every workload. A search across several independent companies has different dependencies from a repair whose next step depends on interpreting the previous compiler error. Parallel research can widen coverage; a sequential debugging chain may offer little work to distribute until the cause becomes clearer.

Before adding agents, also ask whether ordinary parallel tool calls solve the problem. Fetching several known URLs does not necessarily require several autonomous workers. Use another agent when the subtask needs its own bounded investigation, context, or adaptive tool loop—not merely because several requests can run concurrently.

Agent handoffs should carry contracts and evidence

A delegation message is an interface. Specify its contract with the same care you give a tool schema. “Look into authentication” leaves scope, authority, and completion undefined.

An illustrative review brief could contain:

Field	Example
Objective	Identify documented authentication changes affecting this migration
Inputs	Pinned source revision and the supplied target-version documentation
Scope	Read authentication docs and examples; do not edit files
Deliverable	Findings with file locations, source references, and unresolved questions
Completion test	Every supplied authentication example classified or explicitly marked unresolved
Budget	Stop at the assigned deadline and return partial evidence if incomplete
Owner	Coordinator decides edits and accepts the integrated result

Do not pass the entire conversation by default. Pass the task-relevant constraints, evidence, and authority boundaries. A short brief can still be complete; a long transcript can still omit the critical revision identifier.

The return packet should distinguish observation from recommendation. “The example uses an option absent from the target-version reference” is an observation with a checkable source. “Replace the authentication library” is a recommendation requiring broader evidence. Keeping those separate makes integration less vulnerable to a confident but unsupported leap.

Preserve detailed artifacts outside the conversational summary when appropriate, and return references plus a concise account of what they establish. The coordinator needs access to the evidence, not a secondhand assurance that the worker checked everything.

One owner should control shared state and final effects

A simple default is parallel reads, isolated drafts, and a single promotion point. Workers may inspect independent areas or write into assigned workspaces. The coordinator reviews outputs, resolves conflicts, and applies the accepted result through the normal authority boundary.

This is particularly important for external effects. If two agents independently decide that an overdue invoice needs a reminder, their agreement is not a reason to send two messages. Give the operation a durable identity and a single commitment path. The idempotency requirement for agents applies across workers as well as across retries.

A single coordinator alone does not guarantee exactly-once execution: it can crash after sending a request but before receiving confirmation. Preserve the intent record and reconcile unknown outcomes before retrying. Delegation should not weaken the recovery contract already required for one agent.

Treat worker output as evidence under review, not as authority to expand permissions. A worker encountering a protected operation should return the blocker and relevant facts. It should not grant itself access because completing its brief would otherwise be inconvenient.

Measure coordination cost on the critical path

Parallel work helps elapsed time only when the saved serial work exceeds startup, communication, and integration overhead. The slowest required worker can still determine when the coordinator finishes. More workers can also increase the amount of evidence the coordinator must inspect.

Measure the whole task, including decomposition, retries, waiting, verification, and integration. Compare at least three designs where relevant: one agent with sequential tools, one agent with parallel tools, and a coordinator with workers. Otherwise, an apparent multi-agent benefit may simply be the benefit of concurrent requests.

Keep task inputs, available evidence, and success criteria comparable. Record model configurations and resource budgets so that extra compute is visible. For a quality-under-budget question, hold the total budget fixed; for a product decision, compare each design’s verified quality, latency, and full cost at its intended operating point.

Use cost per completed task rather than cost per worker call. Include coordinator tokens, failed branches, and human recovery. A cheap worker that produces expensive integration work is not a cheap completion.

Multi-agent failure modes belong in the release gate

The following are failure cases to test, not incidents observed in a new experiment:

• Duplicate ownership: two workers receive overlapping write scope. Reject conflicting assignments or require isolated proposals before promotion.
• Missing evidence: a worker returns a polished answer without its required references. Mark it incomplete rather than silently lowering the acceptance bar.
• Stale inputs: one worker evaluates an older revision. Check artifact provenance before combining its findings with current results.
• Late completion: a worker returns after cancellation or after a replacement has been accepted. Record its result without allowing an automatic second commitment.
• Correlated mistakes: two workers repeat the same mistaken premise. Verify against the source or an authoritative checker; agreement alone is not ground truth.
• Partial success: one branch fails while others finish. State which required coverage is missing instead of presenting the combined response as complete.

Turn these cases into agent regression gates appropriate to the workload. Assert the final state and permitted effects, not whether the agents exchanged a particular sequence of messages.

Start with one split you can defend

Choose one independent, read-only branch with clear evidence requirements. Give it a bounded brief and retain its artifacts. Evaluate whether it improves verified completion, useful coverage, or elapsed time enough to justify the full cost.

If integration repeatedly needs the coordinator to redo the investigation, fix the contract or collapse the split. If workers require constant access to each other’s evolving state, reconsider the decomposition. Multi-agent orchestration earns its place through useful separation of work—not through the number of agents in the diagram.