Kiloclaw as Meta-Mayor — fleet coordinator across multiple Gastown towns

[jrf0110]

Parent

Sub-issue of #447 (Future Ideas)

Overview

A single Kiloclaw instance acts as a fleet coordinator across multiple Gastown towns. For an org with several towns (frontend, backend, infra, mobile), the Kiloclaw meta-Mayor has MCP access to every town's API and can orchestrate cross-town work, monitor fleet health, and coordinate dependencies between teams.

This is distinct from each town's built-in Mayor (which only sees its own town). The meta-Mayor sees everything and can direct work across the entire fleet.

What the Meta-Mayor Can Do

Cross-town work coordination

• "I need a full-stack feature that touches the frontend, backend, and infra repos" → meta-Mayor creates convoys in each town's Mayor via API, tracks progress across all of them
• "The backend API is changing — tell the frontend town to hold off on the auth integration" → meta-Mayor sends messages to individual town Mayors
• "All towns: run your test suites against the staging branch" → fan-out commands

Fleet health monitoring

• Query all towns' bead boards, agent rosters, and review queues in one view
• "What's the status of everything?" → aggregated summary across all towns
• Detect cross-town blockers: "Frontend town is waiting on the API spec that backend town hasn't finished"
• Alert on anomalies: "Backend town has had 5 failed beads in the last hour, the other towns are fine"

Cross-town dependency management

• Track dependencies that span towns (e.g., "the mobile deploy can't happen until the backend API and frontend SDK are both merged")
• When a dependency is met in one town, notify the dependent town to proceed

Org-level reporting

• "How much did we spend across all towns this week?"
• "Which town has the highest rework rate?"
• "What did the fleet accomplish today?" → daily summary across all towns

Integration Mechanism: Gastown MCP Server

The meta-Mayor connects to each town via an MCP server that exposes the Gastown HTTP API as MCP tools. This MCP server is either:

1. A single MCP server with multi-town support — one server, configured with credentials for N towns. Tools are prefixed by town: frontend.list_beads, backend.sling, infra.convoy_status.
2. One MCP server per town — the Kiloclaw instance has N MCP server connections. Each server exposes the same tool set scoped to its town.

Option 2 is simpler and more modular — adding a new town means adding a new MCP server connection to the Kiloclaw instance, not reconfiguring a multi-tenant server.

MCP tools exposed per town

These map directly to the existing Gastown HTTP API and Mayor tool set:

MCP Tool	Maps to	Purpose
list_beads	GET /api/towns/:townId/rigs/:rigId/beads	Query bead board
list_agents	GET /api/towns/:townId/rigs/:rigId/agents	Query agent roster
list_convoys	Town RPC listConvoys	Query convoy status
sling	Town RPC slingBead	Create a bead in a town
sling_batch	Town RPC slingConvoy	Create a convoy in a town
send_mayor_message	Town RPC sendMayorMessage	Talk to a town's Mayor
get_town_status	Town RPC getAlarmStatus	Get alarm loop health
list_rigs	Town RPC listRigs	Query rig configuration
convoy_status	Town RPC getConvoyStatus	Get detailed convoy progress

The meta-Mayor doesn't replace individual town Mayors — it delegates to them. "Frontend Mayor, please start working on the new auth flow" is a send_mayor_message call. The town Mayor handles the decomposition and agent management within its town.

Kiloclaw Configuration

The meta-Mayor Kiloclaw instance would have:

• Custom instructions: "You are a fleet coordinator for an org's Gastown towns. You can see and direct work across all towns. Delegate implementation details to individual town Mayors. Focus on cross-town coordination, dependency tracking, and fleet health."
• MCP servers: One per town, each authenticated with the user's Gastown credentials
• Persistent memory: Kiloclaw natively persists conversation history — the meta-Mayor remembers past cross-town coordination decisions, what worked, what didn't

User Experience

The user talks to their Kiloclaw meta-Mayor from the Kiloclaw chat interface (not from within any specific Gastown town). The conversation feels like talking to a VP of Engineering AI:

User: I need to ship the new payments feature by Friday. It needs changes to 
      the backend API, the frontend checkout flow, and the mobile app.

Meta-Mayor: I'll coordinate this across your three towns. Here's my plan:

  1. Backend town: I'll ask the Mayor to create a convoy for the payments API 
     endpoints — new routes, Stripe integration, and webhook handlers.
  
  2. Frontend town: Once the backend API spec is defined (after the first backend 
     bead), I'll ask the Frontend Mayor to start on the checkout UI components.
  
  3. Mobile town: The mobile SDK update depends on both the backend API and the 
     frontend component library. I'll queue this for after both are merged.

  Shall I kick this off?

User: Go for it.

Meta-Mayor: Done. I've created:
  - Backend: "Payments API" convoy (5 beads) — Toast is working on the first one
  - Frontend: Staged convoy ready to start once the API spec bead closes
  - Mobile: Staged convoy, will start after backend + frontend land
  
  I'll monitor progress and notify you of any blockers.

Prerequisites

• Gastown HTTP API / tRPC procedures must be accessible with user auth tokens (most already are)
• An MCP server package that wraps the Gastown API (new — does not exist today)
• Kiloclaw must support multiple MCP server connections (verify current capability)

Acceptance Criteria

• Gastown MCP server package that exposes town operations as MCP tools
• MCP server authenticates with user credentials and scopes to a single town
• Kiloclaw instance can connect to multiple Gastown MCP servers (one per town)
• Meta-Mayor can query bead boards, agent rosters, and convoy status across all connected towns
• Meta-Mayor can create beads and convoys in any connected town
• Meta-Mayor can send messages to individual town Mayors
• Meta-Mayor can track cross-town dependencies (at minimum via conversation memory)
• Documentation for users on how to set up their Kiloclaw instance as a meta-Mayor

Notes

• The Gastown MCP server is independently useful — it also enables the "Kiloclaw as Mayor" integration for single towns, and could be used by any MCP-compatible agent (not just Kiloclaw)
• The meta-Mayor doesn't need Gastown-specific UI — it uses the existing Kiloclaw chat interface
• Cross-town convoy tracking (formally linking convoys across towns with dependency edges) is out of scope — the meta-Mayor tracks this conversationally via its persistent memory. Formal cross-town dependencies can be added later.
• This is the org-level fleet coordination described in Cloud Gastown: Future ideas — capabilities unique to or enhanced by the cloud model #447 and plans/gastown-org-level-architecture.md, but implemented as an AI agent rather than a dashboard