Anthropic recommends a git worktree per agent. Your runtime infra makes that a problem.

Anthropic’s guidance shifts the unit of isolation from a branch to a full worktree. For engineers, this means every agent gets its own filesystem root, eliminating accidental overwrites or race conditions when agents modify the same files. The trade-off is that worktrees are heavier than branches; they consume more disk space and require explicit management of git metadata. Teams already using worktrees for other purposes may find this easier to adopt, but those relying on simpler branch-based workflows will need to adjust their mental model and tooling.

Runtime infrastructure becomes the bottleneck. Build systems, test runners, and deployment scripts typically assume a single working directory per repository. Supporting multiple worktrees in parallel demands either duplicating these tools or rewriting them to accept a worktree path as a parameter. Local development environments face similar challenges: IDEs, debuggers, and hot-reload tools must be configured to recognize and switch between worktrees without restarting. The cost of retooling is highest for monorepos, where the overhead of managing multiple worktrees scales with repository size.

The recommendation stops working when agents need to collaborate on the same files. If two agents must modify a shared configuration or lock a resource, the worktree isolation breaks down. Additionally, worktrees are not a substitute for proper concurrency controls; they only prevent filesystem-level conflicts, not logical ones. Teams will still need coordination mechanisms, such as shared state stores or explicit merge steps, to handle inter-agent dependencies. Without these, the worktree pattern merely shifts the problem from file conflicts to integration failures.