That is not a highlight reel stat. That is what this system produces on a busy day. The average is 50 commits. The record is 94. And none of it required me to sit in a terminal babysitting an agent.

Most builders using Claude Code or Codex are treating them as the destination. They are not. They are workers. The unlock is building the layer above them: an orchestrator that holds your business context, writes precise prompts per task, routes work to the right model, monitors progress, and only surfaces PRs when they are actually ready to merge.

This is the full breakdown. The architecture, the reasoning behind every decision, the exact setup code, and an honest account of where this system breaks down.

Why Claude Code Alone Has a Ceiling

Here is the constraint nobody talks about clearly: context windows are zero-sum. Every token you give to business context is a token you cannot give to code. Every token you give to code is a token you cannot give to customer history, meeting notes, or the three failed approaches you tried last week.

When you use Claude Code or Codex directly, you are managing this tradeoff constantly. You paste in a bit of context about what the feature is for. You add some relevant code. You hope the model figures out the rest. It usually does fine on small tasks. It falls apart on anything that requires understanding why a feature matters, not just what it should do.

The solution is not a bigger context window. It is specialisation through separation. You need one AI that holds everything about your business and one AI that holds everything about your code. They talk to each other. You talk to the orchestrator. The orchestrator talks to the workers.

This is the two-tier architecture. OpenClaw is the orchestration layer. Codex and Claude Code are the workers. Here is exactly what each one knows:

The Full 8-Step Workflow

Here is the system end-to-end, using a real example: a customer on an agency plan requested a way to reuse configurations across their team. Here is exactly how that moves from customer call to merged PR without me touching the code.

The Setup Code

Here is the actual implementation. There are five pieces you need: the OpenClaw config, the agent spawn script, the monitoring cron, the task registry schema, and the review trigger. Start with OpenClaw installed and connected to Telegram, then layer these on top.

Step 1: Install OpenClaw and Configure Zoe

# Install globally (requires Node 22+)
npm install -g openclaw

# Run the onboarding wizard
openclaw onboard

# This configures your AI provider, links your Telegram channel,
# and installs the background gateway service.

Your OpenClaw config lives at ~/.openclaw/openclaw.json. Here is Zoe's configuration for this orchestration setup:

{
  identity: {
    name: "Zoe",
    emoji: "🤖",
    theme: "technical orchestrator with full business context"
  },
  agent: {
    workspace: "~/.openclaw/workspace",
    model: {
      primary: "anthropic/claude-opus-4-5",
      fallbacks: ["anthropic/claude-sonnet-4-20250514"]
    },
    elevated: { enabled: true },
    heartbeat: { every: "30m", target: "last" }
  },
  channels: {
    telegram: {
      token: "YOUR_BOT_TOKEN",
      allowFrom: ["YOUR_TELEGRAM_USER_ID"]
    }
  },
  cron: {
    enabled: true,
    maxConcurrentRuns: 2
  }
}

Step 2: Create the Agent Spawn Script

Save this as .clawdbot/spawn-agent.sh in your project root. This script creates the isolated worktree, registers the task, and fires the agent:

#!/bin/bash
# Usage: ./spawn-agent.sh [task-id] [branch-name] [agent-type] [model]
# Example: ./spawn-agent.sh feat-templates feat/custom-templates codex gpt-5.3-codex

TASK_ID=$1
BRANCH=$2
AGENT=$3
MODEL=$4
WORKTREE_DIR="../${TASK_ID}-worktrees/${TASK_ID}"

# Create isolated git worktree
git worktree add "$WORKTREE_DIR" -b "$BRANCH" origin/main
cd "$WORKTREE_DIR" && pnpm install

# Register task in JSON registry
cat > .clawdbot/active-tasks.json << EOF
{
  "id": "$TASK_ID",
  "tmuxSession": "${AGENT}-${TASK_ID}",
  "agent": "$AGENT",
  "branch": "$BRANCH",
  "worktree": "$WORKTREE_DIR",
  "startedAt": $(date +%s000),
  "status": "running",
  "notifyOnComplete": true
}
EOF

