To run coding agents in parallel, give each one its own task and its own working copy of the code, usually a git worktree, then watch for the case that isolation does not solve: two agents deciding the same thing differently. Worktrees stop agents overwriting each other’s files. They do not stop duplicate or conflicting work.
What does running agents in parallel mean?
Several coding agents work on one repository at the same time, each on its own job: one on the endpoint, one on its tests, one on a bug. The gain is that three jobs take about as long as the longest one. The cost is that you now have three things to watch and merge.
What are the ways to do it?
| Approach | What you get | Where it falls short |
|---|---|---|
| Several terminals, one folder | Zero setup | Agents edit the same files, and you find out at merge time |
| A git worktree per agent | Each agent has its own checkout and branch, so file edits cannot collide | Setup per worktree, such as installing dependencies again; conflicts move to the merge |
| An app that manages worktrees | Worktrees created and cleaned up for you | Usually built for one person; check what it shows about overlap |
| One shared session | Every agent and person in one place, with each lane’s changes visible, and a worktree per agent if you choose | On one computer only one agent changes a folder at a time: a second joins in Plan or gets its own worktree. Lanes in separate copies get a warning when they change the same file |
What do worktrees not fix?
- Two agents fixing the same bug in different ways, each in its own clean copy.
- Two agents changing a shared interface, such as a function’s arguments, in different files. Nothing conflicts until the merge, or until the tests fail.
- The review. Three branches still need three reviews, and the riskiest change deserves the most attention.
- Usage limits. Three agents on one Claude or ChatGPT plan reach its limit sooner than one.
The rules in how to run multiple coding agents on one repo still apply: split by task, split by files where you can, and merge one at a time.
How does Friday show who is touching which files?
In a Friday session each agent works in its own lane, and Friday keeps track of which lane has changed which file. On one computer, only one agent can change a given folder at a time: a second agent joins in Plan, or gets its own worktree. When lanes working in separate copies change the same file, Friday warns you and says who else changed it and when.
The agents see it too. Friday tells each one to say which files it will change before it writes, and an agent that calls check_messages learns which of its files another agent is changing as well. Agents can also ask each other directly, as in the guide on how Claude Code and Codex talk to each other.
You can also give an agent its own worktree. Friday makes the copy on your machine, and the agent can edit without touching the files another agent holds. Because a folder takes one writer at a time on one computer, put each agent that edits in its own worktree and use the session to see all of them at once.
How do you set it up?
- Write each task so it names the files or folders it owns.
- Add each agent to the session and name its lane after its job, such as tests or endpoints.
- Start the agents, and keep one person as the driver of each.
- Watch the heads-up Friday gives when two lanes touch the same file. When it appears, ask one agent to finish first, then hand the work on.
- Review and merge one lane at a time, and run the tests between merges.
Or make one agent the lead and give it the goal. It splits the work into a task board and hands each task to the agent best placed for it.
When is a worktree-only tool enough?
If you work alone, a tool that creates a worktree per task and nothing else may be all you need. Orca, Synara and Orchestrator are built for that today, and our comparisons with Orca and Conductor say where each fits. Friday is for when other people need to see and steer the agents, or when you want the agents to share what they learn.