Gas Town: Steve Yegge’s Multi-Agent Orchestration Framework

Research Date: 2026-01-20 Source URL: https://x.com/willccbb/status/2011509849268596830

Reference URLs

Welcome to Gas Town (Original Article) - Steve Yegge, Medium
Gas Town Emergency User Manual - Steve Yegge, Medium
The Future of Coding Agents - Steve Yegge, Medium
Will Brown (@willccbb) Tweet - January 15, 2026
Allan (@niemerg) “Software-as-a-Psychosis” Tweet - January 14, 2026
Steve Yegge (@Steve_Yegge) Survival Guide Announcement - January 13, 2026
Yegge’s Developer Agent Evolution Model Analysis - Justin Abrahms

Summary

Gas Town is Steve Yegge’s multi-agent orchestration framework for AI-assisted coding, released in early January 2026. The system enables developers to manage colonies of 20-30 parallel AI coding agents (primarily Claude Code) through a structured hierarchy of roles, workflows, and persistent state management. Built in Go (~189k LOC) on top of the Beads issue-tracking system, Gas Town represents a paradigm shift from “developer using one AI assistant” to “developer as factory operator managing agent swarms.”

The framework garnered significant attention in the developer community, with Will Brown (@willccbb) describing the original article as “beautiful and terrifying and hilarious and probably a glimpse at the future that will feel normal in 6 months.” Allan (@niemerg) characterized the system as “Software-as-a-Psychosis”—a phrase capturing the manic intensity of managing dozens of AI agents simultaneously.

Gas Town is explicitly designed for developers at Stage 6-8 of Yegge’s Developer Evolution model—those already running multiple parallel agent instances and ready to build or adopt orchestration infrastructure. The system prioritizes throughput and parallelism over polish, offering durable workflows backed by Git with crash recovery and auditable state.

Architecture Overview

Town and Rigs

The Gas Town architecture centers on two organizational levels:

flowchart TD subgraph Town["Town (~gt directory)"] Config[Configuration] TownLevel[Town-Level Agents] Orchestration[Cross-Project Orchestration] end subgraph Rigs["Rigs (Project Repositories)"] Rig1[Rig 1: Project A] Rig2[Rig 2: Project B] Rig3[Rig 3: Project C] end Town --> Rig1 Town --> Rig2 Town --> Rig3 Rig1 --> RigAgents1[Per-Rig Agents] Rig2 --> RigAgents2[Per-Rig Agents] Rig3 --> RigAgents3[Per-Rig Agents]

Component	Description
Town	Headquarters directory (`~/gt`) housing configuration and managing all project rigs
Rig	A project/repository under Gas Town’s control; rigs live under the Town
Town-Level	Cross-project orchestration, workflows like releases or system patrols
Rig-Level	Project-specific tasks: features, bug fixes, local workflows

Agent Roles

Gas Town defines a hierarchy of specialized agent roles, each with distinct responsibilities:

flowchart TB subgraph Human["Human Layer"] Overseer[Overseer - Human Operator] end subgraph TownAgents["Town-Level Agents"] Mayor[Mayor - Chief Dispatcher] Deacon[Deacon - System Health Daemon] Dogs[Dogs - Maintenance Helpers] end subgraph RigAgents["Rig-Level Agents"] Crew[Crew - Persistent Named Agents] Polecats[Polecats - Ephemeral Workers] Refinery[Refinery - Merge Queue Manager] Witness[Witness - Supervisor and Unblocker] end Overseer --> Mayor Mayor --> Crew Mayor --> Polecats Deacon --> Dogs Witness --> Polecats Witness --> Refinery Polecats --> Refinery

Role	Scope	Lifespan	Primary Function
Overseer	Town	Permanent	Human operator; assigns work, monitors, makes decisions
Mayor	Town	Long-lived	Chief-of-staff; dispatches tasks, oversees major workflows
Deacon	Town	Long-lived	Daemon maintaining system health via patrol loops
Dogs	Town	Variable	Maintenance and helper agents under the Deacon
Crew	Rig	Long-lived	Named, persistent agents for sustained design and review work
Polecats	Rig	Ephemeral	”Cattle” workers; spun up for specific tasks, then terminated
Refinery	Rig	Long-lived	Manages merge queue; handles conflicting merges and rebasing
Witness	Rig	Long-lived	Supervises Polecats and Refinery; helps unstick blocked work

Every agent possesses:

Role Bead: Defines role rules and priming instructions
Agent Bead: Persistent identity surviving session restarts
Hook: Bead-backed queue where molecules and workflows attach

The MEOW Stack

MEOW (Molecular Expression of Work) is the workflow stack enabling persistent, composable, crash-recoverable work orchestration.

