Gas Town: Git-Backed State Machines for Multi-Agent AI Orchestration
Hook
What happens when 30 AI coding agents lose their context mid-sprint? Gas Town’s answer: treat agent memory like source code—commit it, branch it, and never lose work again.
Context
AI coding assistants like Claude Code and OpenAI Codex have become legitimately useful for implementing features, fixing bugs, and refactoring code. But they’ve always been solitary workers—you spin one up, it does a task, and it disappears. The moment the process ends, all context vanishes. Try coordinating multiple agents on a complex project and you’ll quickly discover the problem: Agent A refactors a module that Agent B is depending on, but B has no idea the change happened. Agent C gets halfway through implementing a feature, crashes, and has to start over from scratch because there’s no memory of what it was doing.
This context-loss problem becomes exponentially worse as you scale up. Managing two or three agents manually is tedious but possible. Coordinating 20-30 agents on a multi-week project with interdependent tasks? That requires infrastructure. You need persistent state, task queues, work distribution, and recovery mechanisms. Gas Town, built by Steve Yegge in Go, solves this by treating agent state as a first-class citizen, persisting it in git worktrees and coordinating work through a SQLite-backed task queue. It’s not a simple wrapper—it’s a complete multi-agent operating system designed for serious AI-driven development workflows.
Technical Insight
Gas Town’s core architectural insight is that agent state should live in version control. When you create a workspace for an agent (called a ‘hook’ in Gas Town’s terminology), it’s backed by a git worktree. Every piece of context—the files being modified, the conversation history, the current task state—gets committed. When an agent crashes or needs to pause, its state is already persisted. When it restarts, it checks out the worktree and picks up exactly where it left off.
The system is organized around a hub-and-spoke model. At the center is the ‘Mayor’—an AI coordinator that makes high-level decisions about work distribution. The Mayor manages ‘rigs,’ which are project containers. Each rig contains one or more git repositories, ‘crew members’ (long-lived agent workspaces), and ‘polecats’ (ephemeral worker agents spawned for specific tasks). Here’s what a basic rig configuration looks like in Gas Town’s TOML format:
[rig]
name = "myproject"
repo = "https://github.com/user/myproject"
base_branch = "main"
[[rig.crew]]
name = "architect"
role = "system-design"
hook_type = "persistent"
[[rig.crew]]
name = "implementer"
role = "feature-development"
hook_type = "persistent"
[convoy]
db_path = "./convoy.db"
max_workers = 8The ‘convoy’ system is Gas Town’s task queue implementation. It’s a SQLite database that tracks work items, dependencies between tasks, and which agents are assigned to what. Work items integrate with Beads, a structured issue tracking system, using a custom ID format (like FEAT-a3k9m). When the Mayor breaks down a large feature request, it creates multiple convoy tasks with dependency relationships. Agents claim tasks, work on them in their git worktrees, and update the convoy database with progress.
What makes this architecture powerful is the formula system. Formulas are TOML-defined workflows that encode repeatable processes with dependency graphs. Want to define a standard “implement feature” workflow that involves design review, implementation, test writing, and integration? You create a formula:
[formula]
name = "implement-feature"
[[formula.step]]
id = "design"
agent_role = "architect"
prompt_template = "Design the architecture for: {{.feature_description}}"
[[formula.step]]
id = "implement"
agent_role = "implementer"
depends_on = ["design"]
prompt_template = "Implement according to design in {{.design_output}}"
[[formula.step]]
id = "test"
agent_role = "tester"
depends_on = ["implement"]
prompt_template = "Write tests covering {{.implementation_files}}"
[[formula.step]]
id = "integrate"
agent_role = "integrator"
depends_on = ["implement", "test"]
prompt_template = "Merge changes and resolve conflicts"When you execute a formula, Gas Town expands it into convoy tasks with proper dependencies, assigns them to appropriate agents, and orchestrates the entire workflow. The git-backed state means if an agent fails during the “implement” step, it doesn’t corrupt the pipeline—you just restart that agent and it resumes.
The runtime integration is surprisingly flexible. Gas Town can run in full orchestration mode using tmux, where it spawns Claude Code CLI instances in separate panes and manages their lifecycles. Or it can run in minimal mode where you manually control agents but still get the benefit of persistent state and task coordination. The abstraction layer supports swapping between Claude Code and OpenAI Codex without changing your workflow definitions.
Gotcha
Gas Town’s biggest limitation is its heavyweight dependency chain. You need Go 1.23+, Git 2.25+ with worktree support, Beads 0.44.0+ for issue tracking, tmux 3.0+ if you want orchestration mode, and the Claude Code CLI configured with API credentials. This isn’t a “npm install” experience—it’s a complex toolchain that requires careful setup and maintenance. If any component in the chain breaks or has version conflicts, debugging becomes an expedition through multiple systems.
The git worktree persistence strategy, while clever, has scaling considerations that aren’t well-documented. Each hook creates a new worktree, which means each active agent has a full copy of the repository on disk. With 30 agents running simultaneously on a large monorepo, you’re looking at significant disk I/O and storage requirements. The SQLite convoy database is a single-writer system, which means extremely high concurrency scenarios (50+ agents claiming tasks simultaneously) could hit lock contention. There’s also no clear guidance on how to handle pathological cases—what happens when an agent corrupts its worktree, or when the convoy database grows to gigabytes from accumulated task history? The project is relatively new and these operational concerns haven’t been battle-tested at scale. Error recovery patterns and production deployment considerations are sparse in the documentation, which suggests this is still experimental infrastructure rather than proven production tooling.
Verdict
Use Gas Town if you’re running multi-agent AI development workflows with 10+ agents where context persistence and coordination are non-negotiable—particularly for projects spanning weeks or months where agent crashes would otherwise lose significant work. It’s ideal for teams treating AI agents as first-class development infrastructure rather than occasional assistants. Skip it if you’re doing simple single-agent tasks, can’t commit to managing the complex toolchain dependencies, or need production-grade stability with established operational runbooks. This is cutting-edge infrastructure for serious AI-agent-driven development at scale, not a productivity wrapper for casual AI coding assistance. If you’re already coordinating multiple AI agents manually and hitting coordination chaos, Gas Town is worth the setup cost. If you’re just exploring AI coding tools, start with simpler solutions and come back when you outgrow them.
