Single Agent or Multiple Agents? Start with the Coordination Cost

Overview: what you are actually comparing

A single-agent design gives one agent responsibility for interpreting a request, choosing tools, and producing a result. It may still call databases, APIs, search services, or ordinary application code. “Single” describes the agentic decision-maker, not a ban on software components.

A multi-agent design assigns agentic responsibilities to two or more agents and adds a coordination mechanism: one agent delegates to others, agents exchange messages, or an application routes work among them. The extra agents may have separate instructions, tools, context, or model calls. They also require an explicit way to pass work and combine results.

The decision is not whether a complicated job can be divided. Almost any job can be described as subtasks. The decision is whether separate agent boundaries improve the work enough to justify the additional handoffs, duplicated context, failure handling, observability, and operational ownership. Task decomposition is useful only when the coordination it creates costs less than the complexity it removes.

This comparison is for teams deciding how to move from a prototype to a production workflow. It does not treat human approvals, tool-contract testing, or the choice of a particular framework as substitutes for the architecture decision. Those are related engineering topics: see Human Approval in an AI Harness: Pause, Review and Resume Safely for the approval boundary, and Tool Changes Can Break Agents: Add Contract Tests to CI for compatibility testing.

Start with a job’s inputs, outputs, side effects, and failure consequences. Then compare a single agent against the smallest plausible multi-agent design. If a deterministic function, queue, or ordinary service can perform a step more predictably, that step does not need to become an agent merely to make the diagram look distributed.

The comparison at a glance

The table is a starting point, not a scorecard. A single agent can call multiple tools in parallel through application code; multiple agents do not automatically run concurrently. Likewise, a multi-agent system can have one coordinator and several narrowly scoped workers, or a more decentralized communication pattern. The number of agents alone tells you little about the quality of the design.

A practical way to estimate coordination burden is to count the information transfers that matter, not just the agents. If three workers each report to one coordinator, that creates three worker-to-coordinator result handoffs, plus any dispatches, retries, and shared-state reads. If workers also exchange messages with one another, the number of possible paths grows quickly. Each path needs a defined payload, an owner for decisions, and a response to failure.

Control flow and task decomposition

Single-agent control

In a single-agent workflow, one decision-maker handles the evolving task. It can inspect the request, choose a tool, interpret a result, and decide whether to continue. This keeps responsibility easy to explain: the agent owns the plan, while the application owns the tools and the limits placed around them.

That simplicity has a cost. As responsibilities accumulate, the agent may receive instructions about many domains, access many tools, and need to keep more facts in context. The resulting system can be difficult to evaluate because a change intended for one type of request may affect another. The first remedy should usually be narrower instructions, clearer tool contracts, deterministic routing for known cases, or conventional code—not immediately another autonomous decision-maker.

A single agent is particularly suitable when each step depends on the result of the previous one. For example, a support workflow may need to identify an order, inspect its status, interpret a return policy, and draft a response. If the later decisions depend on the earlier findings, one agent can maintain the thread without repeatedly packaging and reconstructing context.

Multi-agent decomposition

Multiple agents become more attractive when the job contains parts that are meaningfully independent, require distinct context or tools, or need separate evaluation. A coordinator can assign those parts and collect structured results. Separation can also make ownership clearer: a catalog researcher returns candidate facts, while a policy reviewer checks a defined set of rules.

The work must actually be separable. If Worker B cannot make progress until Worker A has resolved an ambiguity, running both as agents in parallel creates idle calls rather than useful concurrency. If both agents need the same evolving facts, the design must decide which version is authoritative and what happens when their assumptions diverge.

A role label does not itself create specialization. Two agents given nearly identical context, tools, and instructions may produce overlapping answers, contradict one another, or repeat the same work. To justify a boundary, specify what one agent can decide, what it must return, and what the next component is allowed to do with that result.

The anatomy of an AI agent is useful background for separating the model’s decisions from tools, state, and surrounding application logic. That distinction matters here: introducing another agent changes a decision boundary, while moving a deterministic operation into ordinary code may reduce uncertainty without adding another agent handoff.

