Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.

Runners

Runners are the RBA Fleet's autonomous agents — and this catalog is their Registry. A Runner is a declaration: it names the catalog skills the agent uses, the scoped Gateway tools it is allowed to call, what triggers it, which model it runs on, and the Sandbox it executes in. The declaration lives here, in git, PR-reviewed and validator-gated. A separate service (rba-runner) reads the Registry and actually executes the work.

This split is deliberate. This repo is the declarative control plane — it declares and governs Runners; it does not run them. That keeps every Runner accountable, reviewable, and audited the same way every other artifact in the catalog is, without coupling the static site to a live execution service. See the Platform Roadmap for how the three layers (Catalog → Gateway → Fleet) fit together.

What's in a Runner declaration

A runners/<slug>/runner.json names:

  • skills — references to catalog skills the Runner draws on.
  • allowedTools — scoped Gateway tool references (e.g. gateway:jira.read, gateway:git.*). A Runner reaches internal systems only through the Gateway, never directly.
  • trigger — manual, schedule, or webhook.
  • model — the Claude model the Runner runs on.
  • sandboxProfile — the isolated environment it executes in. Non-optional — no production credentials, no network egress except through the Gateway.
  • owners, maturity, securityReview — the same governance spine as the rest of the catalog.

Why Runners are governed harder

An autonomous Runner with tools is a higher risk class than a static skill. So the validator holds Runners to a stricter bar than the catalog default:

  • owners is required (not just a warning) — an autonomous, tooled agent must route to an accountable team.
  • sandboxProfile is required — the Sandbox is non-optional.
  • Any write-scoped Runner must pass a security review before it can reach maturity: stable. The Sandbox plus the Gateway's scoped, short-lived tokens are what let a Runner run without per-action permission prompts.

When to declare a Runner

Reach for a Runner when a repeatable job should run autonomously — on a schedule, off a webhook, or on demand — interleaving Claude with deterministic steps (git, lint, test, API calls through the Gateway). For an interactive, human-in-the-loop workflow, a skill, command, or agent is the better fit.

Browse the Runner Registry Search by name, filter by platform, discipline, outcome, lifecycle, or tag.