How to Run Multiple Coding Agents Without Collisions

How to Run Multiple Coding Agents Without Collisions

Run coding agents in parallel only when their file ownership, dependencies, environments, and integration order are explicit. Give each task an isolated branch and working tree, prevent shared side effects, and make one person or agent responsible for reviewing the combined result.

Parallelism is not the number of chats open at once. It is a change-management system.

Venture Step episode 111A shows the attraction and the risk. Dalton Anderson starts one task for a user-interface redesign and another for image-processing behavior. Both move while he records. He also notes that local agents can run over one another when they share a codebase.

A worktree helps with filesystem edits. It does not solve every collision.

Decide whether the tasks are actually independent

Two tasks are safe to parallelize when each can finish against the same starting commit and neither invalidates the other's assumptions.

Check more than filenames. A front-end task and an API task may both change a shared type, route contract, package dependency, environment variable, generated client, or integration test. Two database tasks may touch different migration files but depend on one schema order. Two agents may use separate Git branches while writing to the same development database.

Use an overlap table before starting.

If a task changes a contract another task needs, separate design from implementation. Agree on the contract first, commit it, then branch the independent implementations from that point.

Use branches and worktrees for file isolation

Git's worktree documentation says one repository can have a main working tree and additional linked working trees. Each linked worktree has its own checkout and metadata while sharing the repository's Git object data.

That makes worktrees a practical foundation for concurrent agents. Each agent receives a unique directory and branch. Changes do not appear in another agent's working files until they are deliberately integrated.

Git normally refuses to check out the same branch in two worktrees. Preserve that safeguard. One branch should have one active owner.

The exact commands below are an example. Choose names and paths that fit the repository.

1. Start from a clean, reviewed base commit. Record the commit identifier in both task specifications.

2. Create one branch and linked worktree for each task.

git worktree add ../project-ui -b agent/ui-refresh main
git worktree add ../project-image -b agent/image-processing main

3. Start each agent inside its assigned worktree. Its task should name the owned paths, forbidden paths, expected evidence, and stop conditions.

4. Keep each branch focused. Do not let an agent “help” by refactoring unrelated shared code unless the integrator revises the task boundary.

5. Commit validated changes on the task branch. Preserve the test output or handoff evidence that corresponds to that commit.

flowchart TD
    A["Reviewed base commit"] --> B["UI branch and worktree"]
    A --> C["Image branch and worktree"]
    B --> D["Task tests and handoff"]
    C --> E["Task tests and handoff"]
    D --> F["Integrator reviews first change"]
    E --> G["Rebase or update second change"]
    F --> H["Combined branch"]
    G --> H
    H --> I["Full build, tests, security, and runtime check"]

Isolation turns accidental overwrites into explicit integration work. It does not decide whether the two changes are semantically compatible.

Isolate everything outside Git

A linked worktree still shares external systems. Parallel agents can collide through database tables, container names, build caches, test accounts, service quotas, browser sessions, generated directories outside the checkout, and environment files.

Give each task a resource namespace. Use separate test databases or schemas when possible. Allocate distinct ports and container-project names. Keep temporary output inside the worktree. Do not share a browser profile that contains production sessions. Use scoped test credentials with limited permissions.

If the system cannot isolate a destructive external action, keep that action sequential. Applying migrations, changing infrastructure, modifying shared secrets, and publishing packages usually require an integration owner and a controlled environment.

OpenAI's current Codex worktree guide notes that worktrees share Git metadata but use separate checkouts. It also explains that setup files excluded from Git may need explicit handling. That is an important operational detail: an agent can have an isolated branch and still fail because its local environment is incomplete.

Anthropic's subagent documentation supports isolation: worktree for a subagent. Tool-provided isolation is useful, but the operator should still verify the base branch, worktree path, cleanup behavior, and external resources.

Assign ownership before the agents start

Every concurrent task needs a single owner. Ownership means the agent or person is responsible for the defined outcome, not merely allowed to edit anything that seems relevant.

The task specification should include the starting commit, the files or subsystem owned, acceptance criteria, required commands, prohibited actions, dependencies, and handoff format.

