The Concurrency Ceiling of Coding Agents

Why coding swarms stall at single-digit concurrency—and the runtime substrate required to make high-concurrency software work practical.

Agent swarms already work well for broad search, independent research, and information gathering. Coding is different: a worker has not succeeded when it produces a plausible local diff. It has succeeded only when its change fits a particular codebase head, passes the relevant tests, coexists with live services, and can be accepted into one integrated result.

That requirement creates the concurrency ceiling. To avoid agents overwriting one another, teams split a codebase into large disconnected tasks, give each worker a worktree, then ask a lead agent or human to reconcile the output. The more workers they add, the coarser the task boundaries usually become. Work that is actually connected—shared configuration, interfaces, tests, build files, and running services—gets postponed until integration.

CooperBench evaluates collaborative coding across more than 600 tasks and reports that collaborating agents achieved, on average, 30% lower success than one agent completing both tasks. Its diagnosis is not merely weaker models: communication is vague or mistimed, agents break commitments, and they carry incorrect expectations of one another's work. CooperBench

Worktrees stop one agent overwriting another's files. They do not reveal active work, coordinate a running service, or make integration cheap; coordination is deferred to merge time. Merge cost is not inherently O(2^n), but the possible interactions among concurrent changes can grow combinatorially and are discovered late. Real AI-authored pull requests show substantial conflict incidence, concentrated in source files and often structural rather than simple line edits. AgenticFlict

The bottleneck is therefore not just agent intelligence. It is the runtime substrate in which agents work.

This explains a familiar pattern in agent-team products. A coordinator can fan out several agents, but it usually assigns them broad, carefully separated slices: one investigates, one writes tests, one implements a component, one reviews. That is useful parallelism, yet it is not the same as letting fifty workers make fine-grained progress through one codebase. The coordinator is compensating for the absence of a shared execution substrate by keeping the workers apart.

The failure, demonstrated: ten agents, one feature set

Imagine ten coding agents building a checkout experience. One changes pricing rules, another adds express checkout, two build competing storefront previews, and the remaining workers add search, accessibility, tests, and integration checks.

The individual tasks are reasonable. The difficulty is that they are only mostly independent. Checkout needs the pricing contract. Accessibility touches the application shell that catalog work also changes. The test agent needs to see the eventual integrated route, not an old private copy. The preview agents both expect a familiar development port. In a real product, these dependencies appear continuously; they cannot all be removed during planning.

In a worktree-based team, every worker can report a local success while the system is already failing as a team:

1. All ten begin from the same old revision, but cannot see the relevant state of other active work.
2. Two preview servers try to bind port 4173 on the same machine; one fails, and neither worker has a runtime-level way to discover the owner or a safe endpoint.
3. Pricing and checkout independently edit the same shipping threshold. Both tests pass locally; the conflict is discovered only after one worker's work is merged.
4. A lead agent now needs to inspect diffs, decide merge order, repair the integration, re-run tests, and work out which agent created each side effect.

The problem is not that isolation is wrong. The problem is isolation without operational transparency.

In a runtime built for agent teams, the same demonstration should look different:

1. Ten workers start private copy-on-write sessions from one recorded base revision.
2. The control plane exposes task status, declared intent, active services, port leases, resource use, and published results—without exposing another worker's uncommitted files.
3. Isolated preview sessions can both bind port 4173, each receiving a distinct, discoverable endpoint.
4. The first shipping-threshold change publishes. The conflicting changeset is rejected as a whole; its unrelated checkout file does not leak into the shared result.
5. The rejected worker starts a fresh one-shot session from the new head, adapts its change, and retries. Integration tests run against the actual shared result, not a collection of optimistic local successes.

This is how a coding swarm becomes a runtime problem rather than a prompt-engineering problem: isolate uncertain work, expose the state that matters for coordination, and make integration an explicit system operation.

The missing abstraction: a shared workspace protocol

The answer is neither a shared writable directory nor a longer status update. A shared workspace protocol must divide state in two: private execution state—uncommitted files, commands, processes, and experiments—and public coordination state—task owner, base revision, declared intent, services and ports, resource budgets, test results, publish events, and handoffs.

This is the transparency missing from isolated worktrees. A worker never sees another worker's dirty directory, but it can see that an agent is modifying the checkout contract from R42, holds a preview endpoint, or has published a change that requires consumers to rebase. That is enough to wait, work elsewhere, coordinate an interface, or deliberately create a competing proposal.

Those facts should be typed, durable records rather than chat-only assertions. A port lease has an owner and lifetime; a publish result has a base, changed paths, conflict class, tests, and resulting head; a handoff names an artifact and acceptance condition.

What agent teams prove—and what their runtimes leave open

