Single agent vs. multi-agent systems

Three reasons to split the work

Multiple agents can be useful when subtasks are independent, when different tasks need materially different context or tools, or when responsibility must be separated. Microsoft’s guidance distinguishes single-agent and multi-agent choices and discusses the additional orchestration involved. The choice should follow the workload rather than a preferred framework.[1]

A second agent does not automatically create an independent opinion. Two agents using the same model, context and instructions may share the same blind spots. If the purpose is verification, define what evidence or method makes the check meaningfully different. A deterministic validator or human review may be a better second component.

Worked scenario: investigate an account exception

A synthetic account-review task needs billing facts and service-incident facts. These reads can run independently. One bounded worker queries authorized billing records; another queries the permitted incident history. Each returns a typed evidence package with record IDs, timestamps, findings and unresolved conditions.

A coordinator joins the packages and produces a recommendation. It does not accept unsupported prose as established fact: source references must resolve, the records must be in scope and conflicting dates remain visible. The final domain service owns any account change. Parallel investigation does not mean parallel writers racing to fix the same record.

task_id
subtask_id
source_ids[]
source_versions[]
findings[]
unresolved_conditions[]
status: completed | incomplete | failed

If one worker fails, the coordinator follows a predefined rule: wait within the task budget, continue with an explicitly partial answer if that is acceptable, or stop. It should not invent the missing result because the other worker returned a persuasive explanation.

Count coordination in the outcome

The relevant comparison includes orchestration, model calls, evidence merging, duplicate retrieval, review and rework. A lower model cost per worker can still produce a higher cost per accepted task. Latency improves only when enough work is independent; serial delegation can make the critical path longer.

Evaluate a single-agent baseline, a deterministic parallel workflow and the proposed multi-agent design. The middle option is often overlooked: independent searches do not necessarily need autonomous workers to execute them.

Make the coordination contract explicit

Useful orchestration patterns include sequential stages, concurrent work and handoffs, but each has a different failure contract. Microsoft’s pattern guidance is a catalog of options, not a requirement to combine them all.[2]

• Define the task and subtask identities separately. A retry should refer to the same intended work.
• Specify the evidence schema and the conditions under which a result is incomplete.
• Set a total budget as well as per-worker limits; many bounded workers can still exceed the product budget.
• Name the owner of the final answer and the owner of each business mutation.
• Define cancellation and late-result behavior. A timed-out worker must not commit after the parent task has been rejected.

Treat a worker’s output as input to validate. That applies even when the worker is described as a specialist or reviewer. Titles in a prompt do not establish expertise, independence or authority.

Keep permission boundaries real

If decomposition is intended to isolate access, enforce that separation in credentials and application policy. A read-only worker should not receive mutation tools. A worker scoped to one tenant should not use a shared memory store that exposes another tenant’s context. The coordinator must preserve those boundaries when it joins results.

For consequential writes, a single operation owner simplifies concurrency and recovery. It can check the current resource version, apply policy and record the outcome. Multiple agents can contribute evidence without being allowed to commit competing versions of the same action.

When the simpler design wins

Prefer the simpler design when the work is mostly serial, handoffs lose context, or the added workers do not improve measured outcomes. A multi-agent system is justified when its benefits survive the complete task evaluation and the operating team can explain its failure paths. Preserve that evidence with the architecture decision so the design can be simplified later if the workload changes.