Multi-agent orchestration for coding agents: how teams run a fleet
Published September 9, 2026
Summary
Running coding agents in parallel requires a queue, an isolation boundary, a reproducible environment, a review gate, and a merge strategy. This guide compares the common ways teams build and operate a fleet.
From one agent to many
What multi-agent orchestration means for coding
The phrase describes two different setups. Inside one task, a lead agent delegates to subagents such as a planner, coder, and reviewer. Across a codebase, independent agents take tasks from a queue, work in isolation, and return pull requests. This guide covers the second setup.
A coding-agent fleet needs five parts, whether you build or buy it.
- A queue with clear task boundaries
- Tickets, Slack requests, schedules, or CI events become tasks with a definition of done. Parallelism only pays when tasks have low semantic overlap; twenty agents that all touch the same migration file have moved the bottleneck to the merge.
- An isolation boundary per task
- A worktree separates files. A container also separates processes. A VM adds a kernel and compute boundary. Credentials need their own scope and access controls regardless of the runtime boundary.
- A reproducible environment
- Every agent should start with the same dependencies, tools, secrets, and instructions. Fleets fall apart when each run depends on whatever was on one engineer's machine.
- A verification gate that is not the implementer
- Run tests and CI, then have a person or a separate agent review the change. An agent should not grade its own work.
- A merge strategy
- Use small independent branches, detect conflicts before merge, and order tasks that depend on each other. One task, one workspace, and one pull request is a simple default.
The core decision
Worktrees, tmux sessions, containers, or a VM per agent
Worktrees, tmux sessions, containers, and VMs draw different boundaries between agents and the systems they can reach.
- Worktrees work well when each engineer has enough local capacity. Teams can standardize that setup, but worktrees alone do not provide runtime isolation, shared provisioning, or centralized access controls.
- tmux is a visibility layer, not an isolation layer. It is how terminal-based orchestrators let you flip between agents; it changes nothing about what those agents can touch.
- Containers separate processes and files while sharing the host kernel. VMs add a kernel boundary, which matters when the code or workload needs stronger separation from the host.
- Managed VMs remove the local host as the capacity limit. Plan limits, startup time, cost, and review throughput still determine how far a fleet can scale.
| Model | What is isolated | What is shared | Ceiling in practice | Typical of |
|---|---|---|---|---|
| Git worktree per agent | Files and branch | Machine, credentials, CPU, network | A few agents per engineer | Claude Code worktrees and /batch, Phasr, wta, rookery, AGX |
| tmux session per agent | Terminal and process view | Everything a worktree shares | A few agents, with better visibility | Terminal orchestrators layered on worktrees |
| Container per task | Process tree and filesystem | Host kernel, often the host network | Bound by host capacity and the scheduler | Codex cloud tasks, Coder templates, self-hosted OpenHands, custom CI-based fleets |
| VM per task | Kernel, filesystem, processes, compute | Credential accounts can remain user- or organization-scoped | Bound by plan and available capacity | Replicas, Cursor Cloud Agents, Devin, Jules |
The landscape
Three ways teams run a fleet of coding agents
The way a fleet is built determines how a team operates it. This section groups products by that choice and compares the trade-offs. Product details change quickly, so confirm specifics with each vendor.
| Approach | Isolation | Who owns the queue | Harness choice | Best for |
|---|---|---|---|---|
| Git worktrees on one machine | One worktree and branch per agent, shared machine and credentials | You, a shell script, or Claude Code /batch | Claude Code natively; any CLI agent with a script | One engineer running a handful of agents on their own laptop |
| Harness-native cloud tasks | A vendor-managed container or VM per task | The vendor's task list and supported integrations | One harness each: Codex, Claude Code web, Cursor Cloud Agents, Copilot coding agent, Jules | Teams that want background tasks within a coding product they already use |
| Cloud coding agent platforms | Managed environments for delegated tasks | Team tasks from issues, chat, integrations, or an API, depending on the product | Replicas and Tembo offer multiple harnesses; Devin and Factory provide their own agents | Teams delegating implementation, testing, and pull requests with shared oversight |
Git worktrees on one machine: good for a few agents on one laptop
A Git worktree gives each agent its own checkout and branch inside the same repository, so three agents can edit three features without overwriting each other's files. Claude Code supports this directly: use the worktree flag or set worktree isolation for subagents. Its /batch command can split a migration across worktree agents, with each agent testing its changes and opening a pull request. Open-source desktop and terminal orchestrators such as Phasr, wta, rookery, and AGX wrap the same pattern with a task board, a tmux session per agent, and a merge queue.
Worktrees separate files but leave agents on the same machine with the same SSH keys, cloud credentials, CPU, and memory. Ten agents running test suites will fight for the same cores, and a destructive command runs with your permissions. They work well for file conflicts on one machine; they do not provide runtime isolation or more capacity.
Harness-native cloud tasks: easiest way to get agents off laptops, one vendor at a time
OpenAI Codex, Anthropic's Claude Code on the web, Cursor Cloud Agents, GitHub Copilot's coding agent, and Google Jules each run a task in an isolated environment the vendor owns and hand back a pull request. You can queue several at once from the product's UI or by assigning issues, so this is genuinely asynchronous, multi-task work with no machines to run.
Environment setup, triggers, analytics, and task ownership differ by vendor. A team using Codex for one class of work and Claude Code for another has two fleets, two configurations, and two places to look.
Cloud coding agent platforms: delegate engineering work and review the results
Replicas, Devin, Factory, and Tembo compete for the same job: take a software task, work on the repository, run checks, and return changes for review. Compare how each handles your backlog, environment setup, review, and integrations before choosing a platform.
Replicas runs delegated work in Linux VMs prepared with the team's repositories, dependencies, tools, and instructions. Tasks can start from Slack, Linear, GitHub, GitLab, schedules, webhooks, or the API. Engineers can inspect and steer the work, review test output, and continue from feedback. Teams can use one coding agent throughout or choose Claude Code, Codex, Cursor, OpenCode, and other supported harnesses per task.
Devin provides a packaged workflow around its own agent, while Factory provides Droid with selectable models and custom-model support on supported surfaces. Tembo also offers multiple coding harnesses, including Claude Code and Codex. Model choice and harness choice are separate decisions: compare the actual workflow and supported integrations rather than assuming one product is the only flexible option.
A managed platform adds service costs, account permissions, and environment configuration to evaluate. A team already well served by local worktrees or one provider's cloud tasks may not need another platform. For Replicas, VMs separate task runtimes; connected credentials can still be user- or organization-scoped, so access controls need a separate review.
In production
Patterns to plan for
A fleet makes execution easier to parallelize, while task selection, review, and merge order become the constraints.
- Scheduled work can create large bursts
- Recurring reviews, tests, migrations, and maintenance jobs can start many tasks at once. Set concurrency and spending limits before the first large schedule runs.
- Start with a few agents, not a swarm
- Start with independent backlog tasks and add concurrency as the review process catches up. A large fleet does not help when every change waits on the same reviewer.
- One task, one workspace, one pull request
- Small, independent changes are easier to test, review, retry, and merge. Long sessions create larger diffs and make failures harder to isolate.
- Dispatch volume can outrun review capacity
- Track opened, reviewed, merged, and abandoned pull requests together. More dispatched tasks only help when the team can verify and merge the output.
- Each task source carries a different workload
- A Linear issue, Slack request, pull request comment, and scheduled job arrive with different context and review expectations. Measure outcomes by source before expanding a trigger.
- Decide whether agent choice matters to your team
- One agent may cover your workload well. If different tasks need different agents, compare platforms that let you change the harness without rebuilding the environment and task workflow.
If you build it
A reference architecture for a coding agent fleet
Worktrees, scripts, and managed platforms use the same basic loop.
- Select only tasks whose dependencies are satisfied, and write a machine-checkable definition of done for each one before an agent sees it.
- Create a fresh isolated environment per task: a worktree for file separation, or a VM when the task needs a kernel and compute boundary.
- Start the agent with the same environment definition every time: dependencies, credentials scoped as narrowly as the provider supports, instructions, and the tools it is allowed to call.
- Run tests and CI when the agent declares completion, then hand the branch to a reviewer that is not the implementer, human or agent.
- Detect conflicts before merge, merge approved branches in dependency order, and retire the environment once it stops running: destroy it, or archive it so a reviewer can wake it to answer a question. Treat agents as a pool of disposable workers, not as named developers with persistent state.
- Record, per task, who started it, from where, which harness and model ran, how long it took, what it cost, and whether it merged.
Evaluation
Questions to ask before you choose
Run the same five backlog tickets through each finalist, in parallel, with the same reviewer, and answer these while you do.
- What separates the files, processes, kernel, network, and compute used by two tasks? Separately, are credentials scoped to a run, a user, or the organization?
- Is the queue mine or the team's? Can a task start from Linear, Slack, GitHub, GitLab, or a schedule, or only from one person's UI?
- Can I run Claude Code for one task and Codex for the next without a second platform, and can I use existing subscriptions or API keys where the harness allows it?
- What does running fifty tasks at once cost me in setup, and what does it cost in money, separated into compute and inference?
- Where do I see, across the whole fleet, what ran, what merged, and what it cost per source and per engineer?
- What happens to the environment when the task ends, and what could an agent have reached while it was running?
FAQ
Fleet orchestration questions
Getting started with Replicas
Run your first fleet without building one
Connect a repository, define the environment once, pick Claude Code, Codex, Cursor, or OpenCode, and assign a few independent backlog tickets from the dashboard, Slack, or Linear. Each task runs in its own Linux VM, where the agent can implement changes, run checks, and open a pull request for your team to review.
For dedicated or self-hosted deployment, SCIM, audit logs, static egress IPs, and a security review, contact the enterprise team.