Docs / Agentic Development

Why Multi-Agent?

A single AI agent is powerful — but it has limits. Context windows fill up. Prompts lose focus when mixing UI, backend, tests, and security in one conversation. Knowledge is shallow across too many domains.

Multi-agent development solves this by assigning specialist agents to focused tasks — just like a real engineering team. A Team Lead decomposes work, delegates to experts, and verifies results. Each agent operates within a well-scoped context, producing higher quality output.

Orchestration Patterns

In multi-agent development, an orchestrator (or Team Lead) coordinates the work. It analyzes requirements, creates a plan, assigns tasks to specialist agents, and verifies their output — similar to a tech lead managing a team of engineers.

Key orchestration principles:

• Task decomposition — break work into the smallest meaningful, independently verifiable units
• File partitioning — parallel agents never touch the same files, eliminating merge conflicts
• Dependency ordering — tasks are phased so dependent work waits for prerequisites
• Independent verification — every output is reviewed before being accepted

Specialist Agents

Instead of one generalist AI trying to handle everything, multi-agent systems assign focused roles with domain-specific instructions, tools, and context. This mirrors how real engineering teams operate — you wouldn't ask a backend engineer to also design the UI and write the security audit.

Quality Gates

In single-agent workflows, you manually verify output. In multi-agent systems, quality gates automate verification — ensuring every agent's work passes review before being accepted.

• Deterministic checks — lint, type-check, and test suites run automatically
• Fast review — a lightweight reviewer agent checks acceptance criteria, file partitions, and regressions
• Panel review — for high-stakes changes (security, auth, DB migrations), multiple independent reviewers vote PASS/BLOCK
• Self-improvement — lessons from failures are captured and fed back into future agent prompts

Architecture

The Ralph Wiggum Loop

The Ralph Wiggum Loop, invented by Geoffrey Huntley, is a single-agent technique for autonomous coding. It's a simple bash loop — while :; do cat PROMPT.md | claude-code; done — where one AI agent iterates repeatedly on a task until it's done. Named after the Simpsons character because he's cheerfully persistent despite failures: eventual consistency through brute force.

• One task per iteration — each loop gets a fresh context window; the spec in PROMPT.md is deterministically loaded every time
• Backpressure — tests, type checkers, and linters act as gates; bad code is rejected automatically before the next iteration
• Self-improvement — the agent updates AGENT.md and fix_plan.md between runs, accumulating knowledge across iterations
• Brute force meets persistence — the loop is the hero, not the model; it runs until the work is done
• Best for greenfield — works well as a single-agent technique for new projects (Geoffrey Huntley built an entire programming language, CURSED, using this technique)

Gas Town Architecture

Steve Yegge's Gas Town takes the looping-agent idea to industrial scale — dozens of Claude Code instances working in parallel through a rigorous work representation system called the MEOW stack (Molecular Expression of Work):

• Beads — the atomic unit of work; one-issue-per-line JSON files tracked in Git (a Git-backed JSONL issue tracker built in Go)
• MEOW stack — layered work representation: Beads → Epics → Molecules → Formulas; state persists in Git so work survives crashes (Nondeterministic Idempotence)
• GUPP (Gastown Universal Propulsion Principle) — "If there is work on your hook, YOU MUST RUN IT"; keeps agents driving forward across session crashes
• Polecats — ephemeral per-rig workers; they spin up on demand in swarms, produce Merge Requests, get merged, then are fully decommissioned with names recycled — cattle, not pets
• Deacon — the "daemon beacon"; a patrol agent that runs workflows in a loop, propagating DYFJ ("Do Your Job") signals to workers, managing orchestration, plugins, and session recycling; has helper workers called Dogs (including Boot)
• Witness — the actual worker health monitor; checks on polecats and refineries and detects stuck or zombie workers
• Convoy — the ticketing and work-order system that wraps work into a delivery unit, maintaining order and dependencies across the pipeline
• Refinery — a merge queue that serializes changes from parallel workers, preventing conflicts before they reach the main branch

Gas Town vs OpenCastle

OpenCastle takes these ideas and rebuilds them for the IDE-native developer workflow — TypeScript over Go, SQLite over Git JSONL, standard git tooling over custom infrastructure:

Why OpenCastle