flowchart BT Beads[Beads - Atomic Tasks] --> Epics[Epics - Hierarchical Collections] Epics --> Molecules[Molecules - Workflow Graphs] Molecules --> Protomolecules[Protomolecules - Workflow Templates] Protomolecules --> Formulas[Formulas - TOML Definitions] subgraph Persistence["Persistence Layer"] Git[Git Repository] JSONL[JSONL Storage] end Beads --> JSONL JSONL --> Git

Beads

Beads are the atomic work units—issues with IDs, descriptions, status, and assignees stored in JSONL and tracked via Git. They form the universal data and control plane in Gas Town.

Property	Description
Format	JSONL files tracked in Git
Scope	Rig-level (features, bugs) or Town-level (orchestration)
Persistence	Survives session crashes; state recoverable from Git
Identity	Each bead has a unique ID for tracking and reference

Epics

Epics are hierarchical collections of Beads organized as tree structures. They enable organization of large goals into manageable subtasks with nested structure supporting parallel or sequential execution.

Molecules

Molecules are instantiated workflows—graphs of Beads sequenced with dependencies, gates, and loops. They define detailed step-by-step work with explicit ordering and conditions.

flowchart LR subgraph MoleculeFlow["Example Molecule: Feature Implementation"] DesignBead[Design Bead] --> ImplementBead[Implement Bead] ImplementBead --> TestBead[Test Bead] TestBead --> ReviewBead[Review Bead] ReviewBead --> ApprovalGate{Gate: Approved?} ApprovalGate -->|Yes| MergeBead[Merge Bead] ApprovalGate -->|No| ImplementBead end

Protomolecules

Protomolecules are workflow templates—entire workflow skeletons including Beads and structure ready for instantiation. They enable reusable workflow patterns across projects and tasks.

Formulas

Formulas are high-level source definitions in TOML format specifying workflows including loops, gates, and composition. Formulas are “cooked” into protomolecules, which are then instantiated into molecules.

# Example Formula Structure (conceptual)
[workflow]
name = "feature-implementation"

[[steps]]
name = "design"
type = "crew"
assignee = "architect"

[[steps]]
name = "implement"
type = "polecat"
depends_on = ["design"]
parallel = 3

[[steps]]
name = "review"
type = "crew"
depends_on = ["implement"]
gate = "approval-required"

Workflow Mechanisms

GUPP: Gas Town Universal Propulsion Principle

The fundamental scheduling principle: If there is work on your hook, you MUST run it.

GUPP ensures persistence of scheduling. Agents check their hooks, resume molecules, and pick up where they left off. Combined with persistent agent identity and Git-backed state, this enables work to survive crashes and session restarts.

Hooks and Handoffs

sequenceDiagram participant Overseer as Overseer participant Mayor as Mayor participant Polecat as Polecat participant Hook as Hook participant GitRepo as Git Overseer->>Mayor: gt sling molecule Mayor->>Hook: Attach molecule to Polecat hook Hook->>GitRepo: Persist hook state Polecat->>Hook: Check hook (GUPP) Polecat->>Polecat: Execute molecule steps Polecat-->>GitRepo: Update bead status Note over Polecat: Session crash Polecat->>Hook: Check hook on restart Hook->>GitRepo: Load persisted state Polecat->>Polecat: Resume from last checkpoint

Command	Function
`gt sling`	Attach molecules or beads onto agent hooks
`gt handoff` or `/handoff`	Restart sessions or move work to fresh sessions while preserving context

Patrols, Wisps, and Convoys

Concept	Description	Use Case
Patrols	Recurring workflows run by long-lived agents	Queue cleanup, health checks, merge queue processing
Wisps	Ephemeral beads living temporarily	Lightweight orchestration not requiring full persistence
Convoys	Aggregations of work items tracked as delivery units	Large composed goals like releases or feature sets

Developer Loops

The Emergency User Manual defines three nested development loops for productive Gas Town usage:

flowchart TD subgraph Outer["Outer Loop (Days-Weeks)"] Planning[Strategic Planning] Upgrades[System Upgrades] Cleanup[Town-Level Cleanups] end subgraph Middle["Middle Loop (Hours-Days)"] Spawning[Agent Spawning Decisions] Coordination[Mayor + Polecat Coordination] Throttling[Capacity Throttling] end subgraph Inner["Inner Loop (Minutes)"] Handoff[Frequent Handoffs] TaskSpec[Clear Task Specification] Review[Output Review] end Outer --> Middle Middle --> Inner

Loop	Timeframe	Activities
Outer	Days to weeks	Planning, town-level cleanups, upgrading infrastructure
Middle	Hours to days	Using Mayor + Polecats; deciding when to spawn many agents or throttle back
Inner	Minutes	Frequent `gt handoff`, clear task specification, reviewing agent output, adjusting

Operational Practices

Autonomy with inspection: Let agents work autonomously with clear instructions; always inspect results
Crew vs Polecats: Use Crew for thoughtful work (review, design); Polecats for well-specified fast tasks
PR Sheriffs: Crew role that scans open PRs, classifies easy wins vs manual review requirements
Garden tending: Regular review sweeps, catching “heresies” (incorrect assumptions), defining core principles

