Worktrees, review and races
Give every task its own git worktree so agents never edit the same files, review each task's diff, then merge it, open a pull request or send it back. Or race two or three agents and keep the best attempt.
When several agents work on one repository at once, they get in each other's way: one agent's half-finished change breaks another's tests. TaskWire can give each task its own copy of the code, show you exactly what each task changed, and let you merge only what you approve.
A copy of the code for each task
Edit the workspace and turn on Give each task its own copy of the code. It needs a project folder that's a git repository.
From then on, when an agent claims a task, it gets a git worktree of its own, on the branch taskwire/task-12 made from the default branch. Agents need no new instructions: the task's folder points at the worktree, and they work there.
- A released task keeps its worktree, so the next agent carries on with the same changes.
- A completed or deleted task loses its worktree once nothing in it is uncommitted. The branch always stays for review and merging.
- If git fails, the claim still stands and the agent works in the project folder as before.
Review what a task changed
Open a task in Review and its Changes section shows the diff. For a task with its own branch, that's everything since the branch left the default branch, plus anything not yet committed. For a task in a plain git folder, it's the folder's uncommitted changes. The files each agent read and changed are listed on the task too.
Then pick one:
- Approve and merge merges the task's branch into the default branch. TaskWire never forces anything. If the merge conflicts, it stops, leaves every branch as it was, and tells you which files clash.
- Open pull request pushes the branch and opens a pull request on GitHub, when the workspace's repository is on GitHub.
- Send back with a note on what needs to change. The task goes back to Pending, still reserved for the same agent, and your note goes in its thread so the agent sees it. Its branch keeps the work so far.
Merging and pull requests need the task's own branch, so turn on the copy per task first.
Race a task
Not sure which agent will do it best? Open a pending task and expand Race it: give it to 2 or 3 agents and keep the best. Pick the agents and a time limit (60 minutes unless you change it), and click Race.
Each agent gets its own copy of the task and its own worktree, even if the workspace doesn't usually use them, so they can't see each other's work. When they're done, the task shows the attempts side by side: how many files and lines each one changed, what it said about tests, the tokens it used (and about what they cost, for API-key models) and its result. Click Keep this one on the best. Its branch, log and result move onto the original task, which goes to Review as usual, and the other attempts are deleted with their branches.
Racing an API-key model against Claude Code is a cheap way to find out whether the cheaper model is good enough for a kind of task.