When Multi-Agent Coding Workflows Are Overkill

Multi-agent coding workflows are overkill when their token costs, handoffs, and time spent on review outweigh the time saved by parallel execution. For most everyday engineering tasks, a well-configured single agent is the better default. The decision to add another agent should follow evidence that the work is independent, valuable enough to justify the overhead, and supported by a clear verification plan.

Why multi-agent systems exist and what they promise engineering teams

A single coding agent serializes work that does not always need to be serial. If a feature branch, a bug fix, and a test-suite update are genuinely independent and take roughly the same time, running them in parallel can compress wall-clock time. The practical appeal starts with the gap between giving an agent a task and receiving its result. An engineer waiting for a Claude Code or Codex session can open another terminal and put that interval to use.

The tools increasingly support this way of working. Claude Code and Codex support background agents that return pull requests rather than inline suggestions, while agent architectures are converging around memory files, long-running execution, sub-agent orchestration, and repo awareness. These capabilities make delegation more substantial than asking for a code completion. An engineer can assign bounded work and return when there is a change to assess. The promise is a shift from writing every change to managing several streams of implementation, with shorter elapsed time when those streams can proceed independently.

Why the bottleneck is now attention, not generation

For most engineering teams, code production is no longer the binding constraint that parallel agents are meant to remove. Human attention and verification capacity are. An agent can produce another change while an engineer reviews the previous one, but that does not make the next review disappear.

Simon Willison has documented running four agents in parallel on separate worktrees while still being able to focus on reviewing and landing only one significant change at a time. Anthropic engineer Sid Bidasaria reported productivity gains from running several agents concurrently on Claude Code itself, but those gains depended on review keeping pace. Together, these examples distinguish concurrent activity from usable throughput. An engineer needs a separate mental model for each new thread and must check each change when it is done. Merge and integration can then absorb the time saved during coding, especially when changes meet in shared modules such as auth or billing.

The constraint remains whether agents run locally, in a code editor, or on a platform such as Replicas, which provisions isolated computing environments per task. Returning pull requests rather than inline suggestions helps surface and organize the work, but it does not compress the engineer’s decision about whether to land a change. Isolation of execution is not isolation of responsibility. Someone still has to understand how the result fits the system. More agents multiply the load on the resource that does not scale with agent count.

What multi-agent coordination actually costs in tokens and overhead

The same multiplication appears in token spend. Each agent consumes its own full context window, so the cost of understanding the task stacks. Agentic tools can consequently cost substantially more per engineer than seat-license estimates suggest. A budget based on access to the tool is not a budget for the work it performs. The relevant comparison is the cost of reaching an acceptable result, including coordination and verification.

Handoffs add costs of their own because information can be lost each time. If Agent A omits a critical detail from a summary, Agent B can fail without having made an obvious mistake in its own reasoning. Debugging B may tell little because the fault is in the summary it was given. Finding the missing context then means tracing it back from one agent to the other. This is a different debugging problem from tracing one agent’s conversation history, and adding handoffs gives it more places to occur.

Cost accounting becomes harder when runs span tools, environments, and credentials. Spend fragmented across those boundaries can obscure whether parallel execution saved time or merely repeated context consumption. Replicas provides attribution per agent run down to the model, harness, and credential, giving teams a basis for that comparison. Such accounting makes the trade-off visible. The multiplier is defensible only when the result is valuable enough, and the work independent enough, to absorb both the token bill and the effort of coordination.

The task properties that determine whether a second agent is worth it

Anthropic’s research found that a single agent did far better than multi-agent coordination on step-by-step planning tasks. In those tasks, each step depended on the previous one, and coordination fragmented the reasoning. This is the clearest disqualifier for parallel implementation. The dependencies in a dependency chain remain when the work is split among agents. It adds boundaries across which the reasoning must survive.

The first decision criterion is therefore independence. Subtasks parallelize cheaply when they can proceed without shared state or knowledge of what another agent is doing. Separate assignments can still depend on each other when they touch the same modules. Large-scale refactors across modules that are truly independent and security audits across separate services can pass this test. Sequential feature implementation, bug fixes with shared state, and incremental PRs that depend on context continuity usually do not.

The second criterion is value density, meaning whether the result is valuable enough to justify the extra context consumption and coordination. A costly multi-agent run to build a compiler can be defensible where the same architecture for a routine bug fix is not. Peking University’s case-bundle research offers a concrete example of bounded reuse in a valuable engineering task. Its CFD study replayed a reviewed case bundle to execute and post-process 140 independent geometry variants. The reusable design was established before the repeated execution, so the parallel work did not require each run to renegotiate the case.

