Skip to main content

When You Need Botfather

One SLAW instance handles everything a solo developer or small team needs. Botfather becomes valuable once you have several instances and need to know what they are all doing.

You probably don't need Botfather if​

  • You are a single developer or small team running one SLAW instance
  • There is no compliance or audit requirement for agent activity
  • Budget tracking happens at the provider level (for example, a shared API key with a spend cap)
  • You have no need to standardise which agent skills are available across teams

You need Botfather when​

You have multiple SLAW instances. Once engineers each run their own SLAW — five laptops, twenty Claude Code terminals — you lose visibility across the fleet. Botfather puts every machine, instance, squad, and running issue on one screen.

You need spend visibility and control. Botfather aggregates cost telemetry from every instance, surfaces the top burners, and lets you set an enterprise-wide limit that caps local agent runs before they overspend. The tower enforces a ceiling on top of any local squad or agent budget.

Enrollment governance matters. In a regulated environment, you need a record of which machines are running agents and the ability to deny or revoke access. Botfather's approval queue and per-instance API keys give you that control — no machine starts reporting until an admin (or a matching auto-approve rule) allows it.

You want to standardise agent skills. When enrolled, the tower becomes the single source of truth for the skill catalog. Admins publish a governed set of standard skills; local skill authoring is locked on enrolled instances. Every squad works from the same baseline.

The enterprise pattern​

A typical enterprise deployment looks like this:

  1. IT pre-provisions a botfather.url in the SLAW config via MDM or config management — the presence of that URL turns the integration on and engages the enrollment gate
  2. Engineers start SLAW; each instance self-enrolls and appears as pending in the tower's Approval Queue
  3. An admin approves the instance (or an auto-approve rule matches, for example *-ENG-* on the machine hostname)
  4. The instance goes active; the startup gate unlocks; the Reporter starts pushing metrics

From that point, the admin dashboard shows the full fleet in real time. New machines follow the same path automatically.