Five subagents are working in parallel on different modules of the same repository. Without coordination, two agents modifying the same files would cause conflicts. What branching strategy best isolates each agent's work?

Agent-per-branch isolation is the standard pattern for parallel multi-agent work on a shared repository. Each agent works on its own dedicated branch, such as agent/auth-refactor or agent/payments-refactor, makes all its changes on that branch, and the orchestrator merges the branches after conflict detection and resolution. This provides complete isolation: agents cannot interfere with each other's in-progress work, each agent's output is independently reviewable as a pull request, and failures are scoped to the individual branch without affecting other agents.

The approach where all agents commit to the same feature branch in alphabetical order of their task IDs requires a serialization mechanism, eliminates the parallelism benefit, and creates complex ordering dependencies. Alphabetical order of task IDs provides no technical enforcement and will result in conflicts.

The approach where all agents commit directly to main, using timestamps to order their commits, violates branch protection rules in most repositories and makes it impossible to review, test, or reject individual agent contributions. If one agent introduces a regression, it is immediately in production history.

The approach where agents take turns using a GitHub Actions concurrency group to serialize all commits to the same branch eliminates parallel execution — only one agent can work at a time, which is the opposite of what the multi-agent architecture is designed to achieve. It also still creates a shared branch where all agents' changes mix together, making it impossible to isolate individual agent outputs.

Separate agent branches are the fundamental isolation primitive for parallel multi-agent work.