This is not an argument against agent teams. The products now shipping make a useful distinction: parallel research, review, and clearly independent modules are already productive; parallel, interdependent writes remain much harder.

Cognition's writing on Devin makes the tension especially clear. In 2025, its CPO argued that parallel writers fragment context and make conflicting implicit decisions; the article recommended preserving the full relevant context and treating long-running, single-threaded work as the reliable default. Don't Build Multi-Agents. In 2026, Cognition refined rather than abandoned that position: its production patterns use additional agents for review, consultation, and management, while the most reliable pattern keeps writes single-threaded. It also reports that cross-agent context transfer, state assumptions, and communication required dedicated engineering. Multi-Agents: What's Actually Working

That is a valuable challenge to this vision, not a reason to hide it. A COW runtime cannot make agents agree on architecture or prevent a poor task decomposition. It addresses a different, necessary failure mode: operational isolation without operational transparency. The substrate should give agents a common, typed view of bases, intents, resource leases, publishes, tests, and conflicts, so models have a dependable place to apply the context-sharing and synthesis that the products above require.

The ambition: make coding concurrency a systems problem

The long-term target is simple to state:

One machine should support hundreds of sandboxes. One sandbox should support tens—eventually hundreds—of coding agents.

That is worker capacity, not a promise of a literal 1,000× speedup. Dependencies, tests, host resources, shared services, and model latency still set the real limit. The runtime simply should not force agents into single-digit teams before the work does.

The point is not to let hundreds of agents edit the same directory. It is to make hundreds of private attempts cheap, observable, and safe to integrate.

1. Copy-on-write sessions over a shared project truth

An agent receives a private writable layer over an immutable project base. It can inspect, edit, build, and test without cloning the whole repository or seeing another agent's uncommitted changes.

When it finishes, the runtime captures the layer and attempts a conflict-aware merge into shared history. Disjoint changes can publish; compatible text can merge; a conflicting changeset is rejected atomically. Collaboration is grounded in base revisions, private deltas, and publish outcomes—not a claim in a message that another agent may misunderstand.

This changes the unit of collaboration. In a worktree flow, the unit is usually a branch-sized patch assembled after the fact. In a COW session flow, the unit is a bounded execution with an explicit base, a private delta, a publish contract, and a result. The runtime can make that result visible immediately: accepted, merged, rejected because a path changed, or held for review. A worker no longer has to guess whether “the other agent is done” means its code is running, tested, committed, merged, or merely described in chat.

The merge policy must stay conservative. Some paths—binary files, dependency manifests, generated output, or protected code—should reject or use a specialized resolver. The win is not eliminating every conflict; it is making failure early, typed, atomic, and actionable.

Ephemeral Sandbox already implements much of this runtime loop: LayerStack-backed shared history, private copy-on-write workspace sessions, publish-time resolution, and all-or-reject publication. Runtime architecture, capture and publish

2. Two useful lifetimes: one-shot and persistent

High concurrency needs two workspace lifetimes:

• One-shot sessions start from a known base, complete a bounded task, then publish or discard and exit.
• Persistent sessions stay alive for iterative debugging, development servers, exploration, or coordination; their publication policy must remain explicit.

The current Ephemeral Sandbox model already distinguishes an implicit publish_then_destroy path from explicit sessions whose lifecycle is separately controlled. That distinction should become a first-class product concept, not an implementation detail.

One-shot workers give the scheduler a clean unit for capacity, cleanup, and retry: failures discard private state instead of leaving a half-configured environment. Persistent sessions remain valuable, but should be scarce and intentional.

Workflows a real agent runtime should support

The substrate is only useful if it makes common engineering workflows safer and faster. These are not five prompts for a manager agent; they are repeatable protocols with explicit state transitions.

1. Map, contract, fan out, integrate

For a feature that spans several layers, begin with a short read-only mapping pass: agents identify callers, tests, configuration, compatibility risks, and likely file or symbol boundaries. A lead then publishes a small contract—for example, the checkout payload and acceptance tests—as durable coordination state. Implementation workers each receive a COW session at the same base. They declare their intended surface, publish narrow changes, and an integration lane validates each new shared head.

This keeps early parallelism where it is strongest—discovery—while allowing several writers to proceed once the important decisions are explicit. It is safer than pretending the plan has removed all dependencies.

2. Competing prototypes with a clean selection gate

Some questions should not be divided. Let three workers independently prototype a caching strategy, a new UI flow, or a parser design in isolated one-shot sessions. Each may run a development server on the same familiar port because the runtime gives each session a separate endpoint. An evaluation task compares declared metrics—test results, latency, accessibility checks, bundle size, or a human review—and selects one candidate to publish. The other layers are discarded.

This is productive redundancy, not a merge problem. The key is that prototypes are explicitly competing proposals, not accidental branches that somebody later tries to combine.