A single agent is cheaper and easier to debug when the work relies on continuous reasoning. A second agent becomes a reasonable choice when the task splits into independent, read-heavy pieces and there is a real verification plan. Dividing the task into named roles must remove waiting without creating an equally costly need to coordinate.

The one multi-agent pattern that consistently earns its overhead

Independent review has the clearest, most consistent return because it uses isolation as an advantage. A reviewer agent reads the code with a clean slate rather than inheriting the implementation agent’s reasoning. Its lack of that reasoning can help it catch what the first agent missed. Unlike parallel implementation on shared state, this pattern does not require both agents to maintain a synchronized understanding throughout development. Their responsibilities meet at a reviewable change.

Cognition’s progression from “Don't Build Multi-Agents” to shipping a workflow in which one agent manages others illustrates this narrower case for review and orchestration. It does not establish that every task benefits from a team of agents. Instead, it shows that skepticism about loosely coordinated agents can coexist with a defensible role for bounded delegation and review. The distinction is the structure of the work. An orchestrated workflow still has to earn the tokens and attention it consumes.

Peking University’s case-bundle model makes a related distinction without requiring two separate agents. Build lets an agent help develop a case under engineering review, while Replay uses the reviewed case for new variants, possibly through a different runtime. These are modes of a coding agent. Design remains sequential, and parallelism belongs at the execution stage where the variants are independent. Similarly, a separate coding reviewer earns its extra context consumption only when the change is significant enough that catching a severe bug justifies the cost.

How can teams run Claude Code or Codex in the cloud before adding another agent?

Before taking a difficult task as proof of a single-agent ceiling, teams should check the harness and environment. Replicas is one option for running Claude Code or Codex in the cloud without managing the underlying infrastructure. It provides isolated computing environments pre-loaded with the team’s dependencies and tooling, supports Claude Code, Codex, Cursor, and Opencode, and returns pull requests. That changes the conditions under which the single agent works. It does not change the requirement to review what the agent produces.

Harnesses differ in ways that matter to task completion. Claude Code offers deep hook-event support and dynamic workflows, while Codex spans comparable surfaces at lower per-task token cost. Cursor emphasizes editor-bound, interactive development through inline editing, visual diffs, and integrated agent workflows. These differences make workload fit more useful than a benchmark headline when choosing a tool. A harness suited to interactive editing is not automatically the right choice for every long-running, autonomous task.

The execution environment can be just as important. A single agent with full repo context, tool access, and the ability to run tests can handle work that appears to require delegation in a shallower setup. An isolated VM in which an agent can install packages, run services, drive a browser, and verify its output gives that agent more scope to finish the task alone. A shared or under-configured environment can impose a limit that looks like an architectural weakness but is really an infrastructure constraint. Adding another agent does not by itself repair that constraint.

Support for different harnesses, as in Replicas, allows teams to route subtasks to Claude Code, Codex, Cursor, or Opencode according to task fit. The same flexibility helps establish a fair single-agent baseline first. Otherwise, teams risk adding coordination to compensate for a mismatch between the task and the tool. The meaningful ceiling is what one well-equipped agent can accomplish.

What teams that scale intelligently actually do differently

Teams that get durable value from coding agents measure what the agents produce before increasing their number. More merged PRs do not necessarily mean better delivery. The DORA metrics of deployment frequency, lead time, change failure rate, and mean time to restore can remain flat while longer reviews, rework, and larger diffs absorb the extra output. Agent activity alone cannot settle that distinction.

Useful measurement connects each run to its source, harness, model, and credential, as well as the time it consumes and the outcome it serves. Without that attribution, a second agent’s contribution is difficult to separate from duplicated effort. With it, teams can compare the added cost against what actually shipped and what broke. The comparison must include downstream work after an agent opens a pull request. Otherwise, the apparent gain excludes the very bottleneck that can erase the benefit of parallelism.

Teams can make better use of limited attention by planning how they switch context. Each parallel effort needs a labelled thread, its own branch, a defined scope, and a connection to a specific outcome. That is different from moving between terminals according to which one has new output. Human approval at predefined checkpoints, audit trails, and scoped credentials also keep autonomy bounded. These controls are part of the workflow’s design.

The disciplined scaling path starts with a single well-configured agent on clearly scoped tasks. Measurement then establishes what ships, what fails, and where time is lost before a review agent or parallel implementation is added. Teams that parallelize well know where their single-agent ceiling sits because they measure each agent’s contribution, rather than firing up four sessions simply because they can.