Before You Add an Agent, Pass the Architecture Gate

The appeal of an AI team is obvious: one agent researches, another critiques and a third synthesises. But the number of agents is not the amount of useful work. Every participant introduces messages to route, context to compress, decisions to reconcile and new places for an error to become someone else’s assumption.

The practical question is therefore not “Can we split this task?” It is “What evidence says splitting this task will improve the accepted result enough to justify the coordination?” That question deserves a gate before a workflow becomes a swarm.

Begin with the single-agent baseline

A baseline is not an argument against collaboration. It is the control that makes collaboration measurable.

A 2026 study in Nature Machine Intelligence held prompts, tools and compute budgets constant while comparing a single agent with four multi-agent architectures across 260 configurations, six agentic benchmarks and three model families. The results were sharply dependent on the task. Centralised coordination improved performance by 80.8% on one structured financial-reasoning benchmark, while every multi-agent variant degraded on a sequential planning benchmark; the weakest result was 70.0% below the single-agent baseline. The study’s strongest predictor of absolute performance was the single-agent baseline itself, and its architecture-selection rule is presented as a within-domain selection aid—not a universal scaling law. Read the study.

That is a useful discipline for everyday engineering. Before adding a specialist, run the simplest credible workflow against the same task distribution and acceptance criteria. Record not only whether it succeeds, but how much time, computation, tool use and human attention it consumes. Then state the collaboration hypothesis plainly: perhaps parallel research should improve coverage, or an independent verifier should catch a class of errors. If the hypothesis cannot be named, the extra agent is probably decoration.

This also matches the practical guidance in OpenAI’s guide to building agents: maximise a single agent with clear tools and instructions before splitting a workflow, and introduce multiple agents when the logic or tool selection has become genuinely difficult to manage.

Classify the task before choosing the topology

There is no universally superior agent graph. The task determines what kind of coordination can pay for itself.

For an independent or parallel task, contributors can investigate separate questions without repeatedly changing one another’s working state. A central synthesiser can compare their outputs against one acceptance test.

For a sequential task, each step depends on the state produced by the last one. Adding agents may force the workflow to restate or compress that state at every boundary. If one coherent path can inspect the environment and act directly, collaboration may add latency and opportunities for drift without adding useful diversity.

Shared-state work needs a third level of caution. Multiple agents editing the same plan, repository or finite queue are not simply working in parallel; they are competing to define the state. Shared ownership requires a conflict protocol, a canonical owner and a tested merge or proposal mechanism. Otherwise, let contributors return evidence or proposed changes while one owner controls the mutable artifact.

Communication itself is part of the architecture. Research on LLM-based communication topologies found that moderately sparse connections often balance useful information diffusion against error propagation. Dense connectivity can spread one mistaken output through the whole group, while a chain can suppress useful discoveries. The EMNLP study supports a measured design hypothesis, not a fixed graph prescription.

Anthropic reported roughly 15 times the token use of ordinary chats in its research system, with early failures: agents spawned too many workers, searched past sufficiency and distracted one another with updates. How we built our multi-agent research system describes those results. Separately, Patterns and problems in multiagent systems shows correlated agents making the same bad decision or flooding finite resources.

Use an architecture gate

A lightweight gate can make the choice explicit without turning every workflow into a committee meeting:

1. Define the accepted outcome. Name the user goal, hard constraints, irreversible actions and the person or system that can accept the result. 2. Run the baseline. Use one capable agent with the clearest available tools and measure outcome quality, cost, latency and reviewer effort. 3. Classify the task. Mark the work as parallel, sequential, shared-state, tool-dense or some combination. 4. State the collaboration hypothesis. Identify the expected benefit: coverage, independent disagreement, verification, speed or something else. 5. Choose ownership. Name one synthesis or acceptance owner. Give each contributor a non-overlapping question or artifact boundary. 6. Set a budget and stop condition. Bound steps, messages, retries, tools and time. Define when the workflow stops, escalates or returns a partial result. 7. Compare the accepted result. Test the collaboration against the baseline on the same outcome criteria, including missed constraints and coordination overhead.

The gate should be easy to fail. If the task is tightly sequential, the baseline is already strong, the proposed benefit is vague, or no one has capacity to review the additional work, keep the simpler workflow.

Treat handoffs as interfaces, not courtesies

“The next agent has been notified” is not a successful handoff. A handoff transfers interpretation and sometimes authority, so it needs an interface that another person can inspect.

A useful handoff states the objective, receiving owner, permitted scope, resource and time ceiling, returned artifact or question, sources, constraints checked, uncertainty, residual risk and acceptance test. It should distinguish an observation, a proposed change and an authorised action. The receiving owner should not reconstruct those distinctions from a long transcript.

Evidence for this distinction is unusually concrete. A small controlled pilot of 64 coding-agent executions found that explicit delegation contracts improved evidence sufficiency in 22 of 30 paired comparisons and reduced reviewer ambiguity. They did not improve objective task outcomes in that setting, and they cost 13% more tokens and 38% more wall-clock time. Contracts bought reviewability, not correctness. See the pilot.

That is still valuable. A reviewer can reject an incorrect result more reliably when the work says what it checked, what it did not check and what authority it used. But the contract must not become a badge that substitutes for tests.

Design for shallow, interruptible oversight

Human review is not a decorative approval button at the end of an autonomous process. The reviewer needs enough evidence to understand the result, challenge it and intervene before a risky action becomes difficult to reverse.

The Characterizing Agents in Production study from IBM Research, based on 20 case studies and a survey of 306 practitioners across 26 domains, reports that 68% of production agents execute at most ten steps before human intervention and 74% rely primarily on human evaluation. This is a description of current practice, not proof that every workflow should have ten steps or that human evaluation solves reliability.

It points to a sensible starting posture: keep runs shallow enough to interrupt, make escalation explicit and treat reviewer capacity as part of system capacity. A workflow that generates more candidate work than anyone can understand is accumulating unexamined risk.

Evaluate the system, not just the last answer

An agent run can produce a persuasive final paragraph while leaving the wrong file changed, dropping a constraint during a handoff or consuming an unreasonable amount of time. Evaluation should therefore inspect both the trajectory and the resulting state.

Measure accepted-outcome quality alongside constraint misses, duplicate work, handoff count, retries, latency, token and tool cost, out-of-scope attempts, reviewer time and recovery success. When a workflow changes, compare it with the baseline repeatedly rather than trusting one impressive run. Anthropic’s evaluation guidance makes the same distinction between the full sequence of interactions and the final environment outcome.

Keep diagnostic traces and user-facing evidence related but separate. A trace can explain why a tool call failed; it cannot by itself prove that a user constraint was respected or that a person authorised the resulting change. The durable record should preserve the intent, owner, acceptance decision and relevant evidence, while runtime telemetry explains how the system got there.

The useful unit is accountable coordination

Multi-agent systems can be right when a task contains genuinely independent work, separate perspectives have measurable value or a verifier can intercept compounding errors. They can be wrong when the task is sequential, stateful, tool-heavy or already well served by one capable agent.

The architecture gate keeps that distinction visible. Establish the baseline. Match topology to task shape. Limit communication and authority. Make handoffs inspectable. Give a human a real chance to understand and stop the work. Then judge the collaboration by the accepted outcome and the cost of reaching it.

An AI organisation becomes more capable when it can explain why an agent was needed, what it was allowed to do, what evidence it returned and who accepted the result. Agent count is an implementation detail. Accountable coordination is the operating capability.