gastownhall/gastown

Gas Town - multi-agent workspace manager

Gas Town

Multi-agent orchestration system for Claude Code, GitHub Copilot, and other AI agents with persistent work tracking

Overview

Gas Town is a workspace manager that lets you coordinate multiple AI coding agents (Claude Code, GitHub Copilot, Codex, Gemini, and others) working on different tasks. Instead of losing context when agents restart, Gas Town persists work state in git-backed hooks, enabling reliable multi-agent workflows.

What Problem Does This Solve?

Architecture

Core Concepts

The Mayor 🎩

Your primary AI coordinator. The Mayor is a Claude Code instance with full context about your workspace, projects, and agents. Start here - just tell the Mayor what you want to accomplish.

Town 🏘️

Your workspace directory (e.g., ~/gt/). Contains all projects, agents, and configuration.

Rigs 🏗️

Project containers. Each rig wraps a git repository and manages its associated agents.

Crew Members 👤

Your personal workspace within a rig. Where you do hands-on work.

Polecats 🦨

Worker agents with persistent identity but ephemeral sessions. Spawned for tasks, sessions end on completion, but identity and work history persist.

Hooks 🪝

Git worktree-based persistent storage for agent work. Survives crashes and restarts.

Convoys 🚚

Work tracking units. Bundle multiple beads that get assigned to agents. Convoys labeled mountain get autonomous stall detection and smart skip logic for epic-scale execution.

Beads Integration 📿

Git-backed issue tracking system that stores work state as structured data.

Bead IDs (also called issue IDs) use a prefix + 5-character alphanumeric format (e.g., gt-abc12, hq-x7k2m). The prefix indicates the item's origin or rig. Commands like gt sling and gt convoy accept these IDs to reference specific work items. The terms "bead" and "issue" are used interchangeably—beads are the underlying data format, while issues are the work items stored as beads.

Molecules 🧬

Workflow templates that coordinate multi-step work. Formulas (TOML definitions) are instantiated as molecules with tracked steps. Two modes: root-only wisps (steps materialized at runtime, lightweight) and poured wisps (steps materialized as sub-wisps with checkpoint recovery). See Molecules.

Monitoring: Witness, Deacon, Dogs 🐕

A three-tier watchdog system keeps agents healthy:

• Witness - Per-rig lifecycle manager. Monitors polecats, detects stuck agents, triggers recovery, manages session cleanup.

• Deacon - Background supervisor running continuous patrol cycles across all rigs.

• Dogs - Infrastructure workers dispatched by the Deacon for maintenance tasks (e.g., Boot for triage).

Refinery 🏭

Per-rig merge queue processor. When polecats complete work via gt done, the Refinery batches merge requests, runs verification gates, and merges to main using a Bors-style bisecting queue. Failed MRs are isolated and either fixed inline or re-dispatched.

Escalation 🚨

Severity-routed issue escalation. Agents that hit blockers escalate via gt escalate, which creates tracked beads routed through the Deacon, Mayor, and (if needed) Overseer. Severity levels: CRITICAL (P0), HIGH (P1), MEDIUM (P2). See Escalation.

Scheduler ⏱️

Config-driven capacity governor for polecat dispatch. Prevents API rate limit exhaustion by batching dispatch under configurable concurrency limits. Default is direct dispatch; set scheduler.max_polecats to enable deferred dispatch with the daemon. See Scheduler.

Seance 👻

Session discovery and continuation. Discovers previous agent sessions via .events.jsonl logs, enabling agents to query their predecessors for context and decisions from earlier work.

Wasteland 🏜️

Federated work coordination network linking Gas Towns through DoltHub. Rigs post wanted items, claim work from other towns, submit completion evidence, and earn portable reputation via multi-dimensional stamps. See Wasteland.

New to Gas Town? See the Glossary for a complete guide to terminology and concepts.

Installation

Prerequisites

• Go 1.25+ - go.dev/dl

• Git 2.25+ - for worktree support

• Dolt 2.0.7+ - brew install dolt on macOS, or see github.com/dolthub/dolt

• beads (bd) 0.55.4+ - installed by brew install gastown, or see github.com/steveyegge/beads

• sqlite3 - for convoy database queries (usually pre-installed on macOS/Linux)

• tmux 3.0+ - recommended for full experience

• Claude Code CLI (default runtime) - claude.ai/code

• Codex CLI (optional runtime) - developers.openai.com/codex/cli

• GitHub Copilot CLI (optional runtime) - cli.github.com (requires Copilot seat)

Setup (Docker-Compose below)

Docker Compose

Quick Start Guide

Getting Started

Run

and tell the Mayor what you want to build!

Basic Workflow

Example: Feature Development

Common Workflows

Mayor Workflow (Recommended)

Best for: Coordinating complex, multi-issue work

Commands:

Minimal Mode (No Tmux)

Run individual runtime instances manually. Gas Town just tracks state.

Beads Formula Workflow

Best for: Predefined, repeatable processes

Formulas are TOML-defined workflows embedded in the gt binary (source in internal/formula/formulas/).

Example Formula (internal/formula/formulas/release.formula.toml):

Execute:

Manual Convoy Workflow

Best for: Direct control over work distribution

Runtime Configuration

Gas Town supports multiple AI coding runtimes. Per-rig runtime settings are in settings/config.json.

Notes:

• Claude uses hooks in .claude/settings.json (managed via --settings flag) for mail injection and startup.

• For Codex, set project_doc_fallback_filenames = ["CLAUDE.md"] in ~/.codex/config.toml so role instructions are picked up.

• For runtimes without hooks (e.g., Codex), Gas Town sends a startup fallback after the session is ready: gt prime, optional gt mail check --inject for autonomous roles, and gt nudge deacon session-started.

