You’re running 20 agents across VMs instead of writing code yourself? The key is not the number of agents; it is an operating model where people do not become the bottleneck even when twenty results arrive at once.
Design the human queue before launching 20 agents
The throughput of parallel agents is determined not by the number of running sessions, but by the number of results a person can assess. If five agents ask questions and submit test reports and PRs at the same time, coding time may shrink, but requirement clarification, prioritization, and conflict resolution all pile onto one person. Accounts of real-world parallel development also note that from three agents onward, reading and sorting results becomes a new bottleneck, while aligning requirements requires deep focus and is hard to parallelize.
So do not read “20 VMs” as “20× productivity.” First, split work into units that can be completed without a human response. A good ticket does more than state the goal. It includes the allowed scope of change, areas that must not be touched, completion criteria, validation commands to run, and the format for submitting results. If an agent needs to make a product decision midway through, the task is not ready to delegate.
What grows first when you add agents
Along with generation speed, questions, PRs, test logs, conflicts, and cost also grow. Before adding more sessions to a screen, decide “which results should reach a human?” Require raw failure logs, a change summary, risk level, and next action in a consistent format, and the review queue becomes far clearer.
An operations board should show work states rather than a list of sessions. At a minimum, distinguish queued · running · validation failed · human decision needed · ready to merge. Limit the conditions that notify people, too. Escalate only events that require a human decision—such as requirement conflicts, privilege expansion, repeated failures, or data migrations—and let agents address ordinary test failures first.
A VM is a boundary for limiting blast radius before it is a productivity tool
The purpose of giving each agent a VM or strong sandbox is isolation, not speed. Coding agents can modify files, run shell commands, and install packages. OpenAI explains that, because agents may operate with real user privileges, sandboxes that restrict file writes and network access at the operating-system level are necessary.
The simplest model is “one independent workspace per agent.” Use separate VMs or containers for different repositories; for independent tasks in the same repository, Git worktrees are also practical. According to the official Git documentation, you can attach multiple working trees to one repository and check out different branches simultaneously. A worktree reduces conflicts in Git state, however; it does not isolate host secrets or network access.
| Boundary | What it prevents | What remains |
|---|---|---|
| Branch | Separates change history and merge units | File conflicts in the same directory |
| Git worktree | Separates working directories and concurrent branch work | Shared host credentials, processes, and network |
| Container · sandbox | Restricts file and process access | Kernel and host resources may be shared depending on configuration |
| VM per agent | Strongly separates the operating system and work environment | Cost, image management, and credential-delivery design |
The important thing is not to copy long-lived credentials into the VM. Anthropic’s cloud approach isolates sessions, keeps Git credentials out of the sandbox, and uses a separate proxy to verify the repository and branch before attaching authentication to Git requests. Apply the same principle in your own environment: use repository-scoped read access, write access only to working branches, short-lived tokens, and a default-deny network.
File and network boundaries must be used together. Anthropic explains that isolating only files can still allow network privileges through another route, while isolating only the network can still expose sensitive files. It also reports that internal use of both boundaries reduced permission-confirmation prompts by 84%. That figure does not guarantee the same result in every environment, but it clearly points to designing enforceable boundaries instead of relying on repeated approvals.
Do not eliminate review; shift it from “reading code” to “checking evidence”
An agent saying “I ran the tests” is different from tests actually having run. WorkOS explains that merely instructing an agent to run tests allowed it to create files that looked like evidence. The solution was to change the workflow so the next step required actual test output as input.
A task’s deliverable should not end with a PR. At a minimum, require the reason for the change, modified files, commands run, raw test output or an artifact link, known risks, and rollback instructions. It is also better to separate the contexts of implementation and validation agents. If one session that shares the same misunderstanding creates both the implementation and tests, it can produce self-validating verification that perfectly passes an incorrect requirement.
Separate final merge authority from execution agents. GitHub protected branches can block merging until required status checks are successful, skipped, or neutral, and can be configured to recognize checks created only by a specific GitHub App. As PR volume grows, you can also enable a merge queue so that only changes which pass checks again on top of the latest default branch are merged in order.
People do not need to read every line of code with the same depth, but neither should every risk be automatically approved in the same way. Directly inspect code and queries for authentication, payments, permissions, data deletion, and migrations; review easily reversible changes, such as UI copy or internal tools, primarily through test results and previews. Like WorkOS’s separate reliability-validation period spanning 180 PRs for one internal agent, recurring automation itself should be treated as a product whose reliability is managed.
Build an operations board with two agents this week
- Split two tasks so they do not conflict.
Choose different repositories, or, within the same repository, choose two tasks whose primary files are unlikely to overlap. Put the goal, prohibited areas, completion criteria, validation commands, and risk rating in each ticket. - Separate each workspace and its permissions.
For low-risk practice, you can start with a separate worktree such asgit worktree add ../agent-a -b agent/a. If the agent must read external documents or execute arbitrary commands, use a separate VM·sandbox and do not attach your home directory or cloud keys. - Standardize the submission format.
Before finishing, have agents leave a PR link, a five-line change summary, commands run, test results, failed items, and rollback steps. Require CI logs or test artifacts instead of the sentence “everything passed.” - Enforce merge gates.
In GitHub’sSettings → Rules → Rulesetsor branch-protection settings, require PRs and status checks, and restrict direct pushes. Add human approval for high-risk changes, and do not give execution agents merge authority. - After a week, count interventions—not just output.
Alongside completed tasks, record the number of human questions, reruns, conflicts, review wait time, and post-merge reversions. If questions and wait time do not decline, do not add a third agent; fix the tickets and validation process first.
If you want to go deeper
Parallel AI Development: Lessons From a Few Thousand Dollars of Tokens — explains concretely why requirements, validation, and result classification return as human bottlenecks in parallel-agent work. atum.li
What we learned in six months of making AI the default at WorkOS — shows an operational case that enforced test execution as input evidence for the next step, rather than as a claim. workos.com
Beyond permission prompts: making Claude Code more secure and autonomous — official material for understanding file and network isolation and a restricted Git-authentication architecture. anthropic.com
Git - git-worktree Documentation — documents commands and cleanup methods for creating multiple independent working directories from the same repository. git-scm.com
About protected branches — official configuration documentation for controlling agent changes with required status checks, approvals, and a merge queue. docs.github.com
