What is Botfather?
Botfather gives you a single pane of glass across every SLAW instance in your organisation — every machine, squad, agent, and running issue — without moving any of your work off the desktop.
The sovereignty boundary
SLAW runs locally. No prompts, no code, no task details leave the machine. Botfather is built around that constraint: the tower receives metadata and metrics only.
What the tower sees:
- Squad and agent names, roles, and status
- Issue titles and statuses (opt out of titles via
reportIssueTitles: false) - Token counts and cost telemetry
- Instance health and enrollment state
What stays on the instance, always:
- Issue bodies, comments, and run logs
- Agent adapter configuration and secrets
- Skill definition content
This is an architectural guarantee, not a firewall rule. The Reporter module inside each SLAW instance decides what to emit before anything leaves. The tower has no path to reach in.
Two components
The tower (slaw-botfather) is a self-hosted server your organisation deploys once. It stores fleet state in Postgres, serves the admin dashboard, manages the enrollment queue, and publishes the standard-skills catalog.
The reporter is a sidecar module inside your existing SLAW instance. It runs alongside the SLAW process, reads metadata from the local database, and pushes batches outbound to the tower over HTTPS every 60 seconds. It never opens an inbound port — all connections originate from the instance.
A SLAW instance remains fully functional when the tower is unreachable. Botfather is observability and governance, not a runtime dependency.
Next steps
- When you need Botfather — one instance vs a fleet
- Architecture — the push model and data flow in detail
- Install the tower — self-host Botfather in minutes