Context, state, and information transfer

One working context versus scoped contexts

A single agent can reason over a unified view of the task, but that view can become crowded. Irrelevant data makes it harder to identify the facts that should control a particular decision. Context selection is still necessary: a coherent agent does not benefit from receiving every record, tool output, and previous message indiscriminately.

Multiple agents offer the possibility of narrower working contexts. A pricing analyst could receive product and pricing data while a fulfillment analyst receives inventory and shipping data. This separation is useful only if the agents’ results are compact, relevant, and consistent with the coordinator’s needs. Narrow context also means a worker may miss a fact that another worker knows, so the handoff has to preserve necessary dependencies.

Treat the result passed between agents as an interface, not a transcript. A useful handoff identifies the question answered, the relevant entity, the source or record identifier, the conclusion, uncertainty, and any unresolved dependency. Passing a long conversation encourages the receiver to infer which parts matter and can carry forward stale assumptions.

For example, a result about a product should distinguish “no matching product found” from “search failed,” and distinguish “price observed” from “price authorized for an order.” Those are different states. If the coordinator collapses them into a generic text answer, it can turn missing evidence into a confident-looking decision.

State ownership and freshness

Shared state is not automatically shared understanding. If two agents read a customer record and one updates it, the other may continue working with an earlier view. A multi-agent design therefore needs to say whether a worker’s output is a snapshot, whether it can be superseded, and how the coordinator handles conflicting versions.

Prefer a clear owner for mutable business state. Agents can propose a change or return a recommendation, while application code checks the current record and applies permitted updates. This keeps the decision to change state separate from the question of whether the state still satisfies the relevant conditions.

For a bounded workflow, a single agent may be easier to reason about because the task’s facts remain in one working thread. That does not remove the need to read current data before an important action, but it avoids synchronizing multiple agent memories. Choose multiple contexts for a real isolation or specialization benefit, not on the assumption that separate prompts create reliable state boundaries by themselves.

Handoffs, latency, and failure behavior

A handoff has several stages: work is assigned, the receiver gets enough context, it produces a result, and the coordinator decides whether that result is usable. Any stage can fail. The message may be incomplete, the worker may time out, the result may not satisfy the expected structure, or the coordinator may combine incompatible conclusions.

Sequential delegation can increase elapsed time because a later agent may wait for an earlier one. Parallel work can reduce waiting when subtasks are independent, but parallelism does not remove the final merge. The coordinator still has to determine whether every required answer arrived, whether results conflict, and whether a failed worker can be retried safely.

A retry is not always harmless. A read-only lookup can often be repeated. A tool call that changes an order, sends a message, or creates a record may have an external effect even when the caller times out before receiving confirmation. Do not assume that a retry is safe or that a distributed workflow can guarantee exactly-once external effects. Use operation identifiers, idempotent application behavior where available, and a way to inspect whether an action already happened.

A useful failure policy distinguishes at least four outcomes: success, a valid negative result, a recoverable technical failure, and an ambiguous result. A valid negative result may let the workflow continue. A technical failure may be retried within a limit. An ambiguous result should not be silently treated as success. The coordinator should stop, fall back to a safer path, or return the task for human handling according to the consequence of being wrong.

The adjacent flowchart captures a deliberately small design choice. It does not assume that every independent task deserves a new agent: first check whether a conventional function is sufficient, then check whether separate work is both useful and independently verifiable. A failed or conflicting handoff reaches a bounded fallback rather than being accepted as a completed result.

flowchart TD
accTitle: Choosing an agent boundary and handling a failed handoff
accDescr: A request is assessed for independent subtasks. A deterministic task stays in one agent workflow. Independent work may be delegated, but invalid or conflicting results go to a bounded fallback before any result is accepted.
    A["Request arrives"] --> B["Check task boundaries"]
    B --> C["Use one agent or function"]
    B --> D["Delegate independent work"]
    D --> E["Validate returned results"]
    E --> F["Accept consistent result"]
    E --> G["Bounded fallback"]

