Gas Town — Multi-Agent Workspace Manager
Orchestrate multiple AI coding agents with persistent work tracking via git, scaling to 20-30 agents across Claude Code, GitHub Copilot, and more.
Evidence shows: README and SECURITY.md mention agents run in tmux sessions, share filesystem access, and can execute shell commands, but no specific least-privilege mechanisms are provided. User confirmation: `--human` flag and `gt convoy create --human` exist, but not all high-risk operations require explicit confirmation. Data flow transparency: `gt feed` and `gt peek` provide monitoring, but data flow details are not specified. Sensitive data handling: no mention of credential management or encryption. Dependency security: go.mod lists many dependencies, but no vulnerability scanning or version pinning strategy. External effects: agents can push git and run shell, but no explicit restrictions. Rollback: git and beads persistence exist, but no explicit rollback mechanism. Source attribution: SECURITY.md and release notes exist, but publisher not verified. Deductions: lack of implementation details, mostly assertions.
Evidence shows: README and CI workflows are consistent, no internal contradictions found. Dependency availability: go.mod lists dependencies, CI installs Dolt and ICU, but no guarantee of dependency availability. Failure messages: `gt doctor --fix` and error handling exist, but no specific failure message examples. Deductions: no concrete failure message examples.
Evidence shows: README describes multiple scenarios (Mayor, Minimal Mode, Docker) and provides runtime configuration. Capability boundaries: `gt config` and presets exist, but no explicit limits. Trigger precision: commands like `gt sling` and `gt convoy` exist, but trigger conditions not specified. Environment fit: supports multiple platforms and Docker, but not all environments detailed. Deductions: some descriptions incomplete.
Evidence shows: README structure clear, with installation instructions, examples, and FAQ (partial). Naming stability: `gt` and `bd` commands exist, but no version history. Known limitations: SECURITY.md mentions experimental, but no specific limitations listed. License: MIT license clear. Versioning/changelog: no CHANGELOG provided. Maintenance responsibility: SECURITY.md and CI exist, but maintainers not clearly identified. Deductions: missing version history and changelog.
Evidence shows: Output usability: `gt feed` and `gt convoy list` provide output. Marginal value: solves multi-agent coordination problem, but no comparative data. Cost-benefit: no performance or resource consumption data. Deductions: lack of quantitative evaluation.
Evidence shows: README and CI workflows traceable, but no test results provided. Cross-source corroboration: CI and test files exist, but no external verification. Fact/inference separation: README distinguishes concepts and commands, but not explicitly. Deductions: lack of test results and external verification.
- Agents have broad permissions (filesystem, shell, git push); run in isolated environments.
- Many dependencies without vulnerability scanning; regularly check dependency security.
- No explicit rollback mechanism; back up important data before operations.
What does this agent do, and when should you use it?
Gas Town is a multi-agent workspace manager providing persistent work tracking and cross-agent coordination for AI coding agents like Claude Code, GitHub Copilot, and Codex. It addresses context loss on restart, manual coordination overhead, and chaos when scaling beyond 4-10 agents. Core components include the Mayor (AI coordinator), Town (workspace), Rigs (project containers), Crews (personal workspaces), Polecats (worker agents), Hooks (git worktree-based persistent storage), Convoys (work tracking units), and Beads (git-backed issue tracking). Written in Go, it offers a CLI (`gt`) and integrates with the Beads CLI (`bd`), supporting native and Docker installs. Monitoring is handled by Witness, Deacon, and Dogs, with Refinery merge queue, scheduler, Seance session discovery, and Wasteland federation.
Gas Town provides commands for workspace setup (gt install), project management (gt rig add), agent operations (gt sling, gt agents), work tracking (gt convoy), and monitoring (gt feed, gt mayor attach). It leverages git hooks and worktrees to store agent work state, ensuring recovery after restarts. Agents submit completed work via gt done, and the Refinery merges batches using a Bors-style bisecting queue. gt escalate routes blockers through severity levels. Seance discovers and queries previous sessions via .events.jsonl logs. Wasteland federation coordinates work across towns via DoltHub.
- Development teams coordinating multiple AI coding agents on different tasks within the same codebase
- Individual developers needing context persistence across agent restarts
- Teams monitoring agent health and addressing stuck agents at scale (20-50+ agents)
- Organizations wanting to define reusable templates for repeatable processes like releases
- Distributed teams collaborating on work items across projects
What are this agent's strengths and limitations?
- Persistent work state via git hooks, surviving agent restarts without context loss
- Supports multiple AI agent runtimes (Claude Code, Codex, GitHub Copilot, etc.) with presets and custom configuration
- Built-in monitoring, escalation, and merge queue facilities enable large-scale agent orchestration
- Complex setup requiring many prerequisites (Git, Go, Beads, tmux, Dolt, ICU4C, etc.)
- Native Windows support is limited; full functionality requires WSL
- Dependent on specific CLI tools and versions; updates may introduce breaking changes
How do you install or deploy this agent?
Native (macOS/Linux/Windows): Install Git 2.20+, Go 1.26.2+, Beads (bd) 0.57.0+, tmux 3.0+, and Dolt. On macOS, brew install gastown. On Linux/Windows, go install github.com/steveyegge/gastown/cmd/gt@latest and github.com/steveyegge/beads/cmd/bd@latest. Then run gt install ~/gt --shell --git, gt up, and gt doctor --fix. Docker: Set GIT_USER, GIT_EMAIL, FOLDER, then docker compose build and docker compose up -d.
How do you use this agent?
Start the Mayor with gt mayor attach and tell it what to build. The Mayor creates a convoy and assigns work. For example, gt convoy create "Feature X" gt-abc12 gt-def34 --notify --human creates a convoy, gt sling gt-abc12 myproject assigns work, gt convoy list tracks progress, and gt feed monitors activity. For repeatable processes, use bd cook release --var version=1.2.0.
How does this agent compare with similar options?
Compared to manual coordination or simple agent wrappers, Gas Town offers a more comprehensive solution with persistent storage, automated merging, and a monitoring hierarchy.