A bounded solver and critic handoff
- Choose a bounded review path. Define what a useful result means and what the solver may do. All drafting, reviewing and revising work shares the run budget.
- The original solver produces a candidate. The solver works inside the application's existing permission boundary. A candidate is not yet an accepted result.
- Pass review context, not write authority. The critic uses a different model family and has no tools. It can identify concerns but cannot edit the shared workspace.
- Return feedback to the original solver. The described critique pattern permits one revision. Comments are information to inspect, not proof that the critic is right.
- Check the revised outcome independently. Use task-specific acceptance checks and supporting evidence. Agreement between models does not prove correctness.
- End with an explicit result. Accept only when the application criteria are met; otherwise report failure. Do not turn critique into an unbounded exchange of revisions.
Splitting a task does not remove its dependencies. It moves some of them into the messages, shared state and acceptance checks between workers. Smaller toolsets and separate contexts can help each worker concentrate, but the application must still assemble a correct result.
The evidence is mixed. Anthropic reports benefits for parallel research, while Cognition illustrates coordination risks with hypothetical construction tasks. A study of execution traces documents additional failure modes. These accounts concern different workloads, so none is a universal verdict on whether to use multiple agents.
New to the mechanism? Start with the illustrated agent loop. Sources for the September addition were checked on 14 September 2026. The retained human-review date does not certify that addition; editorial review is pending.
The patterns
These patterns differ in who selects the work and how control returns.
| Pattern | Structure |
|---|---|
| Single agent | One agent uses its permitted tools without delegating to other agents |
| Orchestrator-worker | A lead agent plans and delegates to subagents that run in parallel, each with its own context |
| Supervisor | A central agent routes each turn to a specialist and receives control back |
| Hierarchical | A supervisor of supervisors, for deeper task trees |
| Network | Any agent may call any other, with no central router |
| Router | A classification step selects a specialist to handle the input |
LangChain’s own documentation opens its multi-agent guidance with a caution worth repeating before any of them are adopted: not every complex task requires this approach, and a single agent with the right tools and prompt can often achieve similar results.
The case for, with numbers
Anthropic published a detailed account of building a multi-agent research system on the orchestrator-worker pattern. A lead agent analyses the query, forms a strategy, and spawns subagents that explore different aspects at the same time, each with its own context window, returning condensed findings for the lead to compile.
Their reported comparison:
We found that a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.
Two qualifications belong with that figure. The evaluation is internal and not described in enough detail in the post for independent reproduction. The comparison is also not model-matched: the multi-agent configuration uses a different mix of models from the single-agent baseline.
Anthropic’s architectural rationale is parallel search and compression. Subagents explore different aspects of a question in separate contexts and return condensed findings to the lead. The authors also argue that distinct tools, prompts and search paths reduce path dependency: early choices need not constrain every worker’s investigation.
The cost, stated plainly by the same team
There is a downside: in practice, these architectures burn through tokens fast. In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.
For economic viability, Anthropic argues that the task’s value must justify the additional token use.
The finding that reframes the gain
Anthropic offers this explanation:
Multi-agent systems work mainly because they help spend enough tokens to solve the problem.
They report an analysis on BrowseComp in which three factors together explained 95% of the performance variance, and token usage by itself explained 80%. The other two factors were the number of tool calls and the choice of model.
This is an association in the reported evaluation, not a causal estimate of how much benefit came from spending more tokens or adding agents. Total token usage across a run is not the same as the amount of context occupied on any one model call. The analysis does not establish that a single agent exhausted its context capacity, or that increasing spend alone would reproduce the improvement.
Where Anthropic says not to use it
The same post limits its recommendation:
Further, some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.
Their positive criteria are equally concrete: tasks involving heavy parallelisation, information exceeding single context windows, and interfacing with numerous complex tools.
The case against
The day before that post, Cognition published an argument in the opposite direction under the title Don’t Build Multi-Agents. It rests on two principles:
- Share context, and share full agent traces, not just individual messages.
- Actions carry implicit decisions, and conflicting decisions carry bad results.
Cognition uses two hypothetical versions of a Flappy Bird task to distinguish these problems. In the first, the task is divided between a background worker and a bird worker. One misunderstands the subtask and builds a Super Mario Bros-style background; the other produces a bird whose appearance and movement do not fit Flappy Bird. This illustrates miscommunication of the task, not two workers successfully meeting compatible briefs.
In the second hypothetical, the workers receive preceding context but choose incompatible visual styles while working separately. The problem is now conflicting decisions made during execution, not simply misunderstanding the original request.
The broader design concern is that actions can embody unstated choices about naming, formatting, error handling or libraries. A summary can omit those choices, leaving other workers or the coordinator unable to account for them.
Cognition recommends a single-threaded agent with continuous context. When long histories threaten to overflow the context window, it proposes a dedicated model to compress actions and conversation while retaining relevant details and decisions. This addresses context pressure, not a requirement to split the work.
A useful design constraint
Analysis: parallelise reads; control writes. This is a design recommendation drawn from the two accounts, not a claim that either establishes a universal rule. Anthropic’s research workers return findings for a lead agent to combine. Cognition’s hypothetical construction examples involve outputs that must fit together. Independent writers can be appropriate when their ownership and merge rules are explicit; where those boundaries are unclear, a designated write path reduces the opportunities for conflicting decisions.
How they fail, from real traces
A peer-reviewed study asked the question directly, and the framing in its abstract sets expectations appropriately: despite enthusiasm for multi-agent LLM systems, their performance gains on popular benchmarks are often minimal.
The authors assembled a dataset of over 1,600 annotated execution traces across 7 multi-agent frameworks and developed a taxonomy through close analysis of 150 traces with expert annotators. They report an average Cohen’s kappa of 0.88 for inter-annotator agreement. Kappa measures agreement on labels after accounting for agreement expected by chance; it is not the proportion of agent runs that succeeded. The result is 14 distinct failure modes in three categories:
| Category | What goes wrong |
|---|---|
| System design issues | The specification itself: tasks or roles disobeyed, steps repeated, termination conditions not understood |
| Inter-agent misalignment | Communication between agents: derailment, withheld information, reasoning that does not match the action taken |
| Task verification | Checking: terminating early, verifying incompletely, or verifying incorrectly |
The authors identify failures in system design and interaction, not only limitations of the underlying model, and argue that fixes must address those structures.
A protocol alone does not solve these problems. MCP standardises exchanges between an application’s clients and servers exposing tools and context. It is not a general agent-to-agent coordination protocol and does not establish that returned content is correct. Well-formed messages do not resolve conflicting decisions or missing evidence.
The taxonomy distinguishes information withholding, where an agent fails to share information that could affect another agent’s decisions, from reasoning-action mismatch, where an agent’s actions diverge from its stated reasoning. These are different failures; a mismatch does not by itself show that a decision went unshared.
Deciding
Putting the sources together gives a usable sequence.
Start with one agent. LangChain cautions that complex tasks do not necessarily require multiple agents. Establish a baseline before adding coordination. Context pressure is one reason to consider a split, alongside measured benefits from specialisation or parallel work.
Check the task shape against Anthropic’s criteria. Genuinely parallel subtasks, information exceeding one context window, many complex tools. Be cautious when subtasks continually constrain one another or require the same evolving context. A dependency between steps alone does not rule out delegation.
Then apply the read/write test. Define who may write shared artefacts and how changes are reconciled. Parallel readers feeding a designated writer are one option; independent writers need explicit ownership and merge rules. This is a design recommendation, not a ranking established by the cited comparisons.
Measure the total run budget. Anthropic’s roughly fifteenfold token multiple is an observation from its own system relative to chats, not a default for every multi-agent topology. Count the coordinator, workers, review calls, retries and synthesis on your workload before deciding that the split is affordable.
Instrument verification specifically. Task verification is one of three categories in the taxonomy; that does not mean one third of observed failures concerned checking. Check outputs against evidence outside the producing agent’s own success report, as discussed under agent harnesses.
Recent example: adaptive model orchestration
GitHub’s September 2026 HydraFusion research preview asks a different question from “how many workers should run?” It selects an execution pattern using capability signals, rather than simply selecting a model. The described patterns are:
| Pattern | Execution path | Cost and failure trade-off |
|---|---|---|
| Single | A selected model handles the task directly | Avoids reviewer coordination; does not mean a single API invocation |
| Cascade | An efficient solver drafts; a quality gate accepts or escalates to a stronger solver | Easy tasks may avoid escalation, but a weak gate can accept bad work or escalate needlessly |
| Critique | A solver drafts; an independent, tool-less critic from another model family reviews; the original solver revises once | Adds review and revision work; shared blind spots can survive independent contexts |
In a cascade, acceptance ends the path; escalation is conditional. In the critique path, the critic contributes information but does not share the solver’s ability to edit the workspace. That preserves a controlled write path rather than asking multiple models to modify shared artefacts at the same time. The visual walkthrough at the top follows this bounded critique sequence.
Evidence boundary: this is a research preview evaluated offline in a tuned configuration. The workloads also informed policy development. The article does not establish independent production reliability, a universally reproducible quality gate or guaranteed savings. Its guidance favours well-scoped initial requests; longer iterative sessions remain a separate question. Treat it as a concrete design to evaluate, not a reason to promise equivalent results on your workload.
Quality escalation is not transport fallback
A quality escalation responds to an inadequate candidate: the request ran, but its result did not meet the acceptance criteria. A transport fallback responds to an unavailable route or failed connection. These need different records and different safety checks.
Do not replay a write merely because the connection failed. Its outcome may be unknown. Preserve the operation identity and reconcile with the target, as described in agent observability. A policy denial is neither a quality failure nor a reason to select a more permissive provider.
Make the handoff a contract
The following is a recommended application contract, not a standard supplied automatically by these frameworks. A document-search worker should receive a question and permitted source scope, not the entire parent conversation and all of its credentials.
| Contract element | Example for a research worker | Why it matters |
|---|---|---|
| Task and acceptance condition | Find the current procedure and supporting passage | A fluent summary without evidence must not count as completion |
| Allowed capabilities | Read-only search in the authorised collection | Narrow context is not, by itself, a security sandbox |
| Result shape | Source, revision, passage and unresolved questions | The parent needs evidence and uncertainty, not only a conclusion |
| Shared budget | Child work is charged to the same run as the coordinator | Local worker limits cannot bound unlimited fan-out |
| Cancellation | Parent termination cancels and accounts for outstanding work | Background work must not keep spending after the task ends |
| Write ownership | Only the designated action path can submit an approved change | Independent good intentions can still produce incompatible effects |
Context isolation reduces accidental sharing; same-process execution does not enforce isolation against arbitrary code. Use actual permission and execution boundaries where the threat model requires them. Treat returned worker text as evidence to validate, not a new system instruction.
Diagnostics for the split
| Symptom | Evidence to inspect | Design question |
|---|---|---|
| Every draft escalates | Gate decisions, candidate quality and accepted outcomes | Is the first solver useful, or merely an extra stage? |
| Critique repeatedly changes correct answers | Candidate and revision grades on the same fixtures | Does review add evidence or just confident disagreement? |
| Several workers investigate the same sources | Task briefs, source IDs and parent synthesis | Was the work actually decomposable? |
| Individual outputs pass but the combined result fails | Handoff contracts and final outcome checks | Did specialists make incompatible assumptions? |
| Parent stops but cost keeps increasing | Child spans and cancellation acknowledgements | Does the coordinator own worker lifetimes? |
What this page does not tell you
It does not prescribe a transferable latency figure. Parallel execution can shorten independent work, while sequential review and escalation can lengthen a run. A synchronous wave that waits for every worker is limited by its slowest member. Measure the actual task path, including coordination and retries, rather than assuming a topology is faster from its diagram.
It also does not tell you the 90.2% will reproduce for you. It was measured on one team’s internal evaluation, on research tasks, with a specific model pairing. The BrowseComp association likewise does not establish a general causal mechanism. Whether the split helps your workload is an evaluation question. Compare outcome quality, latency and total resource use against a single-agent baseline on your own tasks.