How to split work across agents in parallel without collisions
Running AI agents in parallel saves time only when tasks are independent. How to split work by files and contracts, and how to integrate the results in order.
This page covers one concrete question: how to split the work so two agents do not collide. The tools that make it possible are explained elsewhere: folder isolation in git worktrees for agents, the agent that splits and gathers in orchestrator-worker, ways of organizing several model calls in multi-agent patterns, and agents that keep going while you do something else in background agents.
When does it make sense to parallelize?
The test is simple: can you write the assignments so that two agents do not need each other’s result to start? If yes, there is real parallelism. If one needs the other’s decision, they are steps in a row, and running them together only produces work to throw away.
Anthropic says this about its research system: most coding tasks involve fewer truly parallelizable parts than research does, and domains where all agents need the same context, or where agents have many dependencies on each other, are not a good fit for multi-agent systems today. The Claude Code agent teams documentation reaches the same conclusion: for sequential tasks, same-file edits or work with many dependencies, a single session or subagents are more effective.
These usually work well in parallel:
- Research: reading several sources or reviewing several modules without changing them.
- Separate modules: one agent adjusts the sign-up form while another updates the pricing page.
- Review and verification: one agent runs the tests while another checks accessibility on the same version.
These usually go wrong: refactoring a shared piece, changing data schemas, or editing the same routes or configuration file from several fronts.
How do you split the work so agents do not collide?
Before launching agents, draw an ownership map. It has three layers:
- By file or module. Each agent has a list of folders it may change. Anything outside its list it can read but not write. The Claude Code agent teams documentation puts it this way: two agents editing the same file overwrite each other, so each should own a different set of files.
- By contract. If two agents must agree on something (a field name, the shape of an endpoint’s response), write that contract first and give it to both. Augment Code asks that each task declare its file and interface boundaries and its integration points.
- By hotspot files. Augment uses that name for routing tables, configuration files and component registries, because many features interact with them. Its recommendation is a single-writer rule: only one agent (or one person) changes those files.
Task size matters too. The agent teams documentation prefers self-contained units that produce a clear deliverable, such as a function, a test file or a review. Too small, and coordination costs more than it saves; too large, and the agent works for a long time without anyone checking in.
What should each assignment contain?
Anthropic reports that, without detailed task descriptions, its agents duplicated work, left gaps or failed to find what was needed. For code, a useful assignment has five parts:
| Element | What it answers |
|---|---|
| Goal | What must be done, in one sentence |
| Owned files | Which folders or files it may change |
| Off-limits files | What it may read but not write (routes, configuration) |
| Contract | Names, formats or endpoints it must respect |
| Success criterion | Which test or check shows it is finished |
If you cannot fill that table in five lines, the task is not ready to parallelize. The same delegation pattern, seen from the agent that does the splitting, is in orchestrator-worker.
How do you isolate each agent?
The most used technical isolation is git worktrees: one folder and one branch per agent, with shared history. They stop two agents from overwriting the same file on disk. Claude Code, for example, creates them with claude --worktree <name>, and its documentation makes clear that not every parallel mode uses them: agent teams do not isolate their members in worktrees, which is why the split by files matters there.
Isolating folders does not prevent integration conflicts: if two branches touch the same line, Git flags it when merging. Nor does it isolate everything. Augment warns that local databases, Docker and caches stay shared unless you separate them explicitly, and that running commit, fetch or pull at the same time from several worktrees can corrupt shared metadata, so git operations should be serialized.
How do you integrate the results?
Integrate one branch at a time, and rebase the others onto the main branch each time. Augment proposes this to reduce surprise conflicts late in the sequence:
- Review the first branch’s diff and run its tests.
- Merge it into the main branch.
- Rebase the remaining branches onto the new base.
- Repeat with the next one.
Start with the shortest branch or the one that unblocks the most. And do not confuse “no conflicts” with “it works”: Git detects textual conflicts, not semantic ones. Augment gives the example of time zone handling that works in UTC but fails at daylight saving boundaries, an error that passes every automated check and shows up in production. That is why tests run at every integration and a person reviews what the tests cannot see.
How many agents should you run at once?
Few. Augment talks about 2 to 4 coding agents in parallel, and the agent teams documentation (an experimental feature, off by default) suggests starting with 3 to 5 teammates and warns that more agents bring more coordination, more chances of conflict and more tokens. For the person supervising, the load changes: instead of reviewing one large change you review several small ones and follow several lines of progress. A list showing each agent’s status, the files it touches and the branch where it lives helps more than three conversations mixed in one chat. Deciding who does what is covered in agent orchestration, and delegation inside a single session in subagents.
Example
Illustrative example: a team wants to ship a CSV export and, at the same time, improve a form’s error text. Agent A owns src/export/ and writes the function with its tests. Agent B owns src/forms/ and adjusts the messages. Neither touches src/routes.ts, a hotspot file with a single writer: a person changes it at the end, once the export exists. Before starting, the team wrote the contract: the export takes a list of rows and returns CSV text. B’s branch is integrated first because it is shorter; A’s branch is rebased onto the new base, the tests run, and only then does it merge.
Common mistakes
- Parallelizing tasks that depend on each other, then spending hours integrating.
- Letting two agents edit the same routes or configuration file.
- Piling up branches and merging them all together at the end of the day instead of integrating one at a time.
- Assuming “no conflicts” means “it works”, without tests at every integration.
- Forgetting shared resources: the same local database or the same development port.
- Launching more agents than you can review.
Sources
- How to Build a Multi-Agent AI System for Code Development (Augment Code, published March 2026)
- Run parallel sessions with worktrees (Claude Code documentation)
- Run agents in parallel (Claude Code documentation)
- Orchestrate teams of Claude Code sessions (Claude Code documentation)
- How we built our multi-agent research system (Anthropic Engineering)