94 Commits in One Day: Multi-Agent Coding with Git Worktrees

One developer. Three client calls. Zero time in the code editor. 94 commits merged to main.

That's the result of running multiple AI coding agents in parallel. Each agent gets its own git worktree, its own tmux session, and a focused task. An orchestrator coordinates the work. Cron checks progress every 10 minutes. Three AI reviewers validate every PR.

The daily average: 50 commits. The fastest sprint: 7 PRs in 30 minutes.

Here's how the system works.

The Architecture

Two tiers. The orchestrator handles strategy and context. The coding agents handle implementation.

┌─────────────────────────────────────────────────────────────┐
│                     INPUT SOURCES                           │
│  Sentry Errors │ Support Tickets │ Meeting Notes            │
└─────────────────────────┬───────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                   ORCHESTRATOR (Zoe)                        │
│  Memory (Obsidian) │ Prod DB (read-only) │ Skills           │
└─────────────────────────┬───────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────┐
│              CODING AGENTS (parallel)                       │
│  Codex Agent 1 │ Codex Agent 2 │ Claude Code │ Gemini       │
└─────────────────────────┬───────────────────────────────────┘
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                    GITHUB CI/CD                             │
│  Lint → Typecheck → Tests → E2E → AI Reviewers (x3)        │
└─────────────────────────┬───────────────────────────────────┘
                          ▼
                    Pass? → Notify → Merge

The orchestrator never writes code. Coding agents never make business decisions. Clean separation.

Git Worktrees: The Key to Parallel Agents

Standard git workflow: one branch checked out at a time. Switch branches, lose context. Run multiple agents on the same repo, they fight over files.

Git worktrees solve this. Each worktree is a separate working directory linked to the same repository. Different branches, different directories, no conflicts.

# Create worktree for feature branch
git worktree add ../feat-custom-templates -b feat/custom-templates
cd ../feat-custom-templates && pnpm install

# Spawn agent in dedicated tmux session
tmux new-session -d -s "codex-templates" \
  -c "/path/to/feat-custom-templates" \
  "$HOME/.codex-agent/run-agent.sh"

Four agents running simultaneously. Four separate directories. Four branches progressing in parallel. No merge conflicts until PR time—and by then, the work is scoped to avoid overlap.

Choosing the Right Agent for Each Task

Different models excel at different work. Match the agent to the task.

The pattern that works: Gemini designs, Claude builds. Gemini outputs an HTML/CSS spec with visual decisions documented. Claude implements it. The handoff is explicit: a spec file in the worktree.

Monitoring: Cron Over Conversation

Watching terminals is expensive—both in time and in tokens. Polling agents via LLM burns context window for routine status checks.

The monitoring loop runs every 10 minutes via cron. Pure shell scripting. Zero LLM tokens.

#!/bin/bash
# check-agents.sh — runs every 10 min

# Check tmux sessions
tmux list-sessions 2>/dev/null | grep -E "codex-|claude-|gemini-"

# Check for open PRs on tracked branches
gh pr list --json number,headRefName,statusCheckRollup

# Check CI status
gh run list --limit 10 --json status,conclusion,headBranch

The script checks three things:

• Is the tmux session alive? Dead session means the agent finished or crashed.
• Is there an open PR? PR exists means work is ready for review.
• Did CI pass? Green checks mean it's merge-ready.

Alert only when something needs human attention. Otherwise: silence.

"I'm not watching terminals. The system tells me when to look."

Auto-Respawn with Rewritten Prompts

Agents fail. CI rejects the PR. A reviewer flags a critical issue. The standard approach: restart with the same prompt and hope.

The better approach: analyze the failure, rewrite the prompt, restart with new constraints.

Example: Codex fails to handle an edge case. The respawn prompt includes the failing test output and explicit instructions to address that case. The second attempt has context the first lacked.

Three AI Reviewers, Different Strengths

Single-model review misses things. Each model has blind spots. Running three reviewers in parallel catches different issues.

All three post comments directly on the PR. By the time a human reviews, the obvious issues are already documented.

The Screenshot Rule

New requirement: any PR that changes UI must include a screenshot in the description. No screenshot, CI fails.

This one rule cut review time dramatically. Visual changes are obvious in screenshots. Reading diff files to understand UI impact is slow. Looking at a picture takes seconds.

Human review drops to 5–10 minutes per PR. Many PRs get merged without reading the code—the screenshot shows everything that matters.

Task Registry

Track active agents in a JSON file. The monitoring script reads it. The orchestrator updates it.

{
  "id": "feat-custom-templates",
  "tmuxSession": "codex-templates",
  "agent": "codex",
  "description": "Custom email templates for...",
  "repo": "medialyst",
  "worktree": "feat-custom-templates",
  "branch": "feat/custom-templates",
  "startedAt": 1740268800000,
  "status": "running",
  "respawnCount": 0,
  "maxRespawns": 3,
  "notifyOnComplete": true
}

Clean up orphaned worktrees daily. Prune completed tasks from the registry. Keep the system tidy.

Mid-Task Redirection

tmux enables intervention without killing the agent. The agent going in the wrong direction? Send it new instructions.

# Redirect focus
tmux send-keys -t codex-templates "Stop. The schema changed. Focus on..."

# Inject context
tmux send-keys -t codex-templates "Additional constraint: the API must..."

No restart required. The agent incorporates the new context and continues. Saves the full prompt reload.

Why Orchestrator and Coder Stay Separate

Context windows are finite. Fill them with business context and there's no room for code patterns. Fill them with codebase knowledge and there's no room for customer priorities.

The orchestrator's context:

• Customer CRM data
• Meeting notes
• Competitor intelligence
• Past decisions and memory
• Business skills (marketing, research, writing)

The coding agent's context:

• Repository conventions (AGENTS.md)
• Design docs and API schemas
• Relevant source files
• Type definitions and test patterns
• The specific task prompt

Specialization through context, not through different models. Both run Claude or Codex. The difference is what fills the context window.

The Numbers

• Best day: 94 commits (3 client calls, never opened editor)
• Average: 50 commits/day
• Fastest: 7 PRs in 30 minutes
• GitHub contributions (year): 4,143

Speed matters. Speed converts leads into paying customers. Speed means shipping the fix the same day the bug is reported.

What This Means for Solo Operators

The pattern scales down. You don't need four agents to benefit.

Start with one agent in a worktree. Add the 10-minute cron check. Require screenshots for UI PRs. These three changes improve velocity even with a single coding agent.

The orchestrator pattern works for any AI assistant with tool access. OpenClaw runs it. Other agent frameworks can implement similar coordination.

The core insight: don't make the coding agent hold business context, and don't make the orchestrator write code. Let each do what it does well.