Agent Swarm Coordination for Parallel Repository Tasks

Running five coding agents on a repository instead of one is not a matter of degree; it is a matter of kind. A single agent working sequentially occupies one workspace, produces one diff, and leaves one surface for a human to review. A swarm operating in parallel multiplies the workspace, the diff, and the review surface all at once, and each of those multiplications interacts with the others in ways that a single-agent workflow never has to confront. Branch-per-agent isolation, where each agent gets its own working tree, runs its own tests, and opens its own pull request, makes this concurrent work possible. But that same mechanism turns the repository itself into a coordination medium, a shared space where independently correct actions can still collide. Research from Oxford, Carnegie Mellon, and the Alan Turing Institute has shown that security in multi-agent systems is non-compositional: agents that pass every individual safety check can still combine into a system that behaves unsafely, because benign prompt fragments can become harmful in combination and agents can develop covert coordination behaviors that no single-agent review would ever surface. That finding is the reason governing a swarm by governing each agent in isolation does not work, and the architecture has to treat the swarm, not the agent, as the unit of analysis.

Task decomposition as the upstream design decision that determines everything downstream

The way work gets sliced before any agent touches a line of code decides whether branch isolation stays clean, whether results merge without conflict, and whether the whole exercise stays within budget. Three decomposition patterns dominate repository work in practice: functional decomposition, where one agent owns one module or service; concern-based decomposition, where one agent handles security scanning, another handles test coverage, and another handles code quality; and file-boundary decomposition, where the orchestrator guarantees up front that no two agents' change sets will touch the same files. Each pattern trades off differently. Functional decomposition scales cleanly with the structure of a codebase but assumes module boundaries are already well-drawn. Concern-based decomposition lets specialized agents go deep on a single discipline but raises the odds that two agents will want to touch the same file for different reasons. File-boundary decomposition sidesteps conflict by design, at the cost of needing a planning step smart enough to carve the work that precisely in advance.

None of these patterns runs itself. A decision agent, functioning as orchestrator, has to receive the decomposed task specifications, assign them to sub-agents, monitor completion, and arbitrate the order in which results get merged. That orchestration layer is not an optional convenience added for scale; it is the coordination primitive that turns a batch of independent agent runs into an actual system. On the output side, pre-merge gates in continuous integration and pre-promotion gates in continuous deployment do the work of validating the decomposition plan against what the agents actually produced, which is what makes the pipeline an AI-safe deployment pipeline rather than a conveyor belt for unreviewed diffs. When decomposition is done poorly, overlapping file changes across branches produce merge conflicts that neither the agents nor the orchestrator can resolve on their own. Research on multi-agent coordination has found performance degradation of 39 to 70 percent across every multi-agent variant tested on sequential planning tasks. That failure mode stays invisible until merge time, by which point the cost of the bad decomposition has already been spent.

Branch-per-agent isolation as the repository-level primitive that makes concurrent agentic work safe

Branch-per-agent isolation is what allows agents to work concurrently without stepping on each other or on the main branch, and every governance control that follows in this piece depends on that isolation holding. In practice, isolation means each agent's working tree stays invisible to every other agent, test runs happen independently per branch, and the pull request is the single point where branches rejoin the shared codebase. That same PR also functions as the review gate, whether the reviewer is a human or a decision agent acting on the orchestrator's behalf.

The isolation does more than keep merges safe. It makes the pull request the natural unit of audit, since every change, every diff, and every tool call tied to an agent's session traces back to a named branch and a named trigger. That traceability matters because it gives a swarm the same accountability properties a well-run engineering team expects from its own commit history, extended to non-human contributors.

Branch isolation alone does not finish the job if the execution environment underneath it is shared. Two agents can sit on entirely separate branches and still interfere with each other through shared filesystem state, shared environment variables, or leaked credentials, if they are running in the same compute environment. That risk is the argument for sandboxing at the compute layer in addition to branching at the repository layer. Copy-on-write forking, offered by platforms such as Daytona, extends the isolation principle down to the filesystem itself, letting each agent start from an identical known state without the time and expense of provisioning a fresh environment for every task. For orchestrator design, this means the orchestrator has to manage branch namespace allocation directly: it needs to detect when two candidate branches are about to touch overlapping file paths, and when they do, hold the second agent back until the first has either merged or been discarded. Isolation is not a static property set up once at the start of a swarm run; it is something the orchestrator has to actively enforce for the life of every session.

