Skip to main content

Branch Strategy for Agents

When running parallel agents in isolated git worktrees, the merge strategy is a first-class parameter that determines safety, speed, and human involvement. Formalized by SandCastle; the underlying decision exists in any multi-agent worktree setup.

Three Strategies

Each agent works directly off main HEAD. No branch created.
  • Fastest — no merge step
  • Risky — file scope must be truly non-overlapping; any overlap causes conflicts
  • Appropriate for: tasks with clear, provably non-overlapping file scope (e.g., agents owning separate modules)

merge-to-head

Agent creates a branch, implements, auto-merges back to HEAD when verification passes.
  • Default for parallel work
  • Handles light merge conflicts automatically
  • Verification gate (tests + types) must pass before auto-merge
  • Appropriate for: standard parallel AFK implementation

branch

Agent creates a branch, stops. Human reviews diff and merges manually.
  • Maximum control — human sees everything before integration
  • Required when: changes affect shared interfaces, high-risk changes, uncertainty about scope
  • Matches Dangeresque’s mandatory human-merge gate philosophy

Decision Heuristic


Relation to Worktrees

Branch strategy is distinct from worktree isolation. Worktrees provide filesystem isolation during implementation — each agent works in its own checkout. Branch strategy determines what happens at merge time, after implementation completes. All three strategies can use worktree isolation during implementation. The branch parameter only affects the merge step.

Relation to Existing Wiki

  • SandCastle — formalizes this taxonomy as a first-class parameter
  • Dangeresque — implements the branch strategy (mandatory human-merge gate)
  • Agent Harness — worktree isolation as a harness component
  • Ralph Loop — the loop that branch strategy is embedded in
  • Verification Pipeline — verification runs before merge; strategy determines what follows