• GitHub Copilot (copilot) is a built-in preset using --yolo for autonomous mode. It uses executable lifecycle hooks in .github/hooks/gastown.json (same events as Claude: sessionStart, userPromptSubmitted, preToolUse, sessionEnd). Uses a 5-second ready delay instead of prompt detection. Requires a Copilot seat and org-level CLI policy. See docs/INSTALLING.md.

Key Commands

Workspace Management

Agent Operations

Built-in agent presets: claude, gemini, codex, cursor, auggie, amp, opencode, copilot, pi, omp

Convoy (Work Tracking)

Configuration

Monitoring & Health

Beads Integration

Wasteland Federation

Cooking Formulas

Gas Town includes built-in formulas for common workflows. See internal/formula/formulas/ for available recipes.

Activity Feed

gt feed launches an interactive terminal dashboard for monitoring all agent activity in real-time. It combines beads activity, agent events, and merge queue updates into a three-panel TUI:

• Agent Tree - Hierarchical view of all agents grouped by rig and role

• Convoy Panel - In-progress and recently-landed convoys

• Event Stream - Chronological feed of creates, completions, slings, nudges, and more

Navigation: j/k to scroll, Tab to switch panels, 1/2/3 to jump to a panel, ? for help, q to quit.

Problems View

At scale (20-50+ agents), spotting stuck agents in the activity stream becomes difficult. The problems view surfaces agents needing human intervention by analyzing structured beads data.

Press p in gt feed (or start with gt feed --problems) to toggle the problems view, which groups agents by health state:

Intervention keys (in problems view): n to nudge the selected agent, h to handoff (refresh context).

Dashboard

Gas Town includes a web dashboard for monitoring your workspace. The dashboard must be run from inside a Gas Town workspace (HQ) directory.

The dashboard gives you a single-page overview of everything happening in your workspace: agents, convoys, hooks, queues, issues, and escalations. It auto-refreshes via htmx and includes a command palette for running gt commands directly from the browser.

Monitoring & Health

Gas Town uses a three-tier watchdog chain to keep agents healthy at scale:

Witness (Per-Rig)

Each rig has a Witness that monitors its polecats. The Witness detects stuck agents, triggers recovery (nudge or handoff), manages session cleanup, and tracks completion. Witnesses delegate work rather than implementing it directly.

Deacon (Cross-Rig)

The Deacon runs continuous patrol cycles across all rigs, checking agent health, dispatching Dogs for maintenance tasks, and escalating issues that individual Witnesses can't resolve.

Escalation

When agents hit blockers, they escalate rather than waiting:

Escalations route through Deacon -> Mayor -> Overseer based on severity. See Escalation design.

Merge Queue (Refinery)

The Refinery processes completed polecat work through a bisecting merge queue:

1. Polecat runs gt done -> branch pushed, MR bead created

2. Refinery batches pending MRs

3. Runs verification gates on the merged stack

4. If green: all MRs in batch merge to main

5. If red: bisects to isolate the failing MR, merges the good ones

This is a Bors-style merge queue — polecats never push directly to main.

Scheduler

The scheduler controls polecat dispatch capacity to prevent API rate limit exhaustion:

Default mode (max_polecats = -1) dispatches immediately via gt sling. When a limit is set, the daemon dispatches incrementally, respecting capacity. See Scheduler design.

Seance

Discover and query previous agent sessions:

Seance discovers sessions via .events.jsonl logs, enabling agents to recover context and decisions from earlier work without re-reading entire codebases.

Wasteland Federation

The Wasteland is a federated work coordination network linking multiple Gas Towns through DoltHub:

Completions earn portable reputation via multi-dimensional stamps (quality, speed, complexity). See Wasteland guide.

Telemetry (OpenTelemetry)

Gas Town emits all agent operations as structured logs and metrics to any OTLP-compatible backend (VictoriaMetrics/VictoriaLogs by default):

Events emitted: session lifecycle, agent state changes, bd calls with duration, mail operations, sling/nudge/done workflows, polecat spawn/remove, formula instantiation, convoy creation, daemon restarts, and more.

Metrics include: gastown.session.starts.total, gastown.bd.calls.total, gastown.polecat.spawns.total, gastown.done.total, gastown.convoy.creates.total, and others.

See OTEL data model and OTEL architecture for the complete event schema.

Advanced Concepts

The Propulsion Principle

Gas Town uses git hooks as a propulsion mechanism. Each hook is a git worktree with:

1. Persistent state - Work survives agent restarts

2. Version control - All changes tracked in git

3. Rollback capability - Revert to any previous state

4. Multi-agent coordination - Shared through git

Hook Lifecycle

MEOW (Mayor-Enhanced Orchestration Workflow)

MEOW is the recommended pattern:

1. Tell the Mayor - Describe what you want

2. Mayor analyzes - Breaks down into tasks

3. Convoy creation - Mayor creates convoy with beads

4. Agent spawning - Mayor spawns appropriate agents

5. Work distribution - Beads slung to agents via hooks

6. Progress monitoring - Track through convoy status

7. Completion - Mayor summarizes results

Shell Completions

Project Roles

Tips

• Always start with the Mayor - It's designed to be your primary interface

• Use convoys for coordination - They provide visibility across agents

• Leverage hooks for persistence - Your work won't disappear

• Create formulas for repeated tasks - Save time with Beads recipes

• Use gt feed for live monitoring - Watch agent activity and catch stuck agents early

• Monitor the dashboard - Get real-time visibility in the browser

• Let the Mayor orchestrate - It knows how to manage agents

Design Documentation

For deeper technical details, see the design docs in docs/:

Troubleshooting

Agents lose connection

Check hooks are properly initialized:

Convoy stuck

Force refresh:

Mayor not responding

Restart Mayor session:

License

MIT License - see LICENSE file for details

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论