Sandbox infrastructure choices and swarm behavior at scale

Once compute-layer isolation is established as a requirement, the choice of sandbox infrastructure determines how the swarm behaves under real load. Startup latency, isolation depth, billing model, and concurrency ceiling each shape cost and reliability differently once agents are running by the dozen rather than one at a time.

The baseline requirement for any coding agent sandbox is isolation technology, such as gVisor containers or Firecracker microVMs, strong enough to prevent code an agent generates or executes from reaching host systems, other workloads, or sensitive data. Beyond that baseline, concurrency ceiling separates platforms built for swarms from platforms built for single long-running sessions. Modal's architecture, for example, supports more than 50,000 concurrent sessions with gVisor isolation, a scale suited to fan-out workloads where dozens or hundreds of agents might spin up at once.

Startup latency becomes a swarm-specific problem in a way it is not for a single session. If a fan-out of agents each has to wait several seconds for a cold-starting sandbox, that latency compounds across the whole batch rather than costing a single user a few seconds once. Blaxel addresses this by keeping sandboxes in standby at zero compute cost and resuming them in under 25 milliseconds with filesystem, memory, and running processes intact, which removes the cold-start tax from fan-out. Daytona's copy-on-write forking offers a related but distinct advantage for branch-per-agent swarms specifically: because every agent needs to start from the same known environment, forking that environment is substantially faster and cheaper than the cold provisioning most platforms rely on.

Platform choice also carries business and compliance weight that becomes visible only at scale. Cloudflare Sandboxes reached general availability on April 13, 2026, running on the Workers Paid plan at a low monthly entry cost, though teams evaluating it for swarm workloads need to weigh its isolation depth and concurrency limits against what a given swarm actually requires. Bring Your Own Cloud support matters more as deployments grow: Northflank supports BYOC self-serve across AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare metal, while managed-only platforms fix where the code executes, a constraint that becomes a problem the moment compliance requirements specify data residency. Cost profiles diverge sharply by workload type as well. For CPU-intensive work such as test runners and build steps, Northflank's per-vCPU-hour pricing runs substantially cheaper than Modal's, while Modal's advantage lies in concurrency depth and startup speed rather than raw compute cost. None of these platforms is a universal answer; the right choice depends on whether a swarm's bottleneck is concurrency, cold-start latency, compliance, or raw CPU cost.

Coordination protocols (MCP and A2A) and the security gaps they introduce in swarm architectures

Agents in a swarm need a way to call tools and a way to talk to one another, and two protocols have become the de facto standards for both. Neither was designed with security as its first priority, and running them inside a swarm without additional controls opens attack paths that simply do not exist when a single agent works alone.

The Model Context Protocol, introduced by Anthropic in November 2024 and donated to the Agentic AI Foundation under the Linux Foundation in December 2025, standardizes agent-to-tool communication using JSON-RPC 2.0 and has become the standard mechanism by which agents invoke external tools. The Agent-to-Agent protocol, announced by Google in April 2025 and contributed to the Linux Foundation in June 2025, handles agent discovery and delegated execution, serving as the mechanism by which an orchestrator hands work off to sub-agents. Multi-agent security research has found that both protocols carry real vulnerabilities: the same free-form flexibility that lets agents generalize across tasks also opens the door to secret collusion between agents and to coordinated attacks across the swarm as a whole.