# Spawn the agent in a tmux session
if [ "$AGENT" == "codex" ]; then
  tmux new-session -d -s "${AGENT}-${TASK_ID}" \
    -c "$WORKTREE_DIR" \
    "codex --model $MODEL \
      -c 'model_reasoning_effort=high' \
      --dangerously-bypass-approvals-and-sandbox \
      'Your task prompt here'"
elif [ "$AGENT" == "claude" ]; then
  tmux new-session -d -s "${AGENT}-${TASK_ID}" \
    -c "$WORKTREE_DIR" \
    "claude --model claude-opus-4-5 \
      --dangerously-skip-permissions \
      -p 'Your task prompt here'"
fi

echo "Agent spawned: ${AGENT}-${TASK_ID} on branch $BRANCH"

Step 3: Mid-Task Redirection via tmux

This is where tmux pays for itself. When an agent drifts, you do not kill and restart. You redirect in real time:

# Agent going the wrong direction:
tmux send-keys -t codex-templates \
  "Stop. Focus on the API layer first, not the UI." Enter

# Agent needs more context:
tmux send-keys -t codex-templates \
  "The schema is in src/types/template.ts. Use that." Enter

# Check what all active agents are doing:
tmux list-sessions

Step 4: The Monitoring Cron

Save this as .clawdbot/check-agents.sh. This runs every 10 minutes and is the deterministic backbone of the whole system:

#!/bin/bash
# Reads active-tasks.json and checks each tracked agent

TASKS_FILE=".clawdbot/active-tasks.json"
MAX_RETRIES=3

# Read all running tasks
for task in $(jq -r '.[] | select(.status=="running") | .id' "$TASKS_FILE"); do
  SESSION=$(jq -r ".[] | select(.id==\"$task\") | .tmuxSession" "$TASKS_FILE")
  BRANCH=$(jq -r  ".[] | select(.id==\"$task\") | .branch"    "$TASKS_FILE")
  RETRIES=$(jq -r ".[] | select(.id==\"$task\") | .retries // 0" "$TASKS_FILE")

  # 1. Check if tmux session is alive
  if ! tmux has-session -t "$SESSION" 2>/dev/null; then
    echo "Session $SESSION dead. Respawning..."
    # Respawn logic here (calls spawn-agent.sh with same params)
    continue
  fi

  # 2. Check for open PR on tracked branch
  PR_NUMBER=$(gh pr list --head "$BRANCH" --json number -q '.[0].number')
  if [ -z "$PR_NUMBER" ]; then continue; fi

  # 3. Check CI status
  CI_STATUS=$(gh pr checks "$PR_NUMBER" --json state -q '.[] | .state' | sort -u)

  if [[ "$CI_STATUS" == *"FAILURE"* ]]; then
    if [ "$RETRIES" -lt "$MAX_RETRIES" ]; then
      echo "CI failed on PR $PR_NUMBER. Respawning with updated prompt..."
      # Increment retry count, update prompt with failure reason, respawn
    else
      echo "Max retries hit on $task. Alerting human."
      # Send Telegram alert via openclaw message
    fi
  elif [[ "$CI_STATUS" == "SUCCESS" ]]; then
    # 4. Check all AI reviews passed
    REVIEWS=$(gh pr reviews "$PR_NUMBER" --json state -q '.[].state')
    if [[ "$REVIEWS" == *"APPROVED"*"APPROVED"*"APPROVED"* ]]; then
      # Send Telegram: "PR #N ready for review"
      openclaw message send --target YOUR_TELEGRAM_ID \
        --message "PR #$PR_NUMBER ready for review. All checks passed."
      # Update task status to done
      jq "(.[] | select(.id==\"$task\") | .status) = \"done\"" \
        "$TASKS_FILE" > tmp.json && mv tmp.json "$TASKS_FILE"
    fi
  fi
done

Add this to your crontab:

