The Gas Town Mayor Pattern — Information Filter, Not Router¶
Type: Orchestration pattern
Related: steve-yegge-hierarchy, steve-yegge-gas-town, kelly-gas-town-gap-analysis, kelly-router, gas-town-daemon-architecture
Overview¶
The Mayor is the most conceptually important role in Gas Town. Steve Yegge calls it "the killer feature" — not observability dashboards, not activity feeds, not the Beads substrate. Just less reading.
In a system running 20–30 concurrent agents all producing output, the noise is overwhelming. The Mayor reads all of it so the human doesn't have to. It surfaces only what matters, when it matters.
The critical distinction: the Mayor is NOT the Router. They serve completely different functions in the architecture. The similarity in name is misleading.
Mayor vs Router: The Fundamental Distinction¶
| Aspect | Router | Mayor |
|---|---|---|
| Direction | Upstream (decomposition) | Downstream (filtering) |
| Input | Human intent | Agent output |
| Output | Bead sequences for agents | Summaries for the human |
| Function | "What work needs to be done?" | "What does the human need to know?" |
| Analogy | Project manager assigning tasks | Chief of Staff briefing the executive |
| When it acts | Before work happens | After work happens |
The Router Decomposes Upstream¶
The Router receives a vague instruction from the human ("build me a competitor to X") and decomposes it into specific, actionable work items. It decides what gets done, who does it, and in what order. The Router is the factory's engine.
In Kelly, the Router is the main agent session that reads AGENTS.md, spawns named leads (kelly-router), validates quality gates, and advances pipeline stages. It never executes work — it orchestrates.
The Mayor Filters Downstream¶
The Mayor receives the output of 20–30 agents and decides what the human needs to see. It does not decompose work. It does not spawn agents. It does not validate quality gates. It reads everything and tells the human only what matters.
[Human Intent]
│
▼
┌────────┐
│ Router │ ← decomposes intent into work
└───┬────┘
│ bead sequences
▼
┌─────────────┐
│ Agents Work │ (polecats, crew)
└───┬─────────┘
│ raw output (20-30 streams)
▼
┌────────┐
│ Mayor │ ← filters output for human
└───┬────┘
│ curated summary
▼
[Human Sees This]
The Chief of Staff Model¶
Yegge frames the Mayor explicitly as a Chief of Staff, not an Executive Assistant:
| Chief of Staff | Executive Assistant |
|---|---|
| Manages information flow | Executes tasks |
| Surfaces decisions needed | Handles scheduling |
| Maintains strategic context | Handles logistics |
| Filters noise | Routes requests |
| You make the calls | They make the calls |
The Mayor-as-Chief-of-Staff means:
- The Mayor doesn't decide for you — it presents the information you need to decide
- The Mayor maintains context — it knows what all 30 agents are doing and why
- The Mayor filters aggressively — if 27 agents are fine and 3 have problems, you hear about 3
- The Mayor escalates novel situations — things it hasn't seen before go directly to the human
How the Mayor Differs from Refinery and Deacon¶
The Mayor, Refinery, and Deacon all interact with agent output, but in fundamentally different ways:
Mayor vs Refinery¶
| Aspect | Mayor | Refinery |
|---|---|---|
| Timing | After work | Before work |
| Direction | Downstream filter | Upstream decomposer |
| Input | Completed beads | Vague epics |
| Output | Human-digestible summary | Specific bead sequences |
| Question answered | "What happened?" | "What should happen?" |
Refinery turns vague intent into specific work. Mayor turns specific output into curated insight. They are complementary, not overlapping.
Mayor vs Deacon¶
| Aspect | Mayor | Deacon |
|---|---|---|
| Concern | Information quality | Agent liveness |
| Detects | What matters | What's stuck |
| Acts on | Content of output | State of agents |
| Output | Summary for human | Re-queue / kill / escalate |
| Frequency | On completion | Continuous patrol |
The Deacon doesn't care what the agent produced — only whether it's still producing. The Mayor doesn't care whether the agent is alive — only whether its output matters to the human.
The Three Together¶
Refinery: "Here's what needs to happen" (upstream)
│
▼
[Agents Work]
│
├──→ Deacon: "These agents are stuck" (patrol)
│
└──→ Mayor: "Here's what you need to know" (downstream)
Information Filtering in Practice¶
What the Mayor Reads¶
- Every bead completion event
- Every quality alert from Witness
- Every stale alert from Deacon
- Every Refinery scheduling decision
- Every agent error and retry
What the Mayor Surfaces¶
The Mayor applies a filtering heuristic:
| Situation | Mayor Action |
|---|---|
| Agent completed successfully, no issues | Suppress — don't bother the human |
| Agent completed, minor quality warnings | Suppress — log for later, don't interrupt |
| Agent failed, RALPH retry in progress | Suppress — let RALPH handle it |
| Agent failed, RALPH escalating | Surface — human needs to know |
| Witness detected drift | Suppress if minor, surface if significant |
| Novel situation (Mayor hasn't seen this pattern) | Surface — always escalate the unknown |
| All agents idle, no work | Surface — human needs to assign work |
| Major milestone reached | Surface — human should see progress |
Summary Format¶
The Mayor produces structured summaries:
## Factory Status — 2026-05-27 18:00
**Active:** 12 agents working, 3 idle
**Completed since last update:** 8 beads
**Issues:** 1 (research agent timeout on bead #447 — RALPH retry 2/3)
### Needs Your Attention
- 🔴 Bead #447: Research task stuck after 2 retries. Error: "context window exceeded"
→ Recommendation: Split into smaller research tasks
### Progress (no action needed)
- ✅ Competitor analysis complete (3/3 agents finished)
- ✅ PRD draft ready for review
- ✅ Architecture doc in review (waiting 2 hours)
Implementation: Router Plays Mayor in Kelly¶
In the current Kelly factory, there is no separate Mayor agent. The Router plays the Mayor role — it reads sub-agent output and summarizes it before surfacing to the operator.
This is a pragmatic compromise: the Router already sees all sub-agent output (because it spawned them), so adding a filtering step is architecturally simple. However, it conflates two distinct concerns:
| Conflated Concern | Risk |
|---|---|
| Routing + filtering | Router may prioritize routing over filtering under load |
| Decomposition + summarization | Different cognitive modes; one may degrade |
| Upstream + downstream | Single point of failure for both directions |
Future: Dedicated Mayor Agent¶
As agent count scales beyond what a single Router can manage, the Kelly factory should consider separating the Mayor into its own agent:
[Human]
│
├──→ [Mayor] ← reads all output, surfaces summary
│
└──→ [Router] ← decomposes work, spawns agents
│
▼
[Agents]
The Mayor would be a lightweight, long-lived agent that:
- Subscribes to all bead completion events
- Maintains a rolling summary of factory state
- Applies filtering heuristics (configurable per human preference)
- Surfaces alerts via Discord / direct message
- Never spawns agents or does work
Yegge's 2026 Prediction¶
From "Gas Town: from Clown Show to v1.0" (Apr 3, 2026):
"By end of year, people will mostly program by talking to a face. No typing. Chat with your Mayor like a person."
The Mayor is the interface. The agents are the engine. The human talks to the Mayor; the Mayor talks to the factory.
Kelly Adoption Status¶
From kelly-gas-town-gap-analysis, the Mayor pattern has High adoption potential:
| Aspect | Current Kelly State | Gap |
|---|---|---|
| Information filtering | Router does this implicitly | Needs explicit filtering logic |
| Chief-of-staff framing | Not present | Needs conceptual adoption |
| Novel-situation escalation | Not explicit | Needs heuristic for "unseen" patterns |
| Summary formatting | Ad-hoc in Router output | Needs structured summary template |
Recommendation: Add explicit Mayor-equivalent information filtering to the Kelly Router — either as enhanced Router logic (near-term) or as a dedicated Mayor agent (long-term). The filtering heuristic and summary format can be adopted immediately without infrastructure changes.
Related Articles¶
steve-yegge-hierarchy, steve-yegge-gas-town, kelly-router, gas-town-daemon-architecture, kelly-deacon-architecture, gas-town-naming-conventions, kelly-gas-town-gap-analysis
Source Attribution¶
- Steve Yegge, "Welcome to Gas Town," Jan 1, 2026 — Mayor role introduced
- Steve Yegge, "Gas Town: from Clown Show to v1.0," Apr 3, 2026 — Mayor as killer feature, 2026 prediction
- Steve Yegge, "Welcome to Gas City," Apr 24, 2026 — Mayor in Gas City architecture
- steve-yegge-hierarchy — Mayor tier in the three-tier hierarchy
- kelly-gas-town-gap-analysis — Mayor adoption potential for Kelly
- q-kelly-router-spawn-vs-gas-town-mayor — Router vs Mayor comparison query