Single-agent vs multi-agent systems: when to split the work

Use multiple agents when a task can be divided into genuinely independent responsibilities with clear handoffs. Start with one agent when the work shares the same context and decisions. More agents add coordination, cost and opportunities for conflicting state; they do not automatically improve the outcome.

Look for a real boundary

Imagine preparing a market brief. Independent research on three separate markets may be parallelizable. Writing three competing versions of the same customer record is not. The first task can combine separate findings; the second risks inconsistent updates to one source of truth.

A division by role also needs a reason. A reviewer is useful when it applies independent criteria and checks evidence. Merely asking another agent whether the first answer looks good may reproduce the same assumptions.

Define the handoff before the agents

• Input: the bounded question each agent receives.
• Authority: tools and records it may access or change.
• Output: the format and evidence the next step requires.
• Ownership: the component allowed to write shared state.
• Failure: what the coordinator does when one part is unavailable.

Keep one accountable owner for the final result. Delegating a section does not transfer responsibility for checking whether the combined output answers the original request.

Compare against a single-agent baseline

Run the same representative task both ways. Measure accepted results, total cost, time to completion and human correction. Count coordination work, including resolving inconsistent terminology or duplicate findings. Faster individual subtasks may still produce a slower overall workflow.

If a multi-agent design wins only on carefully selected examples, keep testing ordinary cases and failures. The architecture should match the distribution of work your team actually sees.

A useful starting constraint

Allow parallel reading and analysis before parallel writing. Require a shared artifact format and a single final merge step. This gives the team a way to learn whether specialization helps without immediately creating several actors that can make competing external changes.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.