# Run agent monitoring every 10 minutes
*/10 * * * * cd /path/to/your/project && bash .clawdbot/check-agents.sh >> ~/.openclaw/logs/agents.log 2>&1

# Daily cleanup of orphaned worktrees
0 2 * * * cd /path/to/your/project && bash .clawdbot/cleanup-worktrees.sh

Which Agent Gets Which Task

The single biggest efficiency win in this system is routing. Not every task should go to Codex. Not every task should go to Claude Code. Zoe makes the call. Here is the routing logic she uses and why:

The Definition of Done (Non-Negotiable)

The single most important rule in this system: a PR is not done when the code is written. It is done when all of these conditions are true. Your agent needs to know this in its initial prompt or it will notify you too early and train you to ignore notifications.

What This Actually Costs

Running at 50 commits per day, the full stack comes to roughly $190/month. Two of the four tools cost nothing.

Claude API via claude-opus-4-5 runs around $100/month at this volume. It covers both Zoe as the orchestrator and Claude Code as a worker agent. Codex via ChatGPT Pro or the API adds another $90/month and handles roughly 90% of all coding tasks as the primary workhorse. Gemini Code Assist is free on its GitHub integration and reviews every single PR for security and scalability issues. OpenClaw itself is open source, self-hosted, and costs nothing to run.

You can start for $20. ChatGPT Plus at $20/month includes Codex access. Pair it with the Claude API at low volume and the system works. The $190 figure is what it costs at scale once you are confident it fits your workflow. Scale spend as commit velocity grows, not before.

The Honest Assessment

This system works well on a specific class of problems: well-scoped features, bug fixes with clear reproduction steps, anything where the task can be described precisely in a prompt. The 94-commit peak and 50-commit daily average are real production numbers from running this on a live B2B SaaS product.

Here is where it breaks down.

RAM is the real bottleneck. Each agent needs its own worktree. Each worktree needs its own node_modules. Five agents running simultaneously means five parallel TypeScript compilers. On 16GB RAM you top out at 4 to 5 concurrent agents before memory pressure becomes a real problem. If you are serious about running more than that, budget for a machine with 64GB or more. A Mac Studio M4 Max with 128GB handles it cleanly.

Claude Code as reviewer is weak. It catches almost nothing independently. Its only real value is validating what Codex and Gemini already flagged. Do not treat it as a primary reviewer. Skip its suggestions unless one is marked critical.

Task scoping is still a human skill. The system one-shots small to medium tasks reliably. Large, ambiguous tasks still need a human to break them down before handing to the orchestrator. Feed Zoe a vague request and she writes a vague prompt. Agents produce vague code. Garbage in, garbage out at every layer.

Security surface is real. OpenClaw in this setup has admin API access and read-only prod DB access. Misconfigured instances are a documented attack vector. Start in read-only mode. Audit every permission you grant before opening anything touching production data.

Run It for One Week Before Scaling

Here is the exact sequence to verify this works for your codebase before committing to the full setup:

Week 1: Install OpenClaw, connect Telegram, run it in read-only mode on your codebase. Give Zoe your Obsidian vault or a folder of meeting notes. Ask her to scope one real feature request you have been putting off. Do not spawn any agents yet. Just verify the context and scoping output is better than what you get by prompting Codex directly.

Week 2: Spawn one agent on one isolated task. Single worktree, single tmux session, no monitoring cron yet. Watch the full cycle manually. Notice where the prompt falls short. Iterate on Zoe's context before adding automation.

Week 3: Add the monitoring cron. Add the three-reviewer setup. Define your exact quality gate conditions in AGENTS.md. At this point the system starts working mostly without you.

Week 4: You start receiving Telegram messages about PRs you did not know were in progress.

That is the unlock. The system finds work, does work, reviews work, and tells you when to merge. You operate at one level of abstraction above the code. This is what solo founders with agent fleets will look like in 2026, and it is already running in production today.

If you are building something with this stack or already running an agent swarm, I want to see it.