gastown/gastown: The Repo That Makes AI Work Survive the Chat Window

A Go orchestration stack where tasks live in Beads, agents run in sandboxes, and least-privilege proxies keep multi-agent coding from collapsing into context loss.

12 min read • View on GitHub • More from gastownhall

A wide black-ink illustration of a control room that feels like a city planning desk. Small agent stations orbit a central ledger while routes branch into separate workspaces and return with updates, explaining that Gas Town treats coding work as something scheduled and routed, not trapped inside one chat. — Gas Town's core move is to treat work like a managed system, not a conversation.

Key Takeaways

Gas Town treats an AI task as a persistent object, so work can outlive any single chat session.
Beads, worktrees, and a locked-down proxy turn agent coding into managed infrastructure instead of improvisational prompting.
Its real differentiator is coordination durability, not a prettier editor or a smarter chat window.
The system is built for long-horizon coding work that must survive crashes, handoffs, and partial failure.

A task that survives the chat

Gas Town's best idea is brutally simple. It refuses to let work disappear when a chat session does. A task becomes a durable object, with state, routing, and recovery attached to it from the start.

That changes the shape of the system. Instead of asking a model to remember everything, Gas Town writes the job into Beads, hands it to an agent, and keeps the thread outside the context window. The result is less like a clever prompt loop and more like an operating model for AI labor.

Gastown inverts this architecture: work is attached directly to the agents and executes itself.

Stanislav Huseletov, Author, Trilogy AI · Deep Dive: Gastown

Why ordinary agent loops collapse

Most agent systems fail for the same three reasons. The orchestrator becomes a bottleneck, the context window becomes a memory ceiling, and the sandbox becomes disposable. Once one of those breaks, the rest of the work turns into archaeology.

A close-up illustration of a single Bead clipped to a Git worktree like a stamped metal tag on a machine part. An agent steps away in the background, but the tagged task remains lit and intact, showing how Gas Town preserves work even when a session ends. — The task object stays alive even when the session does not.

Gas Town answers with a recovery hierarchy that reads like urban planning but behaves like systems software. The Mayor, Witness, Deacon, rigs, polecats, and Beads are not decorative names. They are a vocabulary for persistence, supervision, and handoff.

Inside the machine room

The core lives in Go, and the structure is disciplined. `internal/beads/` wraps the Beads ledger, sometimes dropping below the CLI and talking to `beadsdk` directly to save overhead. `cmd/gt-proxy-server` exposes an mTLS-protected command gateway with a hard allowlist, so a sandboxed agent can ask for the right action and nothing more.

The workflow layer is equally concrete. `internal/beads/molecule.go` turns Markdown-like issue descriptions into executable steps, dependencies, tiers, and backoff rules. `internal/agent/state.go` persists progress into `.runtime/state.json`, so a crashed watcher can resume exactly where it stopped.

Gas Town's key move is to separate the task from the session, then make recovery part of the default path.

A split black-ink illustration that contrasts a fading chat window on the left with a disciplined multi-agent workshop on the right. The left side loses context as notes scatter, while the right side keeps tasks, sandboxes, and a ledger connected in orderly paths, clarifying why Gas Town is about coordination durability. — Gas Town replaces fragile chat loops with a managed workforce.

What Gas Town replaces, and what it is not

Project	Coordination model	State persistence	Failure mode	Best fit
Gas Town	Task-led, multi-agent orchestration	Beads + Git-backed memory + state files	Setup complexity and more moving parts	Long-horizon coding with handoffs
Cursor	Single developer in an AI editor	Local project context	Human still carries coordination	Fast edits and inline assistance
Aider	CLI pair-programming loop	Conversation plus direct repo edits	Sessions drift when work gets large	Focused refactors in one repo
AutoGen / LangChain	General agent graphs	Custom, if you build it	Glue code and abstraction drift	Prototyping orchestration patterns
Claude Code	Strong standalone coding agent	Session-centric	Recovery lives outside the tool	Direct coding assistance

This is not a better editor story. It is a coordination story. Cursor and Aider are strong at interactive loops, but Gas Town is built for the cost of long-horizon work, especially when the same task must survive restarts, handoffs, and partial failure. That is a different class of problem.

The bigger bet

Gas Town feels less like a coding app and more like an operating model. Its city metaphor matters because it teaches the right mental model: agents are not chats, they are workers with state, permissions, and supervision.

That is the bet underneath the whole repo. If managed software work is going to be done by agents, then the unit of control cannot be the transcript. It has to be the task. Gas Town is one of the clearest attempts to build that future into infrastructure instead of interface polish.