ONE AGENT STEERING ANOTHER

Using exe.dev to build an orchestration system where Claude watches Claude work.

INFRASTRUCTURE 2026.02.01

THE SETUP

I'm in one Claude conversation. Call it the "steering" agent.

It spawns another Claude conversation—the "worker" agent—pointed at a codebase. The worker runs until it hits context limits, writes a handoff, and exits. A new worker picks up where it left off.

Meanwhile, I'm watching. In real time. From the steering agent.

THE TOOLS

Built this on exe.dev—a VM that runs Shelley (an agent runtime) with persistent filesystem and HTTP API access.

The orchestration layer is just bash scripts:

# Start an autonomous loop
worker start orchestrator \
  --task "Build the API endpoint" \
  --dir /path/to/project \
  --max 50 \
  --model claude-opus-4.5

# Check status
worker list
# NAME          STATUS   SESSION  DIR
# orchestrator  running  12/50    /home/project

# Adjust on the fly
worker adjust orchestrator --max 100

The steering agent can query worker status, read logs, even cancel runaway sessions:

# List active conversations
conv list --working

# Check context usage
conv status orchestrator
# Context: 145,231 tokens

# Kill a runaway
conv cancel orchestrator

THE LOOP

Each worker session follows a protocol:

Run gates/health.sh — catch build errors, uncommitted work
Query deja for project memories
Read handoff from previous session
Do work until context limit (~75%)
Commit everything
Write handoff for next session
Exit

The key insight: sessions are ephemeral but the repo is permanent. State lives in git, not in the agent's context.

SELF-HEALING

Workers die mid-task. Context limit hits, timeout, crash—doesn't matter. Work gets orphaned.

The health check at session start auto-rescues:

# Auto-commit orphaned work
UNCOMMITTED=$(git status --porcelain | grep -E "^( M|M |\?\?)")
if [ -n "$UNCOMMITTED" ]; then
  echo "⚠️ Rescuing uncommitted work..."
  git add -A
  git commit -m "Auto-rescue: work from crashed session"
fi

No manual intervention. The system assumes failure and designs for recovery.

STEERING IN REAL TIME

The steering agent isn't just watching—it can intervene:

Adjust max sessions — let it run longer or cut it short
Change the model — switch from Opus to Sonnet mid-run
Update deja memories — steer direction without touching code
Fix blocking errors — unblock the worker by fixing types, tests
Archive old conversations — clean up the workspace

Two agents, one codebase, pure observability. The steering agent sees everything the worker does without being in the same context window.

THE API

Documented at docs.coey.dev. Everything the steering agent uses:

POST /api/conversation/{id}/archive
POST /api/conversation/{id}/cancel
GET /api/conversations (includes working field)
GET /api/conversation/{id} (includes context_window_size)

Shell scripts wrap these. The steering agent doesn't need to know HTTP—it just runs conv status orchestrator.

WHY THIS MATTERS

Context windows are finite. Agent memory is expensive. But agent labor is cheap.

Instead of one agent trying to hold everything in context, run many short-lived agents that hand off to each other. The repo is the memory. Git is the protocol.

One human (or one steering agent) can supervise dozens of worker loops. That's the multiplier.

TRY IT

The orchestration scripts are documented at docs.coey.dev.

The platform we're building (to escape exe.dev rate limits) is myfilepath.com—persistent containers for agent loops.

Same ideas, open infrastructure.