Single-agent vs multi-agent: when splitting the work helps
Compare one agent with several using the same task. See when separate investigations help, when dependencies get in the way, and what to measure.
Use one agent when the work depends on a shared, changing understanding of the task. Consider several when each can investigate a well-defined part with its own information or permissions. Splitting work adds handovers and coordination; it does not automatically add independent judgement.
Three agents can separately check three libraries' upgrade notes, then return their findings. If all three instead change the same API, each change can invalidate the others. More workers help only when their work can be separated and combined usefully.
A planner, a researcher and a reviewer sound like a complete team. The useful question is what each worker can finish without waiting for the others to change their minds. Start with that boundary before adding roles.
Count separate work, not job titles#
One agent can make many model calls and use many tools. That does not make every call or tool a separate agent. Here, multiple agents means separately managed workers that can pursue their assigned tasks, with their own working context and action loops.
The workers can use the same model. They can also run one after another. The design question is whether separating their work makes the result easier to produce and check, not whether the diagram contains several model logos.
Chapter 1 of Michael Albada’s book introduces multi-agent systems as collaboration on distributed tasks, while acknowledging extra development and maintenance complexity. The examples below turn that trade-off into a specific choice. They do not assume that every listed industry needs an agent team.
Compare the same investigation#
In this illustrative task, a developer needs a compatibility report before upgrading three unrelated command-line libraries. The input names each library, its installed version, the proposed version and the commands the application uses. The output is a report, not permission to edit the application.
With one agent, the worker reads each library’s release notes, follows relevant references and records breaking changes. It keeps the whole question in one working context. There is no need to transfer partial findings between workers, although a long investigation may accumulate distracting material.
With several agents, each worker investigates one library. A coordinator supplies the same version rules and required output: affected commands, supporting source locations, checked versions and unresolved questions. The coordinator then combines and checks the reports.
Both designs must answer the same compatibility question. Do not give the multi-agent version newer documentation, a larger allowed task scope and more retries, then attribute the result entirely to the number of agents.
The split has two possible benefits to test. Separate working contexts can keep each investigation focused. Independent investigations can overlap in time if capacity is available. Neither benefit removes the final work of reconciling findings, checking omissions and producing a usable report.
A worker should return “No breaking change found in these release notes”, not “The upgrade is safe” when it has not exercised the application’s commands. Handing over findings with their supporting records makes that boundary visible.
Try it: change the investigation boundary
- Read each library’s evidence in turn.
- Check each installed and proposed version.
- Combine findings without a handoff.
Coordination is simpler, but a long investigation may accumulate distracting material.
This is a task-boundary illustration, not a measured speed or cost comparison.
Change one condition: the work is coupled#
Now suppose the libraries share a plugin interface and one upgrade requires changing it. The investigations are no longer independent. A worker’s assumption about that interface may become obsolete when another worker proposes a different version.
Keep one owner for the shared compatibility decision. Narrow workers to questions whose answers remain useful, or have one agent investigate the coupled change. Splitting by “frontend”, “backend” and “tests” does not remove a dependency that crosses all three.
Permissions are another possible boundary. A research worker may need documentation access but no repository writes. Enforce that restriction in its actual tools and credentials. A separate conversation or the job title “researcher” is not a security boundary.
A second worker also needs a reason beyond reassurance. If both reviewer and builder receive the same wrong version requirement, they may agree on the wrong result. Ask a reviewer to check the requirement and evidence, not merely endorse the builder’s summary. The PR review guide explains that responsibility in software delivery.
Choose who resolves a disagreement#
Chapter 8 describes peer coordination, a manager, hierarchies and actor–critic arrangements. Apply each to the same library report rather than treating them as a ladder of increasingly capable systems.
A manager can assign the three investigations and own the combined report. A hierarchy introduces intermediate coordinators when that helps divide a real task. Neither arrangement supplies a correct answer merely by naming a supervisor. If two findings conflict, the coordinator still needs to inspect their source versions and assumptions.
A peer vote can select a proposal, but three workers repeating the same obsolete release note do not provide three independent pieces of evidence. Removing a central manager also does not remove a shared search service, storage dependency or model failure. Redundancy requires a plan for those failures, not just more conversations.
If the third investigation times out, a valid partial report should identify the missing library. The other workers’ agreement cannot establish its compatibility. Decide in advance whether the workflow returns that partial result, makes a bounded further attempt or asks a person.
In a proposal-and-critique loop, one worker drafts and another checks. Using the label actor–critic for those roles does not establish that reinforcement-learning updates occur. Keep feedback in the next input separate from changing model weights. These are qualifications of the coordination patterns, not a benchmark ranking of them.
What the public evidence supports#
Anthropic’s June 2025 research-system report describes benefits on broad investigations with independent search directions, alongside higher token use and coordination costs. Its internal research evaluation is not evidence that adding workers improves every coding task. The useful lesson to test here is separation of investigations, not a transferable speedup percentage.
A later Anthropic study published on 13 August 2026 explores both collaboration and failures in experimental swarms. In its vulnerability-search comparison, the coordinated setup searched more broadly and spent more tokens; restricting the comparison to core directories changed the apparent efficiency advantage. It also documents difficulties when workers depend on each other’s changing contributions.
Those experiments do not settle the best architecture for this three-library report. They explain why a fair comparison must account for the task boundary, budget and result quality. More findings, more pull requests and a better accepted outcome are different measurements.
Framework names need a date#
The early-release chapter’s framework list is a historical snapshot. On 25 September 2026, the Swarm repository states that Swarm has been replaced by the OpenAI Agents SDK. Do not copy its old installation example as a current recommendation for a new production system.
The AutoGen repository states that it is in maintenance mode, with no new features or enhancements, and directs new users to Microsoft Agent Framework. Maintenance is not the same as disappearance: its contribution guidance still allows bug fixes, security patches and documentation improvements.
Those are the maintainers’ dated directions, not a ranking of the best framework for this task. Evaluate the supported APIs, permissions, saved state, cancellation and migration work against the actual requirements. Changing libraries is an application change that needs the same representative task checks as changing a prompt.
Decide with a bounded comparison#
Start with a workable single-agent version and record what prevents it from doing the job well. A missing tool or unclear requirement is not automatically a reason for another worker. Improve the setup when the setup is the problem.
Then compare the proposed split on the same representative tasks. Record missed breaking changes, unsupported compatibility claims, unresolved questions, elapsed time, model and tool costs, and human checking time. Use repeated runs where practical; one successful example can hide unstable behaviour. These are proposed evaluation criteria, not measured results.
Include a worker timeout, contradictory findings and a shared dependency. Decide whether the coordinator returns a partial report, investigates further or asks a person. Cap total work across the whole task, not only each worker, so delegation cannot multiply the spending limit unnoticed.
Keep the split when it improves the outcome enough to justify its extra work. For execution and recovery, continue with whether the task needs more coordination than the existing pipeline provides. The number of agents alone does not decide that either.
Questions people also ask
3 QUESTIONSDo multi-agent systems require different models?
No. Separate workers can use the same underlying model with different tasks, context and tools. That separation does not guarantee that their mistakes are independent.
Must multiple agents run at the same time?
No. One worker can investigate and hand its result to another later. Separate responsibilities and parallel execution are different design choices.
Is a reviewer agent enough to make a builder trustworthy?
No. A reviewer may inherit the same mistaken requirement or accept an unsupported summary. Give it the actual change, relevant requirements and test results, and keep the checks and approval rules the task needs.