The diagram’s “bounded fallback” must be a real behavior, not a label in an architecture document. It might mean one retry for a read-only lookup, asking the coordinator to reformulate a malformed request, or stopping and returning a clear failure status. Which response is appropriate depends on the task and on whether any side effect could already have occurred.

Observability and the cost of operating more agents

A single-agent trace is comparatively direct: record the request identifier, agent version, relevant inputs, tool calls, tool results, and final disposition. Avoid treating private reasoning text as the only explanation of what happened. Operational records should let an engineer answer what the system attempted, what external actions occurred, and where execution stopped.

A multi-agent trace needs to preserve parent-child relationships. Give the overall workflow a correlation identifier and associate every dispatch, worker result, retry, and merge decision with it. Record the worker’s role, input version or relevant record identifiers, outcome status, and elapsed time. Without those links, an operator may see several isolated successful calls without being able to tell that the overall task failed to combine them correctly.

Observability also changes the investigation. With one agent, a wrong result may originate in its instruction, a tool response, or the application’s input selection. With several, the defect may be in any of those places plus task decomposition, message serialization, stale context, worker selection, merge logic, or retry policy. The system may fail even when each worker appears locally successful.

More components also mean more changes to coordinate. A field added to a worker’s output can break a coordinator that expects the old shape. A change to a task definition can leave one worker unaware of a required fact. Treat these boundaries as software interfaces: version the payload where practical, validate before use, and test representative success and failure paths.

A useful operational measure is not “agent success rate” in isolation. Track whether the complete workflow reached the intended business state, how often it needed fallback, how many handoffs failed validation, and whether an external action was confirmed. A model-generated answer can look complete while the intended record remains unchanged; verify the business result separately from the model’s claim that it completed the task.

Pros and cons by option

Single agent: advantages and limits

Pros: A single agent has fewer agent-to-agent interfaces and fewer opportunities for conflicting decisions. Its sequence is usually easier to trace, and a change can often be tested without coordinating a set of worker roles. Context can remain coherent across dependent steps, and the system avoids the additional dispatch, result validation, and merge logic of a multi-agent design.

It is also easier to begin with a restricted tool set. If the agent can draft but not send, or retrieve data but not update it, the application can enforce that boundary without deciding which of several agents owns the action. This is a useful starting point when the team still needs to learn which task variations occur in real traffic.

Cons: One agent can accumulate too many responsibilities. It may have a broad instruction set, an unwieldy tool menu, or difficulty distinguishing which information is relevant. A single control loop may also underuse available parallelism when a workflow contains independent read tasks.

The apparent simplicity can hide a tangled prompt-and-tool design. If every new request type adds another special case, debugging and regression testing become harder even though there is only one agent. At that point, narrowing the workflow, separating deterministic routing, or splitting a well-defined specialty may be warranted—but the agent count should follow the design problem, not serve as the diagnosis.

Multiple agents: advantages and limits

Pros: Multiple agents can isolate genuinely different responsibilities, keep some contexts narrower, and allow independent work to proceed concurrently. A worker can return a focused result that the coordinator validates, rather than giving one agent every tool and all available information. Distinct tasks can also be evaluated at their own boundaries.

This can help when different parts of a task have different data requirements or when one component should never be responsible for another component’s decision. For instance, a research worker can identify candidate records while a separate deterministic rule checks whether the selected record is eligible for an action. The separation is valuable only if the handoff makes the distinction enforceable.

Cons: The design adds coordination code and failure cases. Results can be incomplete, stale, malformed, duplicated, or contradictory. More calls can mean more latency and operating expense, although the actual trade depends on the work, model, and execution design; agent count alone does not determine either.

Parallel agents may produce a wider set of answers without producing a better answer. The coordinator has to reconcile them, and a consensus-like merge can conceal disagreement rather than resolve it. Multiple agents also expand the test surface: teams need to test boundaries and end-to-end behavior, not just each worker in isolation.

