We get this question a lot: if four agents are working on the same codebase at the same time, how do you stop them from stepping on each other?
The honest answer is that we don't. We give each agent its own worktree.
What a worktree is
Git has had git worktree since 2015 and almost nobody uses it. It lets you check out additional branches into sibling directories that share the same .git folder. Same history, different working trees, different files on disk. The repo doesn't fork, it just spreads out.
For us this is the right primitive because:
- Each agent edits its own files. No file-level locks, no merge dance mid-task.
- History is shared. When an agent commits, the commit is immediately visible to every other worktree.
- PRs are real PRs. The branch lives in your origin remote like any other. No bespoke storage layer.
What it isn't
It isn't a sandbox. If two agents are told to edit Cargo.toml in conflicting ways, you'll still get a merge conflict at PR time. That's fine — that's the same conflict you would have had with two humans, and the same review will resolve it.
We tried sandboxes (containers, ephemeral file systems, copy-on-write trees) for about a week. The cost was that every change had to be lifted back into the real repo, which is exactly the boring, error-prone glue layer we're trying to avoid.
What you get
Run artichokey start and you get one terminal pane per agent, each in its own worktree, each on its own branch. The agents talk through a shared channel; they edit independently; they push commits when they're ready; PRs are opened against main like any human would.
Boring? A little. Boring is the goal.
Okey dokey.