Developer Evolution Model

Gas Town targets developers at Stages 6-8 of Yegge’s Developer Evolution model:

Stage	Description	Agent Count	Management Style
Stage 1-5	Earlier stages of AI-assisted coding adoption	0-2	IDE-integrated, supervised
Stage 6	CLI, multi-agent, YOLO	3-5 parallel	High trust, less micromanagement
Stage 7	10+ agents, hand-managed	10+	Manual coordination, approaching limits
Stage 8	Building your own orchestrator	20-30+	Factory-style, automated orchestration

Gas Town is explicitly designed for Stage 7-8 developers. Yegge warns that developers at earlier stages will find the system frustrating rather than productive.

flowchart LR StageLearning[Stage 1-5: Learning] --> StageYolo[Stage 6: YOLO Mode] StageYolo --> StageManaging[Stage 7: Hand-Managing 10+] StageManaging --> StageOrchestrator[Stage 8: Orchestrator] StageOrchestrator --> GasTownUser[Gas Town User] style StageManaging fill:#ffd,stroke:#aa0 style StageOrchestrator fill:#dfd,stroke:#0a0 style GasTownUser fill:#ddf,stroke:#00a

Current State and Limitations

Technical Status (January 2026)

Metric	Value
Codebase	~189,000 lines of Go
Age	~3 weeks since Go port
Primary Agent	Claude Code (Opus 4.5)
Contributors	Dozens, many active PRs

Strengths

Throughput: Handles 20-30 parallel agents with work swarms and merge queue resolution
Persistence: Agent identity stored in Beads; workflows survive session restarts
Durability: Work backed by Git; auditable history, resumable state
Workflow Power: Rich primitives (molecules, formulas, patrols) for intricate workflow definitions

Limitations

Limitation	Description
Early Stage	Many components freshly implemented; missing features (UI, federation, custom roles)
Complexity	Many roles and moving parts; “watchers watching watchers”; steep learning curve
Cost	Running 20-30 agent instances requires substantial compute and API spend
Fragility	Some features depend on agents (Claude Code) being cooperative; reliability varies

Yegge explicitly warns: “You won’t like Gas Town if you ever have to think, even for a moment, about where money comes from.”

Future Implications

Near-Term Trends (2026)

Trend	Implication
Colony over Individual	Agent frameworks will offer richer APIs, role support, and observability; vendors not enabling coordination will lag
Orchestration as First-Class	Embedded workflow definitions, monitoring loops, and merge queue agents become standard
State Persistence Required	Users expect workflows to resume after crashes; Git-backed or immutable log systems become central
High Cost Barrier	Factory-scale agent usage remains prohibitive for small shops; primarily viable for those deeply invested in agentic coding

Architectural Comparison

Yegge describes Gas Town as “Kubernetes mated with Temporal” but focused on agent orchestration rather than infrastructure or enterprise workflows.

flowchart LR subgraph TraditionalOrch["Traditional Orchestration"] Kubernetes[Kubernetes - Container Orchestration] Temporal[Temporal - Workflow Engine] end subgraph AgentOrch["Agent Orchestration"] GasTown[Gas Town - Agent Factory] end Kubernetes -.->|Scheduling Concepts| GasTown Temporal -.->|Workflow Durability| GasTown

Key Findings

Gas Town represents a paradigm shift from AI-assisted coding to factory-scale agent orchestration, where the human becomes an “Overseer” managing colonies of agents rather than an individual coder
The MEOW stack (Beads, Epics, Molecules, Protomolecules, Formulas) provides layered workflow abstraction enabling crash-recoverable, Git-backed persistent orchestration
GUPP (Gas Town Universal Propulsion Principle) ensures work progresses: agents must execute work on their hooks, enabling reliable scheduling across session restarts
The system explicitly targets Stage 7-8 developers already comfortable running 10+ parallel agents; earlier-stage developers are warned the system will be counterproductive
Current limitations include significant cost (multiple Claude Code subscriptions, heavy API usage), complexity (many interdependent roles and systems), and early-stage polish issues
The “Software-as-a-Psychosis” framing captures the manic intensity of managing dozens of AI agents—a glimpse at what may become normalized development practice

References

Will Brown (@willccbb) - Original Tweet - January 15, 2026
Allan (@niemerg) - “Software-as-a-Psychosis” - January 14, 2026
Steve Yegge - Welcome to Gas Town - Medium, January 2026
Steve Yegge - Gas Town Emergency User Manual - Medium, January 2026
Steve Yegge - The Future of Coding Agents - Medium, January 2026
Justin Abrahms - Yegge’s Developer Agent Evolution Model - January 8, 2026
ASCII.co.uk - Steve Yegge Releases Gas Town - January 2, 2026