Worked scenario: reviewing a supplier change

Consider a hypothetical mid-market distributor that wants to review proposed supplier changes before an operations employee updates a purchasing record. A request may include a supplier name, a product identifier, a proposed lead time, and an explanation from an account manager. The desired output is a recommendation with supporting record references; the workflow does not place an order or change the purchasing system.

A single-agent version receives the request, looks up the supplier and product, compares the proposal with the stored purchasing information, and drafts a recommendation. The application exposes read-only lookups and saves the draft for an employee to review. The agent must identify missing matches rather than infer them from similar names. For an early version, this is attractive because the task’s steps depend on a shared product-and-supplier identity.

The pressure to add workers appears when operations asks for three checks: compare supplier terms, inspect recent delivery exceptions, and summarize the account manager’s explanation. Those checks could be delegated if they can each use a stable identifier and return a structured finding. They are not independent if a delivery exception must first be matched to the correct supplier-product pair, or if the terms review changes which historical records are relevant.

A minimal multi-agent proposal therefore begins with data flow, not role names. The coordinator resolves the supplier and product identifiers, then sends those identifiers and the same request snapshot to the relevant workers. Each worker returns a finding and references. The coordinator checks required fields, rejects results for mismatched identifiers, flags disagreement, and builds a draft recommendation. It does not convert an absent result into “no issue found.”

For an illustrative calculation, assume the three checks take 2, 3, and 2 seconds when performed one after another, and each takes 0.5 seconds to package and validate at a handoff. A simple sequential multi-agent design would take roughly 8.5 seconds before final synthesis: 7 seconds of checking plus 1.5 seconds of handoff work. If the checks truly run in parallel, an illustrative lower bound is about 3.5 seconds: the slowest 3-second check plus 1.5 seconds for dispatch, validation, and synthesis. These assumed figures are not a benchmark; real systems also have variable model and service response times.

The comparison changes if those checks can be performed as ordinary database queries and deterministic rules. The application could run the independent reads concurrently, then give one agent the compact findings to interpret. That design may retain the latency benefit without three worker agents. It is a meaningful counterexample to “independent tasks imply multiple agents”: concurrency is an execution property, not proof that each task needs an autonomous agent.

Acceptance criteria should distinguish process quality from business outcome. A useful first release could require the workflow to identify all required record references, label missing or failed checks distinctly, surface conflicting findings, and produce no system update. Review a sample of representative requests against those criteria before expanding access or adding autonomy. The recommendation is a draft, not evidence that a purchasing decision is correct.

Failure analysis: when delegation makes the answer worse

Imagine the supplier lookup returns two similar records. The coordinator sends the first record identifier to the terms worker and the second to the delivery-history worker because the matching step was not centralized. Each worker returns a plausible, internally consistent result. The coordinator combines them into a polished recommendation that refers to no real supplier-product combination.

This is not a model-quality problem in isolation. It is a decomposition and identity-binding failure. The system allowed workers to operate on different entities and gave the coordinator no validation rule to catch the mismatch. The repair is to resolve and bind identifiers before delegation, include them in every result, and reject a result whose identifiers do not match the parent task.

Now consider a worker timing out after a request to an external system may have been accepted. The coordinator retries, receives a second response, and treats it as a new result. For this scenario the workers are read-only, so duplicate lookups are tolerable, but that assumption must be explicit. If a later version adds an update action, the same retry policy could create duplicate effects or leave the result uncertain.

A further failure occurs when one worker returns a valid negative finding while another fails technically. If the coordinator interprets both as “no exception,” the final draft hides an unresolved check. Model the status separately from the finding: a successful check can report “no matching exception”; a failed check reports that it did not complete. Missing is not negative.

