Answer
How should parallel coding-agent work be isolated?
Separate working directories and separate branches, so two runs cannot see each other's half-finished state.
Give each run its own working directory and its own branch. Two agents in one checkout will read each other's half-written files and reason from a combined state that was never valid.
The failure with shared state is not a merge conflict, which at least announces itself. It is that each run reads files the other is midway through changing and forms conclusions from a state that is not a valid version of anything. Tests fail for reasons unrelated to either change, one run reverts the other's edit while tidying, and both produce reports describing work that no longer exists as described.
Separate working directories solve this completely and cheaply. Each run gets its own checkout of the repository, its own branch, and its own build output. Nothing either does is visible to the other until it is committed and shared deliberately. This is the same arrangement two people would use without thinking about it, and the reason it is worth stating is that a single machine running two agents makes sharing the default.
The second requirement is separate build and test artefacts. Two runs sharing a build directory, a test database, a port or a cache will interfere in ways that are hard to attribute, because the symptom appears in one run and the cause is in the other. This is usually a configuration matter rather than a design one, and it is worth checking before concluding that parallel work is unreliable.
The third is division of the work itself. Isolation prevents interference and does not prevent duplication: two runs given overlapping tasks will each produce a solution, and both will be correct and incompatible. The division should follow the same rule as any decomposition — pieces that could be done in either order — and pieces with a dependency between them belong in sequence rather than in parallel however much time that appears to cost.
The fourth is planning where the work comes back together. Parallel work is only worth the arrangement if the integration is cheap, and integration is cheap when the pieces touch different files and share an interface agreed in advance. Agreeing that interface before the runs start is the whole of the coordination cost, and skipping it is how parallel work becomes two people reconciling incompatible designs.
It is worth saying that parallelism is often not the answer. Two sequential runs are simpler, produce a clean history, and avoid every problem above. The case for running in parallel is genuine independence plus enough work in each piece to be worth the setup, and a lot of work that looks parallel is a chain with the dependencies not yet noticed.
Two agents in one directory are not working in parallel, they are editing the same document over each other's shoulder.
Siddharth Sharma, Context Theory
Related questions
Can two agents work on the same branch if they touch different files?
They can, and the risk is not the files they intend to touch. Incidental changes, formatting, regenerated artefacts and any command that writes to a shared location will collide, and those are precisely the changes neither run mentions in its report. Separate branches cost nothing and remove the category.
How many parallel runs are practical?
The limit is nearly always review capacity rather than machine capacity. Producing four changes at once is only useful if four changes can be reviewed and integrated, and the usual outcome of exceeding that is a queue of stale branches that need rebasing against each other. Match the number to what can be absorbed.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Software | Shared working state causes each run to read files the other is midway through modifying, so conclusions are drawn from a combination that was never a valid version, which presents as unrelated test failures and reverted edits rather than as a conflict. | Running two agents in one checkout on separate tasks and comparing their reports against the resulting file state. |
| Workflow | Separate build outputs, test databases, ports and caches are required alongside separate checkouts, because interference through shared artefacts produces symptoms in one run whose cause lies in the other. | Checking whether the project's test setup uses a fixed port, path or database name. |
| Response | Isolation prevents interference but not duplication, so overlapping tasks produce two correct incompatible solutions, which makes the parallel division subject to the same independence test as any decomposition. | Checking whether each parallel piece could be completed without the output of another. |
| Procurement | Parallel work pays only where integration is cheap, which requires the pieces to touch different files and share an interface agreed before the runs start, and agreeing that interface is the entire coordination cost. | Comparing integration effort for parallel work with and without a pre-agreed interface. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one