3. Fine-grained parallel implementation with early conflict recovery

Workers may overlap when the expected value exceeds the risk. The runtime records each session's base revision and declared intent. If the first change publishes and a later change conflicts, the later changeset is rejected atomically. The scheduler opens a replacement one-shot session at the new head, supplies the typed conflict result and relevant published delta, then asks that worker to adapt only its intended contribution.

The workflow is therefore attempt → publish or reject → rebase or escalate, rather than edit privately for an hour → discover an incompatible branch → manually untangle everything. Rejection is normal control flow, not an exceptional loss of state.

4. Persistent incident response with disposable repair workers

An outage is different from a bounded feature. A persistent coordinator session owns the incident timeline, live service references, decision log, and release criteria. It can create disposable COW workers to inspect logs, reproduce the failure, validate a suspected fix, or review a risky change. Port and service leases make the active environments discoverable; CPU and memory budgets prevent emergency debugging from destabilizing production-like test infrastructure.

Only evidence-backed fixes enter the integration lane. The persistent session preserves continuity; the short-lived workers keep experiments isolated and cheap to abandon.

5. Upgrade and compatibility matrices

Dependency upgrades, compiler changes, or platform migrations naturally fan out across a matrix: operating systems, language versions, packages, service boundaries, and test suites. One-shot workers run each cell against a recorded base and publish structured observations—pass, failure signature, affected path, resource use, and suggested repair. The scheduler groups equivalent failures, creates focused repair tasks, and re-runs only the affected cells after each accepted publish.

This is where high worker capacity is especially credible. The tasks have bounded inputs and clear verification, while the runtime prevents a large test matrix from becoming a pile of duplicate checkout directories and competing ad-hoc fixes.

3. A resource plane, not just filesystem isolation

Coding agents conflict over resources as often as files: two workers bind the same port, a test suite saturates CPU, or a runaway process slows every other worker. The runtime needs:

• namespace and network isolation when experiments need the same port;
• port leases and service discovery, so agents can find a running preview without guessing;
• CPU, memory, disk, and I/O budgets with admission control;
• telemetry tied to the task and workspace that consumed the resource.

Ephemeral Sandbox can already demonstrate the same-port case: shared-network sessions collide, while isolated network namespaces can each bind the same port independently. The next step is to make that fact discoverable to agents through a stable resource contract rather than a debugging surprise.

The scheduler should know whether a sandbox is CPU-, memory-, or I/O-bound, then delay or move suitable work. High concurrency without admission control is only a faster route to a noisy, flaky machine.

4. Integration must be scheduled and verified

Automatic merge alone is not enough. Integration lanes must test the new head, validate interface contracts, inspect risky diffs, and decide whether a rejected change should rebase, split, escalate, or be discarded:

1. Fan out cheap private work.
2. Publish only evidence-backed changes.
3. Validate the integrated head continuously.
4. Route conflicts to targeted retry, reviewer, or human approval.
5. Keep every decision attributable.

An integration lane can trigger after accepted publishes: build the new head, run affected tests, and classify the result. Green permits more fan-out; failure narrows admission and opens targeted repair tasks. Integration becomes a continuous feedback loop rather than a final ceremony.

The benchmark that matters

The vision is credible only if it is measured against the status quo. Compare worktrees, isolated sandboxes, and shared-base COW sessions across 1, 2, 5, 10, 50, and 100 coding workers. Measure task success, wall-clock time, accepted publish rate, conflict/retry rate, integration latency, storage and resource cost, test health, and human-review burden.

The benchmark should include overlapping interfaces, shared-port previews, long-running tests, dependency upgrades, flaky failures, and recovery after rejection. Measure conflict-discovery time, leaked changes after failed publish, rework after rebase, and required human intervention—not merely whether the final repository passes.

A ten-agent demo makes the mechanics visible. A serious runtime must then show where throughput improves, resource pressure begins, and human judgment remains necessary.

The claim should not be “more agents always win.” The claim is stronger and more useful: coding agents should be allowed to scale until the task's real dependencies, not a fragile workspace model, become the limit.

Sources and further reading

• CooperBench: Why Coding Agents Cannot Be Your Teammates Yet
• AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests on GitHub
• Codex subagents
• Claude Code Agent Teams
• Claude dynamic workflows
• Qoder Experts Mode
• Cursor 2.0 parallel agents
• Cognition: Don't Build Multi-Agents
• Cognition: Multi-Agents: What's Actually Working
• Ephemeral Sandbox architecture
• Ephemeral Sandbox: LayerStack and copy-on-write
• Ephemeral Sandbox: namespace runtime and isolation
• Ephemeral Sandbox: capture, resolve, and publish