The recovery path should preserve enough information to resume or investigate without pretending the job succeeded. Record the parent task, the specific worker result status, the identifiers used, and whether any external action was attempted. If the workflow cannot establish a reliable answer, leave the purchasing record unchanged and route the draft or failure state to the existing operational process. Detailed human-approval design belongs to the linked treatment above; this article’s point is that agent coordination must make the uncertain state visible.

A practical decision artifact

Use this worksheet during design review. Score each item from 0 to 2: 0 means the statement is not true or not demonstrated; 1 means partly true or supported by an assumption; 2 means true and backed by a concrete task example. The scores structure discussion; they are not a validated benchmark or an automatic architecture selector.

Interpret the discussion rather than mechanically adding the scores. Several strong answers on independent work and validation support a small multi-agent trial. Weak answers on stable inputs, result checking, or recovery point toward keeping the workflow single-agent or using ordinary application code first. If every answer depends on an assumption, run a constrained prototype that tests that assumption before designing a larger system.

Write down the decision in one paragraph: “We will use [design] for [workflow boundary] because [specific task structure]. We will not delegate [step] because [dependency or simpler implementation]. If [failure condition] occurs, the workflow will [bounded response]. We will reconsider when [observable condition] changes.” This makes the tradeoff reviewable when the workflow or tools evolve.

For a first multi-agent trial, keep the number of roles small, use a fixed input snapshot, require a structured result, and make the coordinator responsible for validation. Compare it with a single-agent baseline using the same representative requests and acceptance criteria. Record end-to-end correctness, incomplete handoffs, recovery behavior, elapsed time, and operational effort. Do not declare a winner from a handful of impressive examples or from model confidence alone.

Implementation implications and verdict by use case

Framework terminology can obscure the architecture choice. An SDK is not the same thing as an orchestration design, and neither by itself decides where the system is hosted. The Strands repository provides SDKs and an assembled harness; teams should identify which component they use and separately specify hosting. The Deep Agents overview describes a harness that combines context and tool execution, with planning optional. These are implementation distinctions, not evidence that one agent count is inherently better.

A single-agent design is the better initial choice when one coherent decision path owns the task, later steps depend heavily on earlier findings, and the team has not yet demonstrated an advantage from specialization. Keep the tool surface bounded, make inputs explicit, and use normal code for deterministic validation or side effects. If the agent is becoming overloaded, first identify which responsibility actually causes errors or makes evaluation difficult.

Choose a small multi-agent design when distinct subtasks can use stable, shareable inputs, produce independently checkable results, and benefit from different contexts or responsibilities. Start with a coordinator and only the workers justified by those properties. Require the coordinator to validate identifiers, status, and required fields before it merges results; define timeout and conflict behavior before increasing parallelism.

Prefer ordinary functions, queries, or existing services when the work is deterministic and does not benefit from agent judgment. A mixed design is often the most useful comparison: one agent interprets the request, application code performs predictable retrieval and validation, and a second agent is introduced only if a clearly distinct reasoning task warrants it. “Single versus multiple” does not require every stage to have the same implementation style.

Do not choose a swarm or broad peer-to-peer arrangement just because the task has several domains. Unless agents need to coordinate dynamically, decentralized messages add more possible execution paths than this decision usually requires. A simple, explicit coordinator is easier to audit and recover when the work can be represented as a bounded sequence or a small set of independent tasks.

The implementation decision should be revisited when evidence from actual workflow cases changes: the single agent repeatedly confuses distinct responsibilities; an independent task is a measurable source of waiting; context boundaries improve evaluation; or handoff and recovery costs outweigh the benefit of separation. At that point, test the smallest design that addresses the observed problem. Teams looking for help translating this comparison into a scoped implementation can explore AI agent engineering.

The practical verdict is simple: begin with one agent or conventional code, then add agents only for a demonstrated boundary. Multiple agents are justified by separable work, useful specialization, and verifiable handoffs—not by complexity alone. The architecture succeeds when the complete workflow produces a reliable, inspectable result and behaves safely when coordination does not.

WANT TO TALK THROUGH YOUR SITUATION?

Talk it through with us. Thirty minutes, no slides.