Mayor, Crew, and Polecats — The Three-Tier Agent Hierarchy¶
Source: Steve Yegge, "Welcome to Gas Town," Jan 1, 2026; "Gas Town Emergency User Manual," Jan 13, 2026
Related: steve-yegge-gas-town, steve-yegge-gupp, steve-yegge-meow
Overview¶
Gas Town's most immediately recognizable architectural decision is its deliberate hierarchy of agent roles,，拒绝 the flat "swarm of identical agents" model that most multi-agent frameworks default to. Instead of treating all agents as equivalent nodes in a swarm, Gas Town defines three distinct tiers with different lifespans, responsibilities, visibility, and degrees of autonomy.
This hierarchy is not accidental. It emerged from Yegge's observation that flat agent swarms fail in predictable ways: work doesn't get decomposed properly, quality gates get skipped under pressure, and there's no clear owner for any given piece of work. A hierarchy forces these concerns to be addressed by design.
Tier 1: The Mayor¶
Role: Orchestrator, user's primary interface, chief-of-staff
Lifespan: Long-lived (one per user/Rig)
Visibility: Fully visible; the user's primary contact
The Mayor is the user's primary interface with the entire Gas Town system. This is the most conceptually important role in Gas Town — Yegge identifies it as the killer feature.
The Mayor's job is not to do the work. It's to read all the agent babble so the human doesn't have to. In a system with 20–30 concurrent agents all producing output, the noise is overwhelming. The Mayor is the filter: it reads everything, extracts what's relevant for the human, and surfaces only that.
Yegge frames the Mayor as a Chief of Staff, not an Executive Assistant. An Executive Assistant does tasks for you. A Chief of Staff manages the information flow so you can make decisions. The Mayor's value is in what it removes from your attention, not what it produces.
Concretely, the Mayor:
- Reads all Crew and polecat output and synthesizes summaries
- Handles user intent — parsing vague instructions and routing them appropriately
- Maintains the big picture context that ephemeral polecats lose when they die
- Escalates novel situations that require human judgment
The Mayor is the control plane for the human. Everything the human needs to know flows through the Mayor. Everything the human wants done flows through the Mayor.
Tier 2: The Crew¶
Role: Named, long-lived per-Rig agents for sustained domain work
Lifespan: Long-lived per session, named and addressable
Visibility: Fully visible, semi-permanent
The Crew consists of named, persistent agents that handle sustained, interactive work on a specific domain. Where the Mayor is a generalist orchestrator, Crew members are specialists.
Examples from the Emergency User Manual:
- PR Sheriff — a Crew member with permanent standing orders to triage and merge easy PRs on startup. It watches the PR queue and handles routine merges autonomously, freeing the human from maintenance work.
- Design Agent — a Crew member for handling UI/UX design work that requires back-and-forth iteration
- Research Agent — a Crew member that handles exploratory research that may take days and produce non-linear output
The Crew's defining characteristic is persistence and nameability. They maintain context across sessions (via Beads), they are addressable by the user ("ask the PR Sheriff to..."), and they build up a working relationship with the project over time.
The Rig Cycling pattern applies to Crew: the Mayor loops through all Crew members, assigns them tasks, lets them work, then reviews results. This is analogous to Bezos's management style of reviewing written presentations from direct reports — structured, predictable, high-throughput.
Tier 3: Polecats¶
Role: Ephemeral task agents — given a Bead and let loose
Lifespan: Short; created for a specific Bead, die when the Bead is done
Visibility: Mostly invisible; the "dark" in dark factory
Polecats are Gas Town's ephemeral execution layer. Given a well-specified Bead, a polecat is pointed at it and left to work — unmonitored, unfiltered, with minimal human oversight. They are the "dark" in the dark factory: you don't normally look in on them.
Polecats are contrasted with the Crew's interactive, review-driven workflow. Polecats operate in convoy mode: a batch of well-specified Bead epics is handed to a team of polecats, who work through them in coordinated parallel. The Mayor (via the Refinery) ensures the Beads are well-specified before the polecats are unleashed.
The polecat's philosophy is that most agents should be polecats. The majority of work in a well-functioning dark factory is routine, well-specified, and doesn't require human review. Polecats handle this volume efficiently. Crew handles the exceptions — the ambiguous tasks, the design work, the ones that need back-and-forth.
The failure mode of polecats is worker corpses — polecats that have stopped processing but haven't been cleaned up. This is the problem the Deacon solves (see below).
Supporting Roles¶
The three-tier hierarchy is supported by four daemon/utility roles:
Refinery¶
Decomposes vague epics (user-level intentions) into well-specified Bead sequences that polecats can execute. The Refinery is where ambiguous human intent becomes structured work. This is the "planner" function in Gas Town's pipeline.
Witness¶
Quality auditor that watches all workers and validates their output. The Witness is the gate in the system — no Bead is marked done without passing the Witness's quality criteria. This is Gas Town's implementation of multi-agent adversarial review (see steve-yegge-gas-town).
Deacon¶
Patrol daemon that keeps workers from going stale. If a polecat's hook has been non-empty for too long (GUPP timeout), the Deacon kills the polecat and re-queues the Bead. See steve-yegge-gupp for the GUPP enforcement mechanism.
Boot¶
Daemon handling heartbeats so the Deacon isn't interrupted. Heartbeat traffic is offloaded to Boot so the Deacon can focus on its patrol function without being distracted by routine liveness pings.
Hierarchy Comparison¶
| Role | Lifespan | Visibility | Autonomy | Kelly Equivalent |
|---|---|---|---|---|
| Mayor | Long | High (user-facing) | High (intent parsing) | Router/Manager agent |
| Crew | Long | High (addressable) | Medium-High (interactive) | Persistent agent sessions |
| Polecats | Short | Low (dark factory) | High (unmonitored execution) | Sub-agents spawned for tasks |
| Refinery | Daemon | Internal | Medium (decomposition) | Kelly's pipeline planning stages |
| Witness | Daemon | Internal | High (quality gate) | Kelly's Gate pattern / 5-agent verdict |
| Deacon | Daemon | Internal | Medium (timeout enforcement) | heartbeat liveness detection |
Kelly Parallel¶
Kelly's router/subagent pattern maps loosely to Gas Town's Mayor:
| Gas Town Role | Kelly Equivalent |
|---|---|
| Mayor (control plane, user interface) | Router agent — filters context, routes to sub-agents, maintains session state |
| Mayor (Chief of Staff framing) | No direct Kelly equivalent — Kelly's router is more mechanical; Mayor has more editorial judgment |
| Crew (named, persistent domain agents) | Persistent agent sessions in Kelly's multi-agent architecture — agents that maintain context across the session |
| Polecats (ephemeral unmonitored workers) | Sub-agents spawned for tasks — Kelly's transient sub-agents that run to completion and die |
| Refinery (intent → Bead decomposition) | Kelly's Intake → Planning subphases — vague requirements get refined into actionable pipeline stages |
| Witness (quality gate) | Kelly's Gate pattern or 5-agent verdict (Angry Mob) — external validation before proceeding |
| Deacon (stuck worker cleanup) | Kelly's heartbeat check-in + timeout enforcement — liveness detection + remediation |
| Boot (heartbeat offload) | No Kelly equivalent — heartbeat handling is distributed across agents rather than isolated to a daemon |
Key gap: Kelly's router doesn't have a "Mayor-like" editorial function. Kelly's router is primarily a routing mechanism (which sub-agent to spawn), not an information filter for the human. The Mayor's role as Chief of Staff — reading all agent output and surfacing only what matters — is a distinctly Gas Town innovation that Kelly's system doesn't explicitly address. A Kelly-style factory would benefit from a Mayor-equivalent to handle the information overload problem as agent count scales.
Key distinction: Kelly's sub-agents are unnamed and interchangeable. Gas Town's Crew members are named, persistent, and addressable — they build up context and domain expertise over time. This is closer to Kelly's "persistent sessions" concept but made more concrete with naming and addressability.
Source Attribution¶
- Steve Yegge, "Welcome to Gas Town," Jan 1, 2026 — Mayor, Crew, Polecats, Refinery, Witness, Deacon introduced
- Steve Yegge, "Gas Town Emergency User Manual," Jan 13, 2026 — PR Sheriff, Rig Cycling, Convoys operationalized
Bibliography¶
- Steve Yegge, "Welcome to Gas Town," Jan 1, 2026
- Steve Yegge, "Gas Town Emergency User Manual," Jan 13, 2026