Multi-Agent PRs: Branch Rules That Keep Reviews Sane

A multi-agent PR workflow works when each agent owns one branch → one PR, and merge authority stays with a human (or an explicit gate such as CODEOWNERS + required checks). Write down branch names, path ownership, and rebase rules so parallelism does not collapse into conflicts.

This post covers branches, review ownership, and conflict prevention only. No plan pricing, benchmark numbers, or personal anecdotes.

One branch per agent?

One-line answer: Give every agent a dedicated branch from a shared base, encode role/ticket/purpose in the name, and never let two agents push the same branch.

Pattern:

main
 └─ feat/TICKET-123-api-auth        ← agent-A only
 └─ feat/TICKET-123-ui-login        ← agent-B only
 └─ chore/TICKET-123-ci-cache       ← agent-C only

Naming examples: feat/<ticket>-<area>-<verb>, fix/<ticket>-<symptom>, chore/<ticket>-<tool>.

Put these into the agent brief (prompt, AGENTS.md, or rules):

  1. Base branch — usually main or integration/*; fetch origin/main before branching.
  2. Checkout only your branch — no commits on another agent’s branch.
  3. Path allowlist — e.g. edit src/api/** only; do not touch src/ui/**.
  4. PR size — keep the change reviewable (single concern).
  5. Force-push policy — forbid --force on shared branches; allow rewrite only on the agent’s private branch if the team agrees.

If several agents share one working tree, checkouts overwrite each other. Prefer separate worktrees (git worktree add) or per-agent clones/sandboxes. With Cursor Agent / CLI agents, pin the branch at session start.

Do not pack API + UI + CI into one PR. Mixed concerns blur review, revert, and ownership boundaries.

Who reviews?

One-line answer: Agents draft and self-check; humans (or CODEOWNERS + required checks) approve and merge. Agent-only Approve is how accidents ship.

RoleDoesDoes not
Author agentImplement on its branch, run tests, draft PR bodyPush straight to main, skip required review
Reviewer agent (optional)Summarize diff, flag missing tests/security checksFinal Approve in place of a human
Human / CODEOWNERSIntent, boundaries, secrets, data impact → ApproveRubber-stamp agent output
CIlint / test / build gatesProduct intent

Practical gates:

  1. PR template fields for scope / non-goals / how to test / risks — agent drafts, human edits.
  2. Require ≥1 reviewer and path CODEOWNERS.
  3. Protect main — no direct pushes; PR + status checks only.
  4. If you use a review agent, document one line: Approve is human-only.

Prefer line-level comments and have the author agent land follow-up commits that address them. Re-state the allowlist so drive-by refactors do not sneak in.

How do you prevent conflicts?

One-line answer: Split by path/layer, give shared files a single owner, and rebase/merge main often. When conflicts happen, one integrator (human or designated agent) resolves on one branch only.

Prevention checklist:

  1. Path ownership — e.g. api/ / web/ / infra/. Do not assign the same file to two agents.
  2. Shared-file lock — lockfiles, generated code, route tables, i18n catalogs have one owner. Land a short lock PR first if needed.
  3. Small vertical slices — schema + handler + tests beat “touch every layer sideways.”
  4. Sync cadence — fetch and rebase onto origin/main at start, mid-work, and before opening the PR. Put “rebase before PR” in the agent prompt.
  5. Merge order — land low-conflict or dependency PRs first (contract → implementation → UI is common).
  6. On conflict — do not tell an author agent to “merge the other branch and guess.” An integrator resolves against latest main and keeps the fix on one branch.

Useful deny-list lines for agents:

  • Do not commit/push to main
  • Do not edit outside the allowlist
  • Do not regenerate lockfiles/generated artifacts unless asked
  • Do not push to another agent’s PR branch
  • Do not open a PR with conflict markers left in place

Wrap-up

For multi-agent PRs, stick to per-agent branches + path boundaries, humans as the approval gate, and single ownership of shared files with frequent rebases. Tool names matter less than whether those rules are written down.

Sources