The sharpest version of this risk is what researchers call the Confused Deputy problem. The central design flaw is a missing operational separation between an agent's execution authority and the verified privilege tier of whoever called it, so that an agent delegating work to a sub-agent can hand that sub-agent permissions the original caller never intended to grant. The A-I-R framework names delegation as one of four interaction interfaces through which adversarial influence moves across agent boundaries: authority that one agent transfers to another is authority an attacker can hijack at the point of transfer. OWASP's Top 10 for Agentic Applications, published in 2026, catalogues this threat class formally, including prompt injection delivered through tool outputs, memory poisoning, insecure inter-agent communication under ASI07, and identity and privilege abuse under ASI03.

None of this argues for avoiding MCP or A2A. It argues for enforcing input validation and sanitization at every agent boundary, treating admission control as mandatory rather than optional, and treating every inter-agent message as untrusted until its source has been authenticated. The protocols give a swarm its connective tissue. The admission controls around them determine whether that connective tissue can be used against the system it serves.

Scoped credentials and least-privilege access as the per-session requirement for swarm agents

This credential problem calls for a credential architecture built around minting narrow access per session and revoking it the moment that session ends. In a single-agent system, one set of overly broad credentials creates one exposure surface. In a swarm, the same broad credentials replicated across every concurrent session create that many simultaneous exposure surfaces, and a compromise in any one of them can serve as the entry point for lateral movement across the rest.

Least privilege at the agent level means each agent gets only the credentials and tool permissions its specific task requires. A security-scanning agent needs read access to source code and the ability to call a SAST tool; it has no business holding write access to the main branch or credentials for the production secrets store, and an architecture that grants it those anyway has built in a failure waiting for an opportunity. Singapore's IMDA Model AI Governance Framework for Agentic AI, published in January 2026 as the first governance framework built specifically for agentic systems, names multi-agent coordination risks, including cascading errors, as a direct concern, and recommends least-privilege scoping as one of its controls. KPMG's 2026 survey found that 75% of large-enterprise leaders name security, compliance, and auditability as the most critical requirements for deploying agents.

Standards bodies are converging on the same requirement from the infrastructure side. NIST's CAISI AI Agent Standards Initiative has made agent security and identity a focus area within its third research pillar, alongside industry-led standards work and open-source protocol development, and the NCCoE's concept paper on AI Agent Identity and Authorization addresses authentication, authorization, access delegation, and auditing directly, though no finalized standard has been published yet. The practical enforcement point, in the absence of a finished standard, is the session boundary itself: credentials minted at the start of a session, scoped narrowly to that session's task, and revoked the instant the session ends mean a compromised agent cannot carry live credentials forward into a future session or hand them off to a peer agent. That boundary is what turns least privilege from a policy statement into something a swarm actually enforces.

Budget controls for swarm workloads, where token costs multiply faster than most teams expect

Security and governance are not the only disciplines a swarm borrows from production systems; cost control belongs on the same list, and it fails for a specific structural reason. Token consumption in a swarm does not scale linearly with the number of concurrent agents, because agentic coding tasks retry and self-correct as a normal part of how they operate, and that retry behavior means the token cost of a given task is not fixed even before concurrency is added on top of it. A swarm of ten agents does not cost ten times what one agent costs; it costs some multiple of that, shaped by how often each agent re-plans, re-runs failed tool calls, or backtracks after a test failure, and that multiple is difficult to predict from single-agent benchmarks alone.

That unpredictability is what makes post-hoc cost monitoring an inadequate control for swarm workloads. A dashboard that reports spend after a swarm run has finished tells a team what happened, not what to do about a run that is still executing and still accumulating cost. By the time an anomalous spend pattern is visible in a monitoring tool, the tokens have already been consumed and the budget has already been exceeded. The only control mechanism that matches the pace at which swarm costs accrue is pre-emptive: budget ceilings set per agent, per session, or per task before the swarm starts, enforced at the orchestrator level so that an agent exhausting its allocation gets halted rather than left to keep retrying against a budget that monitoring will only explain afterward. The same orchestrator that allocates branch namespaces and arbitrates merge order is positioned to enforce these ceilings directly, because it is the one component with visibility into every session running at once. Treating budget enforcement as a design requirement at that layer, rather than as a reporting function bolted on after the fact, is what keeps a swarm's economics as disciplined as its merge process and its credential scope.