# One agent or many? > Source: > Published: 2026-08-10 07:59:54+00:00 # One agent or many? AI engineers often need to decide whether a task should use one agent or several. A Single-Agent System (SAS) keeps the task state and reasoning history in one context. A Multi-Agent System (MAS) distributes the work across separate agent contexts. This choice depends largely on two properties of the task: **context integration and diversity.** **Context integration** means keeping important information from earlier steps available for later decisions. It matters when each action depends on what has already happened. **Diversity** means exploring different sources, ideas or solutions. It adds value only when agents do different work. Several agents repeating the same analysis add no value. These properties create an architectural trade-off. A SAS makes context integration easier because one agent maintains a continuous view of the task. A MAS can produce greater diversity because separate agents can investigate different parts of the problem at the same time. However, their knowledge must later be communicated and combined. Research suggests several useful patterns, but none is a universal rule. Use them to choose a starting architecture, then compare it with a strong single-agent baseline under the same production constraints. ## The central trade-off: context integration vs. diversity A single agent maintains one continuous reasoning history. This is valuable when later decisions depend heavily on earlier observations. The agent does not need to explain its current understanding to another agent or reconstruct the task state from compressed messages. A multi-agent system distributes reasoning across separate contexts. The agents may explore more sources, test different hypotheses, or verify one another’s work. But no individual agent automatically has access to everything the others know. The system must communicate that knowledge through messages, shared memory, structured artefacts, or a coordinator. This exchange is usually incomplete and consumes part of the available reasoning budget. The practical trade-off can be expressed as: This is a design heuristic, not a predictive equation. Its purpose is to make the architectural assumptions explicit. ## When context integration matters most A single-agent system is usually the stronger starting point when the task involves tightly coupled decisions. Typical indicators include: - Actions must occur in a particular order. - Each observation changes what should happen next. - The environment changes during execution. - The agent must maintain a consistent internal state. - Subtasks cannot be evaluated independently. - One capable agent already performs the task reliably. - Latency or operating cost is tightly constrained. Examples include interactive debugging, sequential planning, transaction workflows, repository-wide implementation, and tasks involving a continuously changing environment. In these situations, distributing the work can create several competing versions of the task state. A single agent can follow this chain directly. With several agents, every state transition may require synchronisation: If most of the work depends on maintaining this shared state, coordination may become more difficult than the original task. ## When diversity matters most A multi-agent system becomes more promising when the task contains independent or complementary work-streams. Useful indicators include: - Subtasks can be completed independently. - Each worker can produce a clearly defined artefact. - Several sources can be investigated in parallel. - Multiple solution paths deserve exploration. - Independent verification is valuable. - Partial outputs can be evaluated before integration. - Greater coverage justifies additional cost or latency. Consider a due-diligence task: These branches share an objective, but much of the underlying work can happen independently. This lets each agent contribute different evidence. **The key question is whether the work decomposes naturally.** Giving agents titles such as “planner,” “reasoner,” and “reviewer” does not necessarily make the work decomposable. If every role needs the complete reasoning history, the design may simply distribute one thought process across several context windows. A good decomposition gives each agent a defined output that can be evaluated on its own. ## A task-structure decision map A first-pass architecture decision can be made using two questions: - How tightly coupled are the task’s decisions? - How much value could independent exploration provide? This map identifies a sensible starting point. It does not replace evaluation. ## Choosing a MAS coordination pattern If the task appears to justify multiple agents, the next question is how they should interact. ### Independent workers Each agent completes a separate assignment, and the outputs are combined at the end. This works well for independent discovery. It offers parallelism but little error correction unless the aggregator actively validates the outputs. ### Centralised coordination A coordinator assigns work, evaluates contributions, and owns the final result. Use this when partial results must be reconciled or verified. The coordinator should be able to reject unsupported findings, resolve contradictions, and request additional work. ### Decentralised coordination Agents exchange findings and challenge one another directly. This can be useful when several interpretations should be explored. It can also become repetitive if discussion is not bounded by clear stopping conditions. ### Hybrid coordination A coordinator manages agents that also communicate with one another. This is the most flexible pattern, but typically the most communication-heavy. It should be considered only when simpler topologies have failed in identifiable ways. ## Evaluate the choice as an engineering experiment The architecture should be selected through controlled comparison rather than intuition alone. This does not “scientifically validate” SAS or MAS in general. It provides evidence about which implementation works better within the conditions tested. ### Define the production objective Decide what matters before running the comparison: - task success; - factual accuracy; - reliability; - latency; - token consumption; - financial cost; - tool-call efficiency; - or human review effort. Specify the minimum improvement required to justify additional complexity. ### Establish a strong SAS baseline Give one agent appropriate instructions, context, tools, and stopping conditions. A weak SAS compared with a carefully engineered MAS is not a useful architectural comparison. The baseline should represent a credible production implementation. ### State the MAS hypothesis Describe the mechanism through which multiple agents are expected to help. For example: Three research agents should improve evidence coverage because the task contains independent source categories that cannot all be investigated deeply within the latency limit. A claim such as “more agents may reason better” is too vague to evaluate. ### Control the comparison Keep relevant factors consistent: - model capability; - task instructions; - tool access; - evaluation tasks; - output requirements; - stopping conditions; - and resource limits. Two comparisons may be useful: These answer different production questions and should not be conflated. ### Measure both outcomes and coordination Final quality is essential, but it does not explain the result. For a MAS, also measure: - coordination tokens; - message count; - duplicated investigation; - repeated tool calls; - disagreement frequency; - stale-state failures; - errors caught during verification; - synthesis time; - and the contribution of each worker. Use these metrics to check whether inter-agent communication improves the result. ### Inspect traces Review successful and failed runs for recurring mechanisms: - Did agents operate from inconsistent task states? - Did the decomposition create independent work? - Did the coordinator catch errors? - Did workers repeat the same investigation? - Did messages omit important context? - Did peer discussion introduce useful alternatives? - Did communication displace actual task work? Trace review helps explain why performance changed. ### Report uncertainty Agent evaluations are often noisy. Run a representative set of tasks, repeat non-deterministic trials where practical, and examine the variability of the results. A small average improvement may not be meaningful if it disappears across task categories or repeated runs. State the conclusion narrowly: Under these models, tools, tasks, budgets, and evaluation criteria, this architecture performed better. ## A practical starting guide | Task characteristic | Suggested starting point | |---|---| | Sequential, stateful execution | SAS | | Strong SAS performance | SAS | | Independent research branches | Independent workers | | Partial results requiring validation | Centralized MAS | | Several plausible approaches | Decentralized MAS | | High cost of factual errors | Workers with explicit verification | | Many interdependent tools | SAS | | Strict latency requirement | SAS or limited parallel workers | | Need for hierarchy and peer exchange | Test a hybrid carefully | These are research-informed hypotheses, not universal rules. ## The engineering principle Choose the architecture that matches the task. Use SAS when the work is sequential and stateful. Test MAS when the work splits into independent branches or benefits from separate verification. The architectural decision should therefore follow the natural structure of the task: Start with a strong baseline, control the comparison, measure coordination cost, and inspect failures. Keep MAS only if it produces a material improvement under the constraints that matter in production. No spam, no sharing to third party. Only you and me.