Skip to main content

The Fleet & the Tower

One SLAW instance is a squad. Ten instances across an engineering organisation is a fleet. The Tower is how you see and govern all of them without giving up what makes each instance valuable: its local sovereignty.

SLAW Botfather is a self-hosted control tower. It receives telemetry from enrolled SLAW instances, gives an enterprise admin fleet-wide visibility into what every machine is running and what it's spending, and pushes governance directives back down — budget limits, skill catalogs, and enrollment controls. Each SLAW instance stays fully local. Only metadata leaves the machine.

The sovereignty boundary​

This is the headline of the Fleet & Tower model: your data stays on your machines.

What the tower receives from each instance:

  • Squad names and agent descriptions (role, reporting line, capabilities — not adapter config or runtime config)
  • Issue titles only — never bodies, logs, or comments. Title reporting is opt-out via reportIssueTitles
  • Squad-skill descriptors — the skill name and metadata, never the skill body
  • Project names
  • Cost events — token counts and spend per agent, aggregated

What never leaves an instance:

  • Agent configuration and secrets
  • Issue descriptions, comments, and logs
  • Adapter configs or API keys
  • Skill content (the actual instructions)

The tower sees enough to govern. It never sees enough to reconstruct your work.

How enrollment works​

Enrollment is config-driven. If a SLAW instance's configuration includes a botfather.url, the integration is on — the presence of the URL is the switch, no separate enabled flag is needed.

On startup, a configured instance self-enrolls:

  1. The instance sends an enrollment request to the tower and lands in the Approval Queue.
  2. A tower admin approves or rejects the enrollment. Auto-approve rules (matching by hostname or machine ID pattern, e.g. *-ENG-*) can bypass the queue for known machines.
  3. Once approved, the instance receives a per-instance API key and goes active.
  4. Until active, the SLAW UI shows an enrollment gate with states: connecting, pending, rejected, active, unreachable, revoked.

Per-instance API keys are argon2-hashed in the tower with a sha256 fingerprint for lookup, and are revocable from the tower at any time.

What the tower sees​

The tower's nine screens give the enterprise admin a full picture of the fleet:

ScreenWhat it shows
FleetEvery machine and instance — online/offline/stale, spend at a glance
Instance detailSquads, agents per squad, issues by status, token tiles (input/cached/output/total)
Cost AnalyticsHourly rollups, forecast, top-spending agents, subscription vs metered
Budgets & LimitsCost and token limits — enterprise defaults plus per-instance overrides
IssuesPer-instance issues, all statuses, squad names resolved
AlertsBudget breaches, offline, stale, spend spikes (3×), version drift
Approvals & AdminThe enrollment approval queue, auto-approve rules, key revocation
Skill registryThe tower-mastered standard skill catalog, pushed to enrolled instances

Fleet-level governance​

The tower adds a governance layer above the local Operator:

  • Budget enforcement — the tower can set cost and token limits that cap strictly. Tower limits can only tighten the local Operator's budget, never loosen it.
  • Enforcement modes — enforce (the default hard gate; already-enrolled instances fail-open if the tower is unreachable, never-enrolled instances stay gated) vs advisory (soft limits, no blocking).
  • Skill catalog — the tower masters a standard-skills catalog and pushes it to enrolled instances. Local agents receive the catalog; local authoring of governed skills is locked while enrolled.
  • Alerts — the tower monitors for budget breaches, offline instances, version drift, and spend spikes, with deduplication and auto-resolve.

The push model​

Instances initiate all communication with the tower over HTTPS — the tower never reaches into an instance. The protocol has four operations:

  • Enroll — initial registration and identity exchange.
  • Heartbeat (~60s) — proof of life, plus any pending directive back-channel (e.g. set_limits).
  • Sync — delta updates, sent only when there are changes.
  • Manifest — full reconciliation, used for catch-up after a period offline.

An optional WebSocket connection enables real-time drill-down views in the tower UI without polling.

Self-hosted, zero-config​

Like SLAW itself, Botfather is local-first and self-hosted. It boots an embedded PostgreSQL database on startup, auto-creates its schema, and runs migrations automatically. The server listens on :8400; the UI dev server runs on :5174. An external database is available via BOTFATHER_DATABASE_URL for production deployments.

Next steps​