Steve’s Term</th>	Real-World Definition</th>	Alternative Term</th></tr></thead>
Town</td>	Top-level folder containing your individual projects. The `gt</code> binary manages projects under this folder.</td>`	Workspace</td></tr>
Rig</td>	A project. It’s a folder tracked by a unique Git repository within your workspace.</td>	Project</td></tr>
Overseer</td>	The user (you). You have an “inbox” to receive notifications from agents in your projects.</td>	User</td></tr>
Mayor</td>	The managing agent for a project. Usually you send this agent messages, and it coordinates the work of other agents in the project.</td>	Manager Agent</td></tr>
Polecat</td>	Worker agent, taking commands from the mayor, doing some work, submitting a Merge Request, and then stopping.</td>	Worker Agent</td></tr>
Refinery</td>	Merge agent, who coordinates and makes decisions about merge requests coming from Worker Agents.</td>	Merge Agent</td></tr>
Witness</td>	Fixer agent, that watches the worker agents and tries to fix any that are stuck.</td>	Fixer Agent</td></tr>
Deacon</td>	Maintenance agent, runs a consistent workflow in a loop, unlike “worker agents” who do arbitrary tasks and then die.</td>	Maintenance Manager Agent</td></tr>
Dogs</td>	Maintenance worker agents who do cleanup tasks, directed by the Maintenance Agent.</td>	Maintenance Worker Agents</td></tr>
Boot the Dog</td>	Maintenance Manager checker agent, just checks on the Maintenance Manager Agent periodically to see if it needs a reboot or anything else.</td>	Maintenance Manager Checker Agent</td></tr>
Crew</td>	Persistent Worker Agents, which you talk to directly (not through the Mayor), and which persist after their tasks are done, to be reused. These are per-Project.</td>	Persistent Worker Agents.</td></tr>
Beads</td>	System for tracking work history across the system.</td>	Work Tracker</td></tr>
Rig Beads</td>	Project-specific work, tracked in the Work Tracker.</td>	Project Work</td></tr>
Town Beads</td>	Whole-workspace work, tracked in the Work Tracker.</td>	Workspace Work</td></tr> </tbody></table> Even with these definitions and alternative terms, Gas Town is still a bit of a mess, with watchers-on-watchers at times (do we really need a Maintenance Manager Checker Agent?). That said, hopefully this decoder at least makes understanding what Gas Town is</em> easier.</p>

Andrew Lilley Brinker - AI

Move Over Gas Town, Claude Has First-Party Agent Orchestration

2026-02-05T00:00:00+00:00

While Gas Town</a>, the hallucinatory fever dream / slopware project by Steve Yegge, was first on the scene for agent orchestration, it was never going to be the end. Gas Town, as Yegge himself admitted, is an experiment intended to explore the limits and problems of agent orchestration without concern for cost or quality. It would never work as a serious professional tool.

Today, Anthropic announced an experimental alternative for agent orchestration, which they call “Agent Teams.”</a> This is actually the second system Claude has grown for orchestration, the first being “subagents.”</a>

In Agent Teams, one agent oversees a collection of worker agents. The worker agents all maintain their own independent context, and can message between each other to coordinate work. Per Anthropic’s documentation, Agent Teams are best deployed in contexts where they can work on independent efforts on a shared codebase without overlapping.

By contrast, subagents work serially, and share context, with each subagent being specialized for specific tasks. They’re intended to be used in contexts where you have a single problem or series of tasks which benefit from specialization, but which require coordination and shared state between agents. Subagents, unlike Agent Teams, are not considered experimental.

I doubt that Agent Teams will be the final word from Anthropic on multi-agent orchestration, but I am both glad to see Anthropic pursuing a first-party solution in this space, and unsurprised.

Back in the era of containers, Docker had first-mover advantage and were in position to develop a strong first-party solution for container orchestration. Unfortunately, despite efforts in that area, they were unable to satisfy the needs of their users, leaving room for Kubernetes to emerge and take pole position, which limited Docker, Inc.’s ability to monetize that opportunity.

With that well-known example in mind, it was hard to imagine that Anthropic would risk missing the train on agent orchestration by not developing first-party solutions.

It’s doubtful this is the last option we’ll see in the agent orchestration space. Users and AI companies are still figuring out the pitfalls and what seems to work well for coordinating the work of multiple agents. As we’ve seen with Gas Town, solutions which involve the application of ever more specialized agents can become quite expensive!

Agent Teams certainly have fewer unique agent roles compared to Gas Town, and we’ll see what impact (if any) that has on the ability of the agents to remain on-task over time and to coordinate on work.

