Single-Agent vs Multi-Agent Systems: How to Make th...

The answer often starts falling apart when an interviewer asks, “Why do you need five agents?” Naming a planner, researcher, critic, writer, and reviewer can sound architectural, but a list of roles is not evidence that separate agents improve the system.

The defensible default is one agent with explicit tools, bounded context, and clear state. Split into multiple agents only when specialization, parallelism, or isolation creates measurable value greater than the extra messages, latency, cost, evaluation burden, and failure modes.

Start With One Agent and Explicit Tools

A single-agent design does not mean one giant prompt that owns everything. It means one accountable reasoning loop coordinates a bounded set of tools and state transitions.

Define the task contract first:

the user outcome and success criteria;
allowed data, tools, and side effects;
the context available at each step;
cost, duration, and attempt limits;
approval and stop conditions;
final success and safe-failure states.

Then expose small tools for retrieval, calculation, structured lookup, validation, or action. Keep authorization and business policy outside model-generated text. Record tool results and task state explicitly so a retry does not depend on reconstructing an invisible conversation.

This baseline is easier to test. One task has one owner, one primary state model, and one place to decide what happens next. Failures can still occur, but the investigation does not begin with five independent histories and an uncertain merge.

OpenAI's practical agent guidance discusses tools, instructions, guardrails, and patterns for growing orchestration. The useful interview principle is incremental complexity: maximize the capability of the simpler design before adding coordination layers.

The AI agent engineer interview guide provides the broader role context; this decision framework stays focused on when one accountable loop should become several.

State the reason clearly: “I would start with one agent because the task is sequential and shares one context. I can add tools and deterministic checks without creating a distributed coordination problem.” That is a stronger opening than claiming a multi-agent system is more advanced.

Split Only for Specialization, Parallelism, or Isolation

There are legitimate reasons to divide ownership, but each needs an observable mechanism.

Specialization can help when parts of the task require materially different instructions, tools, context, permissions, or evaluation. A security review and a customer-facing rewrite may need different authority and evidence. The split should reduce interference or improve a measured task result, not merely give each prompt a job title.

Parallelism can help when work is genuinely independent. Separate searches across disjoint sources may run concurrently, then return structured evidence to an orchestrator. If every worker waits for the previous result, the design has multiple agents without a latency advantage.

Isolation can help when one activity should not see another activity's secrets, credentials, tenant data, or untrusted context. Separate workers with narrow tools may reduce blast radius. Isolation is an enforcement property, not a conversational instruction telling agents to stay in their lane.

Microsoft AutoGen documents team patterns in AgentChat. Those patterns show that frameworks can support multiple participants, turn-taking, and coordination. They do not establish that a team is preferable for a particular production task.

Anthropic's engineering article describes a multi-agent system built for research and discusses its trade-offs. Treat it as a research-specific case study. Do not lift its topology into customer support, coding, interviewing, or other products without demonstrating that the same workload characteristics apply.

Before splitting, ask: What information becomes smaller or cleaner? What work becomes parallel? What authority becomes safer? Which metric should improve? If the answer is only “agents can check one another,” strengthen the evaluation and validation path first.

Price Coordination, State, and Failure Complexity

Multi-agent coordination creates a distributed system around probabilistic components. The cost is not only additional model calls.

Messages need schemas, versioning, size limits, provenance, and failure handling. Shared state needs an owner and a conflict rule. Work assignment needs idempotency so a retry does not duplicate external action. Completion needs a definition when some workers succeed and others time out.

Common failure modes include:

two agents act on different versions of the same state;
workers repeat the same expensive search;
a coordinator loses source attribution while merging summaries;
one agent's error becomes trusted context for the next;
retries duplicate work or external side effects;
circular delegation consumes the budget without advancing the task;
a partial result is mistaken for complete consensus;
evaluation scores the polished final answer but misses coordination waste.

Latency can increase even with parallel work. The system may need to create tasks, transfer context, wait for the slowest required worker, resolve conflicts, and run a synthesis step. Cost grows with additional inputs, outputs, retries, and duplicated context. More agents can produce more tokens without producing more useful evidence.

Evaluation also becomes harder. Score the end-to-end task, but keep receipts for each delegation, result, merge decision, and failure. Otherwise a quality change cannot be attributed to specialization, better tools, extra sampling, or simple luck.

Track human review time as well. A topology that needs constant arbitration may shift cost from model calls to operators without improving the user outcome.

The state question is especially important. Decide whether the orchestrator owns authoritative state, whether workers return immutable proposals, and how updates are committed. Avoid several agents writing freely into one mutable memory. The context engineering interview guide provides a useful foundation for separating current intent, durable facts, retrieved support, and temporary working context.

Use NIST AI RMF 1.0 as a voluntary risk-management frame for mapping, measuring, and managing risks. It does not prescribe an agent count or a specific coordination architecture.

Define a Reversible Experiment and Exit Criteria

Turn the architecture debate into a controlled comparison. Select representative tasks that could benefit from the proposed split, including difficult slices and failure cases.

Build the single-agent baseline first. Record the model, prompts, tools, context, limits, and evaluation. Then create the smallest multi-agent variant that tests one hypothesis. For example, split independent retrieval across two constrained workers while keeping one orchestrator and one authoritative state owner.

Compare:

task success and critical failure rate;
evidence completeness and source preservation;
end-to-end completion time and slow-tail behavior;
model, tool, and infrastructure cost per successful task;
duplicated work and unnecessary messages;
coordination, conflict, timeout, and retry failures;
operator effort to diagnose and recover;
security and data-isolation outcomes.

Set exit criteria before the experiment. Keep the multi-agent version only if it produces a meaningful improvement on the target workload without violating cost, latency, safety, or operability limits. If the gain disappears on realistic load or can be achieved with a better tool, deterministic workflow, or cleaner context, return to the simpler design.

Make the change reversible. Keep contracts between the orchestrator and workers narrow. Preserve a single-agent fallback for supported tasks. Version message schemas and avoid embedding product policy inside each role prompt.

The harness engineering core skill guide extends that operating model through explicit tools, guardrails, evaluations, observability, and recovery boundaries.

A concise interview close is: “I start with one accountable agent and explicit tools. I split only for measurable specialization, independent parallel work, or enforced isolation. Then I price the coordination layer: messages, state, retries, synthesis, latency, cost, and partial failure. I compare both designs on the same tasks and keep multiple agents only if the improvement survives those costs.”

That answer demonstrates judgment. It does not argue that one agent is always enough or that more agents are inherently better.