Adding a second agent creates a coordination problem before it creates a capability gain. Someone must define the assignment, preserve the relevant context, reconcile the result and decide whether another attempt is allowed. Those obligations exist even when the second agent produces nothing useful. The title describes that architectural asymmetry, not a universal measured growth rate: extra capability is possible, but it has to earn the machinery introduced to obtain it.
Start with a working single-agent baseline. Split one part only when you can name the missing capability, state the boundary of the delegated task and verify the returned artifact. This article develops a coordination-budget table and a handoff contract for that decision. Its examples and numbers are hypothetical; they are not results from a benchmark or a client deployment. AI assisted the drafting and the conceptual cover.
Define the result before multiplying the workers
A system becomes more capable when it completes a useful job that the baseline cannot complete reliably, or achieves an agreed outcome within a better operating constraint. More messages, more tool calls and a longer final answer do not establish that improvement. The unit of value belongs to the user: a resolved support case, an accepted code change or a decision supported by the required evidence.
Consider a support workflow that proposes an account adjustment. It reads a customer's request, retrieves the applicable policy and prepares a recommendation for an authorized operator. Success means the recommendation matches the relevant account facts and policy version, contains the required evidence and leaves the adjustment untouched until the authorized action. A persuasive explanation attached to the wrong account is a failure.
The baseline could be one agent with retrieval and a narrowly defined set of read-only tools. It might already have several model calls, retries and deterministic checks. Single-agent does not mean one prompt, and several calls do not automatically constitute useful specialization. Keep the baseline reasonably competent before comparing it with a more elaborate arrangement.
Now identify the failure you want to remove. Does the baseline overlook a separate source collection? Does irrelevant context crowd out a decisive policy exception? Does a check require a tool that the main worker should not access? Each answer suggests a different intervention. Better retrieval, a deterministic validator or a smaller context may address the problem without introducing another autonomous decision-maker.
Anthropic expressed the underlying design principle in its December 19, 2024 article:
When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed.
Attribution: Anthropic, Building effective agents. The page now notes that its tooling landscape has changed. The quoted principle is useful here as a decision criterion, not as current framework-selection advice.
Write the proposed gain as an observable change. For the support example, a policy specialist should identify the relevant exception and return the source passage that makes it applicable. Its job is not to offer another general opinion about the customer. That difference determines what the coordinator must send and what it can accept.
Put coordination on the same decision table as capability
Before adding a role, fill in the row that describes its intended contribution. Each row needs both a benefit and the recurring work introduced to obtain that benefit. A blank cost cell does not mean the cost is zero; it means the architecture decision is unfinished.
| Proposed split | Capability to establish | Coordination to budget | Acceptance evidence |
|---|---|---|---|
| Parallel source researchers | Find distinct required evidence sooner | Scope division, duplicate removal and source reconciliation | Required facts linked to inspected sources |
| Policy specialist | Apply an exception missed by the baseline | Versioned input, exception ownership and conflicting advice | Applicable rule and supporting account facts |
| Separate reviewer | Catch a specified class of error | Review inputs, disagreement handling and revision limits | Reproducible defect or passed external check |
| Restricted action executor | Enforce a distinct authority boundary | Exact payload binding, approval expiry and outcome tracking | Authorized action receipt and resulting state |
| Dynamic coordinator | Discover subtasks that cannot be fixed beforehand | Planning, worker limits, cancellation and merge ownership | Accepted result within the complete run budget |
The table is a proposal template, not a ranking of architectures. A restricted executor, for example, may be ordinary application code rather than another model. Keeping the authority boundary can be useful even when the proposed agent role is removed. Likewise, fixed source partitions can use a predefined parallel workflow instead of a coordinator that reasons about staffing.
For teams deciding whether orchestration complexity is justified, Pharos Production describes an AI delivery process that defines the goal, tool surface and evaluation set before production readiness. That process connects the architecture decision to an inspectable outcome. It does not prove that adding an agent will improve this hypothetical support workflow.
Separate recurring run costs from the engineering work needed to maintain the arrangement. A worker may consume little inference while requiring a difficult incident procedure, a new permission boundary and another prompt to version. Conversely, an expensive research branch may be acceptable when it produces evidence that materially changes a valuable decision. Record those judgments separately rather than compressing them into an unsupported universal return estimate.
Every added role should have a removal condition. If the specialist returns the same material as the baseline, if the coordinator repeatedly repairs its output or if its benefit disappears after retrieval improves, revisit the split. An architecture diagram should not become the reason a worker stays in production.
Measure the critical path, including the merge
Parallel workers shorten a run only when the work they perform can proceed independently and their outputs can be combined without recreating the original task. Drawing branches on a diagram does not establish either property. List the inputs each branch needs and identify which of them are produced by another branch.
In the support example, account-history retrieval and policy-document retrieval can start together if both have the identifiers they need. Applying an exception usually waits for both results. Writing the final recommendation then waits for that interpretation. Those dependencies remain even if each box is labeled as a specialist agent.
Use an explicit timing model for a proposed parallel section:
Elapsed time = preparation + longest required branch + merge + verification + recovery
This is a planning decomposition, not a universal performance equation. Real stages can overlap, queue or repeat. Its purpose is to prevent the fastest worker's completion time from being presented as the speed of the full service.
Suppose, hypothetically, two independent retrieval branches take eight and twelve seconds. Preparation takes three, merging takes seven and verification takes six. Ignoring queuing and retries, the complete parallel path takes twenty-eight seconds. If a competent sequential baseline completes the same accepted job in twenty-four seconds, the visible parallelism has not created a latency improvement. It may still provide better coverage, but that would be a separate claim to verify.
Anthropic's multi-agent research system report, published June 13, 2025, describes a successful use of parallel exploration across separate context windows. It also reports substantial token consumption and explains why highly dependent work can be a poor fit. That is evidence for a conditional design opportunity, not proof that every workload should use the same topology.
Treat merge ownership as an architectural responsibility. If two researchers disagree about the policy effective date, the coordinator must resolve the conflict against an authoritative source. Concatenating both answers only moves the unresolved problem into the final response. Assign a deadline and an explicit incomplete-result state so the merge cannot continue indefinitely while appearing to make progress.
Give every handoff an input version and a stopping condition
A useful task description says what the worker owns, what it receives and what it must return. It also describes the result that should cause the worker to stop. Without those boundaries, a specialist can expand a narrow assignment into another complete attempt at the original job.
For the support workflow, the policy worker receives a redacted account snapshot, the relevant jurisdiction or product category and a fixed policy version. It returns the applicable rule, the supporting passage and any unresolved eligibility fact. It has no authority to change the account. If the snapshot lacks a required fact, the correct output identifies that absence rather than filling it with an assumption.
A compact handoff might contain these fields:
- Task identifier, parent identifier and the exact decision being supported.
- Input artifact references, versions and the facts that may change during the run.
- Allowed data and tools, plus actions outside the worker's authority.
- Required result fields, source references and the acceptance check.
- Time, tool and token limits, together with the allowed revision count.
- Terminal outcomes: completed, insufficient evidence, invalid input or stopped by budget.
Do not force every failure into an empty success-shaped response. A missing policy document and an inapplicable exception are different findings. The coordinator needs that distinction to decide whether to retrieve another input, reject the request or ask a person to resolve the uncertainty.
A separate context window can reduce distraction, but it can also hide the one fact that matters. Give the worker the minimum sufficient context for its assigned decision, then preserve a route to request a specific missing input. Sending the entire conversation to every worker pays for duplication and weakens the point of the split. Sending only a cheerful one-line assignment can remove the boundary conditions.
When inputs change, identify which results become stale. A policy worker's conclusion for one account snapshot should not silently authorize an adjustment against a later balance. Tie the returned artifact to its input version and let the coordinator invalidate it when a relevant fact changes. This is especially important when a delayed worker returns after another part of the workflow has already completed.
Validate the result at two levels. A response can contain every required field and still cite a passage that does not support its conclusion. First check the structure, identifiers and input version. Then check the relationship between the evidence and the decision. A schema violation should not reach the interpretation step, while a valid schema should not be treated as proof of factual correctness. Keep both outcomes in the task record so a later failure can be attributed to the right boundary.
Keep the handoff as an artifact that an operator can inspect. A transcript may contain the necessary facts somewhere, but an incident responder should not need to reconstruct the task contract from a long exchange of acknowledgments and revisions.
AI-assisted diagram rendered from code for the hypothetical support workflow. Evidence acceptance and action authorization are separate checks.
Budget accepted outcomes, not impressive activity
A coordination budget needs a boundary around the whole run. Worker-level limits alone leave room for a coordinator to create replacements, restart failed branches or request repeated reviews. Track the parent run's total consumption and make child allocations reduce the remaining allowance.
The AI agent development process described by Pharos Production includes evaluation sets, shadow-mode checks, structured output validation and audit logging. Applied to this decision, those practices create places to compare accepted results and inspect failures. The service description is process evidence; the budget example below is an independent illustration.
Count inference across the coordinator, workers and reviewers. Keep tool charges and human review time visible as separate quantities. A cheap output that requires substantial operator repair may have poor economics, while a costlier output that resolves a difficult case can be worthwhile. Avoid converting that judgment into currency unless the assumptions behind the conversion are available.
For a hypothetical set of ten previously retained cases, suppose one architecture spends one hundred cost units and produces eight accepted results. Its observed cost per accepted result is twelve and a half units. Another spends one hundred and fifty units and produces the same eight accepted results. Its corresponding value is eighteen and three-quarter units. These invented numbers illustrate the denominator; they do not establish a performance result for either architecture.
Include unsuccessful and budget-exhausted runs in the numerator. Otherwise, repeatedly abandoning difficult cases can make the surviving outputs look deceptively efficient. Record how many cases required a person to finish the job, and distinguish that result from autonomous completion under the stated acceptance contract.
A hard allowance can create a difficult final decision. The coordinator may have enough budget to summarize existing evidence but not enough to reopen research. Define whether a partial answer is acceptable for that task and what must be disclosed with it. A support recommendation with a missing eligibility fact should not become actionable merely because the token counter is almost exhausted.
Cancellation also needs ownership. Stop unnecessary workers when the parent task ends, prevent late results from reopening it and retain the costs already incurred. If a tool call is in flight, record its uncertain outcome until the application can establish what happened. A canceled reasoning task and a canceled external operation are not the same event.
Make review independent in the way that matters
Two agents agreeing is weak evidence when both saw the same incomplete source, used the same assumption and were rewarded for producing a tidy answer. Assigning one of them a critic persona does not create new information. The review design should specify what the reviewer can inspect that makes its judgment useful.
For the support recommendation, a reviewer could check that the cited policy passage exists, that the account snapshot supports the stated eligibility conditions and that no action was attempted. Some of those checks are better implemented deterministically. Use a model for interpretation where needed, but retain direct checks for identifiers, required fields and exact payload boundaries.
Decide whether the reviewer sees the proposed answer before forming its own assessment. Hiding the answer can reduce one route to agreement by imitation, but it may also duplicate expensive research. Showing it allows a targeted critique, provided the reviewer has access to the underlying evidence. Choose the arrangement for the error you are trying to detect, not because independent review sounds reassuring.
Anthropic's August 13, 2026 research on emerging multiagent systems describes both improving coordination and persistent failures involving shared assumptions, interdependence and incomplete information exchange. Its experiments cover particular models and environments. They support inspecting those failure modes; they do not supply a universal failure rate for a production workflow.
Define how disagreement ends. A reviewer should return a reproducible defect, a source conflict or a clearly bounded uncertainty. The coordinator can then repair the relevant artifact, request the missing fact or escalate the decision. Repeatedly asking another reviewer until one approves is approval shopping, even when every individual call fits within its local budget.
Preserve the original objection after a correction. An operator should be able to see which input changed and why the revised result is now acceptable. If the correction cannot answer the objection, a more confident final paragraph should not close the case.
Keep shared state and action authority explicit
Splitting reasoning does not require distributing write authority. In the support example, multiple workers can prepare evidence while a single controlled component owns the account adjustment. That component should receive an exact action request tied to the current account state and the relevant approval, rather than interpreting a worker's free-form suggestion as permission.
An action boundary still needs concurrency control. Two branches might independently conclude that an adjustment is necessary. If each can execute it, both can be locally correct while the combined outcome is wrong. Choose one owner for the consequential transition and make duplicate requests converge on a known operation identity where the underlying system supports that behavior.
A timeout is not proof that an action failed. If a worker loses the response after submitting a write, starting another worker with the same broad goal can repeat the side effect. The recovery path must first distinguish an unsubmitted request from an operation whose result is uncertain. Retrying safely depends on the external system's semantics, not on the coordinator's confidence.
Keep proposed state separate from committed state. A worker can suggest a policy classification or a code patch without declaring it accepted. The coordinator should publish a new accepted artifact only after the required checks succeed. Downstream workers then consume the accepted version instead of racing against partially written shared notes.
Access boundaries should follow data and action needs. A policy researcher may need the product category but not the customer's full history. A reviewer may need a redacted transaction record but no execution credential. Restricting those surfaces can justify a split even when latency stays unchanged, although the permission controls must be enforced outside the model's prose instructions.
Treat returned source material as data, even when another agent selected it. A retrieved document may contain instructions addressed to its reader; those instructions do not acquire authority by passing through a specialist. The coordinator should preserve the source reference and relevant evidence without accepting an embedded demand to change tools, widen access or bypass an approval. A second model can relay an unsafe instruction as fluently as the first, so delegation does not remove the application's trust boundary.
Logs should make the decision reconstructable without copying every sensitive input into every transcript. Retain artifact identifiers, relevant versions, authorization decisions and tool outcomes according to the application's data policy. The coordinator needs evidence that a check happened, not unrestricted access to every secret held by a specialist.
Use a bounded decision process and keep the simpler fallback
Begin with retained failures and existing traces. They can show whether the apparent problem is missing information, a poor tool interface or a task that genuinely benefits from separate reasoning. Do not launch a large comparison grid merely because the architecture has several possible roles. A proposal that cannot identify its target failure is not ready to consume an evaluation budget.
If new evidence is necessary, predeclare one candidate split, a small relevant case set and a fixed allowance. Keep the task inputs, acceptance rule and operating limits comparable with the baseline. Record any deliberate difference, such as an additional source collection or a restricted tool surface, because that difference may explain the result more directly than the number of agents.
A small comparison is a decision aid, not proof of a broad capability law. Inspect the cases individually and preserve uncertainty when the outputs are mixed. Stop when the allowance is consumed. If the result does not justify the extra coordination, keep the baseline and record what evidence would warrant revisiting the decision.
During a limited rollout, retain a way to route eligible work through the simpler path. Make the operator responsible for that choice explicit, and check that reverting the routing does not abandon external operations already in progress. The useful fallback is a working service behavior, not an old diagram stored beside the new one.
Which boundary in your workflow could become a separately verifiable artifact, and which would merely split a shared uncertainty between two agents?
Key Takeaways
- Keep one agent when the task shares most of its context and the proposed split adds no separately verifiable result.
- Split a task when independent work, a necessary capability or an enforceable permission boundary justifies the handoff and merge work.
- Retain a second reviewer when it detects the specified error through evidence or checks that the baseline does not already provide.
- Stop expanding when the accepted-outcome gain fails to justify the complete coordination budget, and preserve the simpler working route.
More insights to read
- We Let the AI Agent Draft the Article. We Wouldn’t Let It Publish.
- Agents
- Building effective agents
- Effective context engineering for AI agents
- Demystifying evals for AI agents
About the author
Dmytro Nasyrov. Photo supplied by the author.
Written by Dmytro Nasyrov PhD, software architect with 24 years of production experience. Dmytro is the founder and CTO of Pharos Production. He works on production software architecture for FinTech, AI, Web3 and blockchain systems.
Top comments (2)
The coordination budget is usually invisible until agents disagree. At that point the merge is no longer formatting; it is a decision about which evidence, authority, and state wins. I would add one more removal condition: if the coordinator cannot explain why one branch was accepted over another, the extra agent has created output volume rather than capability.
The “separately verifiable result” is the key distinction for me. Otherwise, adding agents can just distribute the same uncertainty across more context windows. A split should earn its complexity by producing something the baseline couldn't reliably verify.