Parallel work and race mode

Duplicating agents into twins, how the lead shares work between them, task dependencies, team awareness, a git working copy per task, and race mode.

Several agents can work on the same project at the same time. That is easy when their tasks have nothing to do with each other. It gets harder when two developers touch the same code, or when one step needs another step’s result. This page covers the tools Agentbits gives you for that: twins, work sharing, dependencies, team awareness, a separate git working copy per task, and race mode.

Duplicate an agent

To get two developers with the same skills, duplicate one. Open Organization → Agents, select the agent and click Duplicate. The twin gets the same role, job description, provider, permissions, teams, skills and access (connections, apps, files). It does not inherit the Lead switch.

Because the twin is in the same teams, it also works on the same projects right away.

How the work is shared

The lead sees how many open tasks each team member has, and spreads work across members with the same role instead of giving everything to one of them.

With Settings → General → Share work between twins on (the default), sharing also happens while the work runs: a free agent takes over a task queued for a busy twin. Twins are agents with the same role and the same expertise tags. The task thread gets a note that starts with “↔” and says who handed the task to whom. Tasks sent back with a review note stay with their own agent, because the note is meant for it.

Tasks that wait for each other

When the lead plans work that must happen in order, it can mark a task to start after another. The card then shows Waits for TA-n, and autopilot starts it only once those tasks are done. You can still start it yourself.

When a task that waited starts, the agent also gets the report summaries of the steps before it, so it knows what was already done.

Team awareness

At the start of each run an agent sees who else in the project is working right now, on which task and which files their run has written so far. It can check the live state again during the task with the team_status tool. Agents are told to avoid files a teammate is working on, and to keep the change small and mention it in their report if they must touch one.

If a second agent writes a file another agent is changing at the same moment, a warning appears in the agent’s transcript and in the task thread: “⚠️ file is also being changed by agent (task) right now”.

File information comes from Claude Code and Demo agents. Codex CLI and API agents don’t report which files they write.

Note: Awareness works through the prompt and a tool. It lowers the chance of agents overwriting each other but doesn’t prevent it. For real isolation, use a working copy per task.

A git working copy per task

For parallel developers, a project can give every task its own branch in a separate git working copy, so agents never overwrite each other. Turn on Each task in its own git working copy in the project settings (double-click the project tab). It is off by default.

The project folder must be the top of a git repository with at least one commit.
Each task runs on its own branch (agentbits/ta-…) in a copy inside the Agentbits data folder, not inside your project. The agent’s terminal shows “🌿 Own working copy on branch …”.
When the run succeeds, its changes are committed to that branch. If git can’t commit them (for example because of a commit signing setting), the task doesn’t go to review: it waits in To do with the reason, and the changes stay in its working copy.
When the task is Done (the lead approved it, or you moved it there), the branch is merged into the project folder. Until then, the project folder doesn’t change.
Tasks that wait for this one don’t start until its branch is merged; their cards say Waits for TA-n to be merged.
If the project folder has uncommitted changes, the merge waits. Commit or stash them, then click Merge now in the task.
If the merge conflicts, the task goes back to its agent, with the project’s latest state merged into its branch, to resolve the conflicts in its working copy.

It applies to Claude Code and Codex agents only. The copies don’t contain untracked files such as node_modules; an agent installs them if it needs them. Agentbits’ own git commands don’t run your repository’s hooks. If the folder isn’t a git repository with a commit, or the working copy can’t be prepared, the task doesn’t run in the shared folder: it is held with the reason. A working copy that still has uncommitted changes is never deleted.

Open a task to see What changed?: the files it changed, added and removed lines, and the diff — from its working copy, or from the merge once it is merged.

Agentbits only creates local branches, commits and merges. It doesn’t push to a remote or open pull requests.

Race mode

Race mode lets two members try the same task, and the lead keeps the better attempt. Turn it on in Settings → General → Race mode. It is off by default and costs about twice as much.

When a task starts for the first time, a copy also goes to a free member on another provider or model, for example a Claude Code agent and a Codex agent. A member on another kind of provider is preferred.
Both work on their own attempt. The cards show a Race badge.
When both are done, the lead compares them and keeps one. The winner is marked Won and moves on as usual; the other is marked Lost, closed, and its changes are discarded.

Some rules:

Lead review must be on, because the lead picks the winner.
In a project with a folder, Each task in its own git working copy must be on. Otherwise race mode is skipped for that task, since the two attempts would overwrite each other, and the task thread says why.
If no free member uses another provider or model, the task runs alone.
If the lead can’t pick a winner, both attempts wait in review for you.