Parallel agents need a review workflow

Start with a dependency map

Suppose a documentation site needs a broken-link fix and a navigation-label change. They touch separate pages, so they are reasonable parallel tasks. If both require a new shared navigation API, settle that API first. Write down dependencies before launching agents; “work on the website” is too broad to review reliably.

Write a task contract

For the link task, identify the broken destination, the affected page and the existing link check. For navigation, identify the exact labels and pages that should change. Each agent needs the repository/worktree, allowed scope, expected result and stopping condition.

• Ask for a summary of changed files and checks run.
• Identify files or interfaces another task owns.
• Require disclosure of failed checks and unresolved questions.

Separate checkouts, not just panes

Two panes in the same directory still edit the same files. Give each independent editing task its own branch and worktree. Start the agent in that worktree and verify its current directory. Install dependencies using the project’s established workflow; avoid sharing writable build output just to save setup time.

git worktree add -b docs-links ../docs-links HEAD
git worktree add -b docs-nav ../docs-nav HEAD
git worktree list

• Git worktree reference
• Ubra worktree workflow

Review before integration

Inspect the diff and compare it with the task contract. An agent that reports “done” may have missed an edge case or changed an unrelated file. Run the relevant checks, then commit only the intended scope. Ubra places diffs, staging, commits and PR checks next to sessions; the reviewer still owns the decision.

Land changes in an explicit order

Land the link fix, update the navigation branch against that base, then retest. If the second task depends on the first, review that seam together. Avoid asking both sessions to resolve the same merge conflict simultaneously. Parallel execution saves time only if integration remains understandable.

Know when to stay sequential

Use one session for tightly coupled refactors, uncertain requirements or changes that need constant human judgment. Start another only when its scope and ownership are clear. Provider limits, CPU, memory and your review capacity are real constraints.

• Claude Code parallel sessions
• Codex parallel sessions
• Choosing a workspace