Gas Town is not Urbit

2026-01-15T00:00:00+00:00

Yesterday I wrote “Gas Town Decoded,”</a> a brief guide to the insular language Steve Yegge uses to describe Gas Town</a>. Gas Town, for those out of the loop, is Yegge’s attempt to build a system for AI agent orchestration.
Today, Steve Klabnik wrote “How to think about Gas Town,”</a> which analyzes why Gas Town chose to use such strange language in the first place. It’s a great piece, and one with which I agree. You should read it!
In discussions around Gas Town, I and many others have noted the parallels to another infamous software system that used insular language: Urbit.
While it’s true that both Gas Town and Urbit invent their own language specific to their projects, they are otherwise extremely different. Urbit is fascist, Gas Town is not.
As Klabnik describes in his piece, Gas Town’s insular language is used by Yegge to signpost the experimental nature of the project and to discourage production use. Klabnik argues Yegge did this because, as someone who is programmer-famous, he knows anything he works on will be taken seriously by others.
Urbit, on the other hand, used insular language to create a sense of exclusivity and complexity, as part of Curtis Yarvin’s attempt to gain an audience for his fascist political ideas. Throughout the 2010’s, Yarvin leveraged Urbit to gain entry to programmer forums and conferences, where he could then spread his politics alongside his software.
So, while it’s true both Gas Town and Urbit use insular language, we shouldn’t consider them similar beyond that.

Gas Town Decoded

2026-01-14T00:00:00+00:00

On January 1st, Steve Yegge published “Welcome to Gas Town,”</a> an introduction to his new AI agent orchestration tool written in a loose and chaotic mode, and accompanied by AI-generated images depicting a fictional industrial city populated with weasels (yes, really).
Reactions were swift, mostly agog at the scale and hubris of such a (self-admittedly) wasteful and obscenely expensive system, and alternately confused or amazed at the amount of new, insular language tailor-made to describe it.
In the interest of making Gas Town intelligible (because, despite the prose, the idea of agent orchestration it describes will be important), I’d like to share a quick decoder for the many new terms Steve introduces. His article itself offers definitions, but those definitions reuse his insular terms, making by-hand decoding tedious. Here, I’ve done the work for you.
Steve’s Term</th> Real-World Definition</th> Alternative Term</th></tr></thead>

Town</td> Top-level folder containing your individual projects. The gt</code> binary manages projects under this folder.</td> Workspace</td></tr>
Rig</td> A project. It’s a folder tracked by a unique Git repository within your workspace.</td> Project</td></tr>
Overseer</td> The user (you). You have an “inbox” to receive notifications from agents in your projects.</td> User</td></tr>
Mayor</td> The managing agent for a project. Usually you send this agent messages, and it coordinates the work of other agents in the project.</td> Manager Agent</td></tr>
Polecat</td> Worker agent, taking commands from the mayor, doing some work, submitting a Merge Request, and then stopping.</td> Worker Agent</td></tr>
Refinery</td> Merge agent, who coordinates and makes decisions about merge requests coming from Worker Agents.</td> Merge Agent</td></tr>
Witness</td> Fixer agent, that watches the worker agents and tries to fix any that are stuck.</td> Fixer Agent</td></tr>
Deacon</td> Maintenance agent, runs a consistent workflow in a loop, unlike “worker agents” who do arbitrary tasks and then die.</td> Maintenance Manager Agent</td></tr>
Dogs</td> Maintenance worker agents who do cleanup tasks, directed by the Maintenance Agent.</td> Maintenance Worker Agents</td></tr>
Boot the Dog</td> Maintenance Manager checker agent, just checks on the Maintenance Manager Agent periodically to see if it needs a reboot or anything else.</td> Maintenance Manager Checker Agent</td></tr>
Crew</td> Persistent Worker Agents, which you talk to directly (not through the Mayor), and which persist after their tasks are done, to be reused. These are per-Project.</td> Persistent Worker Agents.</td></tr>
Beads</td> System for tracking work history across the system.</td> Work Tracker</td></tr>
Rig Beads</td> Project-specific work, tracked in the Work Tracker.</td> Project Work</td></tr>
Town Beads</td> Whole-workspace work, tracked in the Work Tracker.</td> Workspace Work</td></tr> </tbody></table>
Even with these definitions and alternative terms, Gas Town is still a bit of a mess, with watchers-on-watchers at times (do we really need a Maintenance Manager Checker Agent?). That said, hopefully this decoder at least makes understanding what Gas Town is easier.