Use multi-agent architecture when a valuable job divides into independent workstreams, specialist agents produce a measurable advantage, or separate access boundaries prevent one agent from holding every tool and source. Keep one agent when the work shares heavy context, follows tight dependencies or fits inside one coherent toolset.

Better accepted outcomes or materially shorter elapsed time must pay for extra model calls, context handoffs, evaluation and recovery. When they do not, the architecture diagram has created operating overhead.

Anthropic’s research system puts a number on the trade

Anthropic’s production teardown of its multi-agent research system gives unusually clear numbers. In an internal evaluation, a lead Claude Opus 4 agent working with Claude Sonnet 4 subagents outperformed a single Claude Opus 4 agent by 90.2% on breadth-first research tasks.

That gain carried a large resource bill. Anthropic reports that agents used about four times the tokens of chat interactions, while multi-agent systems used about 15 times as many. Its analysis found token usage alone explained 80% of performance variance on BrowseComp, with tool calls and model choice accounting for the remaining factors in a model that explained 95% of variance.

Research can split into independent searches, giving each subagent a clean context window and a distinct direction. The lead agent then compresses those findings into one result. More inference buys broader exploration because the task has enough independent surface area to use it; the 90.2% uplift came from that fit between architecture and task shape.

A tightly coupled workflow receives less value from that spend. When every step depends on the full output of the last, extra agents inherit the same context, wait on one another and introduce more handoffs. Anthropic specifically notes that work with many dependencies or shared context is a weaker fit.

Start with one agent and locate the actual constraint

Microsoft’s AI agent orchestration patterns place architecture on a complexity spectrum: direct model call, single agent with tools, then multi-agent orchestration. The guidance describes a single tool-using agent as the enterprise default for many use cases because it remains easier to test and debug.

A second agent earns a role by removing a named constraint. Four conditions provide a defensible case:

  1. Parallel search space. Several lines of investigation can run without reading one another’s intermediate work.
  2. Specialist advantage. A bounded task needs its own instructions, model, tools or evaluation rubric to outperform the general agent.
  3. Knowledge separation. Different domains have distinct source sets, owners or freshness rules.
  4. Security separation. One workflow crosses access boundaries that should not sit inside a single identity and tool envelope.

Modularity alone supplies weak justification because every module creates a contract to maintain. If one prompt, source set and permission boundary can handle the task reliably, splitting it raises cost before it raises capability.

This extends the Model Operator test for AI agents versus workflow automation. First decide whether the job needs agent judgement. Then decide whether that judgement belongs in one agent or several.

Match the orchestration pattern to the dependency shape

OpenAI’s Agents SDK orchestration guide separates manager-style orchestration from handoffs. A manager calls specialist agents as tools and retains ownership of the final response. A handoff transfers the active conversation to a specialist.

Manager orchestration fits research, analysis and assembly work where one accountable agent must reconcile several contributions. The manager can reject a weak result, request another pass and keep the output format stable.

Handoffs fit routing problems where the selected specialist should own the remaining interaction. Customer support triage is a clear example: once the system identifies a refund request, the refund specialist can continue with focused instructions and the relevant tools.

Code should control predictable coordination. OpenAI recommends code orchestration for deterministic chains, structured routing and parallel tasks that do not depend on one another. Letting a model decide every transition adds variable latency and cost to choices the system already knows how to make.

The dependency shape gives a practical selection rule:

Work shapeArchitectureReason
One domain, shared context, varied tool useSingle agent with toolsKeeps reasoning and state in one place
Independent research or analysis lanesConcurrent specialists under a managerBuys breadth and reduces elapsed time
Fixed stages with clear dependenciesCode-orchestrated sequencePreserves predictable routing and checkpoints
Intent routes to one domain ownerHandoffGives the specialist focused control of the interaction
Separate privileges or knowledge ownersConnected specialist agentsEnforces a boundary the parent should not absorb

Write a contract for every delegated task

Anthropic found that vague delegation caused subagents to duplicate searches, pursue the wrong period and leave gaps. Its response was operational: every task needed an objective, output format, source guidance and clear boundary.

A usable delegation contract contains six fields:

  • the question the specialist owns
  • the evidence or source boundary it can use
  • work explicitly assigned elsewhere
  • the required output schema
  • the condition that marks the task complete
  • the failure or uncertainty the orchestrator must see

The exclusion field carries real economic weight. Two agents searching the same material can return polished duplication that looks like corroboration. Distinct lanes reduce wasted calls and make coverage visible before synthesis begins.

Microsoft’s current Copilot Studio multi-agent guidance recommends separate agents when a subtask has its own complex toolset or knowledge, needs different access controls, or will be reused across parent agents. It also advises giving connected agents distinct descriptions and non-overlapping knowledge sources. Those rules turn routing from guesswork into a testable contract.

Keep one owner for the accepted outcome

Several agents can contribute without sharing authority over completion. The parent should own the final answer, target-system state or reviewer packet.

That ownership resolves three predictable failure modes:

  • Partial results: the parent can identify a missing lane before presenting an answer as complete.
  • Conflicting findings: one rubric determines source precedence and whether the conflict requires escalation.
  • Duplicate communication: specialists return evidence to the orchestrator rather than producing competing user-facing responses.

For workflows that change persistent state, evaluate the end state as well as each agent’s transcript. Anthropic recommends end-state evaluation for agents that mutate an environment over many turns, with checkpoints for required state changes. A subagent can report success while the repository, CRM or booking system remains unchanged.

The same discipline belongs in pilot design. Define accepted outcomes and stop conditions before broadening the orchestration graph; the AI agent pilot success criteria guide provides a full scorecard.

Price the coordination tax per accepted outcome

Token usage reveals part of the cost. A production comparison should also include tool calls, elapsed time, orchestration failures, duplicated work, evaluator calls, human synthesis and recovery after one branch fails.

Measure the multi-agent version against a single-agent baseline on the same representative cases:

MeasureWhat it exposes
Accepted outcome rateWhether specialisation improves usable quality
End-to-end elapsed timeWhether parallelism creates a genuine speed gain
Total model and tool costThe resource premium paid for decomposition
Duplicate or missing coverageThe quality of task boundaries and routing
Active review timeLabour retained in synthesis and correction
Recovery costThe consequence of partial or contradictory results

Segment the results by task shape. A system can justify multiple agents for broad market research while losing badly on a short, context-heavy account review. One average obscures the boundary that architecture decisions need.

The denominator should remain cost per accepted outcome. The Model Operator agent unit economics guide explains how to join execution spend, review and recovery to the verified business result.

Use a four-gate decision before adding another agent

Approve the split only when all four gates have a concrete answer:

  1. Independence: Which work can proceed without shared intermediate state?
  2. Advantage: What measurable quality, speed or access benefit does the specialist add?
  3. Contract: Which inputs, tools, exclusions and output schema control the handoff?
  4. Economics: Which accepted outcome pays for the added inference and coordination?

A failed gate points to a simpler design. The task can stay inside the parent agent, become a deterministic function, or wait until a real permission or knowledge boundary appears.

Model Operator maps these boundaries before teams expand an agent estate: workflow decomposition, authorised sources, specialist access, acceptance evidence and full operating cost. For a hands-on architecture review through AI Initiative Consulting, or an Agentic Company Brain where source and permission boundaries drive the design, start a conversation or email alexander@modeloperator.io.