Shared files need a policy. A lockfile, API schema, routing table, or central registry may be owned by the integrator rather than either task agent. Each agent can report the change it needs without editing the shared file.

This can feel slower than opening five chats. It is faster than discovering that five branches changed the same foundation in incompatible ways.

Use dependency order at integration

Parallel implementation still ends in a sequence.

The integrator reviews one branch first, checks its diff and evidence, and incorporates it into the integration branch. The next task is updated against that result. Its agent or owner resolves conflicts with knowledge of the new base and reruns its checks.

Do not merge both branches because each passed independently. The combined code is a new state. It needs a full build, relevant unit and integration tests, type checks, security checks, and a runtime path that exercises the interface between the changes.

If one task changes a public contract, integrate it before its consumers. If a migration adds data required by application code, verify the deployment order and backward compatibility. If a package update changes the lockfile, let one owner reconcile the final dependency graph.

Preserve a handoff for each task

A useful agent handoff identifies the result, changed files, commands run, tests that passed or failed, unresolved risks, assumptions, and exact commit.

Screenshots can support a visual claim. They do not replace tests. A test result can support a behavior claim. It does not prove product correctness. The evidence should match the acceptance criteria.

The handoff should also state what the agent did not do. In episode 111A, the interface appeared successful while an evaluation request failed because of a timeout. A truthful handoff would preserve both facts.

Avoid summaries that say “all good” without naming the checks. The integrator needs enough detail to decide what can merge and what must return to the task owner.

Stop when parallelism increases uncertainty

Pause concurrent work when two agents begin editing the same central file, when one task changes an assumption used by another, when external state cannot be isolated, or when the integration owner cannot explain the combined dependency graph.

Also stop when the review queue grows faster than changes can be verified. Agent throughput has no value if unreviewed branches accumulate.

Security-sensitive changes deserve a lower concurrency threshold. Authentication, authorization, secrets, payment, infrastructure, and destructive data operations often benefit from a focused sequence and an independent review.

Google's analysis of agent-facing repository files is relevant here. Each agent may load instructions, hooks, runtime settings, or extensions that affect its behavior. Parallel workers multiply those trust paths. Pin and review the configuration given to each worker.

A practical operating loop

1. List candidate tasks and map file, contract, data, environment, dependency, and verification overlap.

2. Keep dependent work sequential until the shared contract is stable.

3. Create one branch and worktree per independent task from the same reviewed base.

4. Assign one owner, a narrow scope, acceptance criteria, and explicit external-resource limits to each task.

5. Run the agents with isolated test resources and no unnecessary production access.

6. Require a commit-specific handoff with diffs, commands, test results, failures, and assumptions.

7. Integrate in dependency order. Update later branches against the new integration state.

8. Run the combined verification suite and the real interaction between components.

9. Remove completed worktrees through the supported Git or tool workflow after the branches and evidence are safely retained.

The loop is intentionally conservative. Most failures in parallel agent work are not caused by insufficient generation speed. They come from ambiguous ownership and hidden shared state.

The standard for safe concurrency

Multiple agents are useful when each one reduces a bounded queue of work and returns evidence that an integrator can judge. They are dangerous when they create changes faster than anyone can understand the resulting system.

Start with two tasks, not fifteen. Prove that the ownership, isolation, handoff, and integration process works. Increase concurrency only when the review system remains clear.

Episode 111A shows why the technique is compelling. It also records the right warning: local workers can run over one another. Worktrees solve the visible file collision. Explicit contracts, isolated resources, and combined verification solve the larger problem.

For the context each worker should receive, continue to [[How to Structure Repository Instructions for Coding Agents]]. For Dalton's live experiment, read [[Vibe Coding Beyond the Context Window]].

Verification and disclosure

This guide was checked on July 27, 2026 against current Git worktree documentation, current OpenAI Codex worktree documentation, current Anthropic subagent documentation, Google's agent-security analysis, ECC 2.0.0 at commit 6a9f075, and the E111A transcript.

Tool isolation behavior, cleanup, branch defaults, and external-resource handling can change. Test the current workflow in a non-production repository before scaling concurrency. AI assisted with research organization and drafting; evidence boundaries and final editorial decisions remain Dalton Anderson's.