[Gastown] PR 11: Mayor Agent

[jrf0110]

Parent: #204 | Phase 2: Multi-Agent Orchestration

Revised: Moved from Phase 3 to Phase 2. The Mayor is now a demand-spawned Kilo CLI process inside the Town Container, not a DO-controlled loop with on-demand cloud-agent-next sessions. The DO is the persistent memory; the Mayor agent is an ephemeral reasoning process.

Goal

The Mayor is an agent process inside the town container that coordinates work across rigs. It is spawned on demand when there is work requiring LLM reasoning.

Design

The Mayor is demand-spawned — the Rig/Town DO alarm starts a Mayor process in the container when:

• A user sends a message (message bead created via sendMessage tRPC)
• An escalation is routed to the Mayor (mail delivered)
• A convoy needs coordination

The Mayor process runs until its work is complete, then calls gt_done and exits. There is no persistent Mayor session — the DO state provides continuity between Mayor invocations. The Mayor's gt_prime context includes full town state so it can resume from where it left off.

This avoids the "Mayor session persistence" problem entirely. The DO is the persistent memory; the Mayor agent is an ephemeral reasoning process.

New Tools for Mayor Role

Tool	Description
gt_sling	Create bead and assign to a polecat in a rig
gt_convoy_create	Create a convoy with multiple beads
gt_convoy_status	Check convoy progress
gt_rig_status	Get summary of a rig's state (agents, beads, review queue)

Mayor System Prompt

The Mayor's system prompt needs to understand:

• The full Gastown model (towns, rigs, beads, agents, convoys)
• How to break down work into appropriately-sized beads
• Delegation strategy (which rig, which model, priority)
• Escalation triage (severity assessment, response recommendations)
• That it is ephemeral — DO state is its persistent memory, gt_prime restores context

Mayor Lifecycle

User sends message → tRPC → message bead created → alarm fires
  → DO signals container: start Mayor process
  → Mayor calls gt_prime → gets full town context + message
  → Mayor reasons, calls gt_sling / gt_convoy_create / etc.
  → Tool calls → DO RPCs → state updated
  → Mayor calls gt_done → process exits
  → Next message → cycle repeats, Mayor gets updated context via gt_prime

Dependencies

• PR 4 (Town Container)
• PR 5 (Rig DO Alarm)
• PR 3 (Tool Plugin)
• PR 9 (Town DO — for cross-rig context)

Acceptance Criteria

• Mayor tools added to plugin (gt_sling, gt_convoy_create, gt_convoy_status, gt_rig_status)
• Mayor system prompt
• DO alarm dispatches Mayor to container on message/escalation/convoy events
• Mayor gt_prime returns full town context (rigs, agents, beads, convoys, pending mail)
• Work decomposition: complex request → multiple beads via gt_sling
• Convoy creation via gt_convoy_create
• Mayor process exits cleanly after completing work

[jrf0110]

Closing this issue — the design has been superseded by the Mayor-per-Town architecture.

Problem with old design: This issue specified the Mayor as a per-rig, demand-spawned ephemeral agent that creates a bead for every user message. This diverges from the Gastown spec where the Mayor is a town-level singleton coordinator.

New design: The Mayor is being extracted to a dedicated MayorDO (keyed by townId) with a persistent conversational session. Messages to the mayor no longer create beads — the mayor decides when to delegate work via tools (gt_sling, gt_convoy_create, etc.).

See the replacement issue for the new MayorDO design.