Cheatsheet: Multi-agent integration patterns

Voice anchor

Git stores snapshots. Every other command is just navigating those snapshots.

Pattern comparison table

Pattern	Remote setup	Best for	Tradeoff
Shared origin	One remote, all agents push to it	Default. Team workflows.	Agent branches visible on shared remote (clutter, weak isolation)
Per-agent fork	Each agent on its own remote	Untrusted agents, external contributors	More setup; slower iteration
Shared worktrees	No remote push until final	Fast solo iteration	No backup, no in-flight visibility

Shared-origin pattern commands

# Setup (from main repo)
git checkout main && git pull
git worktree add -b agent-N/feature ../agent-N main      # repeat per agent

# Each agent pushes when ready
cd ../agent-N
git push -u origin agent-N/feature

# Lead integrates
cd ~/projects/myrepo
git checkout -b integration/<name> main
git merge agent-1/feature
git merge agent-2/feature
# ... etc; run tests after each merge

# Final push
git checkout main
git merge integration/<name>
git push origin main

# Cleanup
git worktree remove ../agent-1
git branch -D agent-1/feature      # local
git push origin --delete agent-1/feature   # remote

Per-agent fork pattern commands

# Each agent works in its worktree, pushes to its OWN remote
cd ../agent-N
git remote add origin [email protected]:agents/agent-N.git
git push -u origin agent-N/feature

# Lead adds each fork as named remote
cd ~/projects/myrepo
git remote add agent-1 [email protected]:agents/agent-1.git
git fetch agent-1

git checkout -b integration/<name> main
git merge agent-1/agent-1/feature
# (the remote name + branch name; can be confusing, use --no-ff to keep merge commits)

Shared-worktrees pattern commands

# Setup
cd ~/projects/myrepo
git checkout main && git pull
git worktree add -b agent-N/feature ../agent-N main

# Agents work and commit LOCALLY (no push)

# Lead integrates LOCALLY
git checkout -b integration/<name> main
git merge agent-1/feature
# ... etc

# Only at the end:
git checkout main
git merge integration/<name>
git push origin main

Semantic-conflict checklist (for the lead’s diff review)

Before pushing, review git diff main..integration/<name> and look for:

• Renamed functions, classes, fields (does any branch call the OLD name?)
• Duplicate utilities (two agents adding similar functions?)
• Mismatched field names across model and consumers
• Migration ordering (do migrations need a specific sequence?)
• Subtle behavior changes (return type changes, error behavior changes)
• Shared constants / config changed by multiple agents
• Implicit assumptions (one agent relies on behavior another agent removed)

If any item is uncertain, dig in before pushing.

Pattern selection drill, model answers

1. Solo dev, 4 agents, 2-hour sprint: shared worktrees. Fast iteration, lead controls everything, no need for remote visibility.
2. 10-person team, one fleet at a time, want peer review: shared origin. Agent branches need to be on the shared remote so other engineers can review them.
3. External AI services provider, untrusted code: per-agent fork. Quarantines the work; the team’s main remote is protected.
4. Startup founder runs nightly fleets, others inspect in the morning: shared origin. Agent branches need to be on the shared remote for morning review.
5. OSS maintainer accepting AI-assisted PRs: per-agent fork. Matches the existing OSS workflow.

Semantic-conflict spotting drill, model answers

1. Rename conflict. Agent A renamed; Agent B calls the old name. Catch via integration tests OR by spotting the rename in the diff review.
2. Mismatched field names. Agent A’s model field doesn’t match Agent B’s endpoint field. Catch via integration tests that exercise the endpoint OR by reading the diff for naming consistency.
3. Migration ordering. Each migration is fine alone; together, order matters. Catch via the lead-stage build that runs all migrations in order. Or by an explicit “list all migrations being added” check in the diff review.
4. Duplicate utility. Two functions doing the same thing. Catch via diff review or via lint rules that flag duplicate logic.
5. Implicit nullness. Return type changed; consumer doesn’t handle the new None case. Catch via type checking (mypy, TypeScript), via integration tests that exercise the None branch, or via diff review.

Mock fleet integration drill, model walk-through

After the deliberate semantic conflict (renaming add to sum_two on one branch), tests will fail. The lead’s job:

1. Read the test output. Identify the missing function name.
2. git diff main..integration to see what each agent contributed.
3. Spot the naming mismatch.
4. Fix: pick one name as canonical. Update the calls (or rename the definition).
5. Commit the integration fix.
6. Tests pass.

This is the canonical semantic-conflict-and-recovery pattern. Most multi-agent integrations include at least one of these.

Common mistakes and fixes

Mistake	Fix
No build gate at integration	Add the lead-stage build. Non-negotiable.
Loose agent scope (lots of overlap)	Refine scope upstream; prefer non-overlapping agent assignments
Skipping the diff review before push	Add it to the workflow. It catches what tests miss.
Hand-repairing confused agents instead of re-running	When in doubt, abort and re-run with a refined prompt
No process documentation	Write down the workflow. Onboard new leads to it.
Treating all 3 patterns as interchangeable	Use the decision tree. Each has clear best-fit situations.

What’s in L15

AI-authored commits and PRs. Co-authorship conventions (“Co-Authored-By: Claude Opus 4.7”). The “Generated with Claude Code” trailer line. What human review changes when an AI typed the code. Release notes treatment. How “human-authored” vs “AI-assisted” is communicated.