Build

Registry

A tenant-scoped catalog of agent definitions: publish, search, version history. Metadata + source_ref: not auto-deploy.

What it is

Entries carry display name, tags, author, and a source_ref (git URL, plain URL, or inline config snippet). Version bumps write immutable snapshots when content changes.

Why it is here

Teams need a discoverable list of agents without turning the plane into a package manager that fetches and runs arbitrary code.

How to implement

Two equivalent paths, pick whichever fits your workflow. Both write to the same table, so an entry published one way shows up immediately when you look it up the other.

From your CI/CD or a script: the client-facing API, scoped by your own auth context:

  1. PUT /registry/entries/{name} with metadata + source_type / source_ref.
  2. POST /registry/search by name substring, tags (all must match), or author.
  3. Browse history via GET /registry/entries/{name}/versions.
  4. Wire the source into a runner config yourself, publishing does not register a live agent.
PUT /registry/entries/sales-qualifier
{
  "display_name": "Sales Qualifier",
  "description": "Qualifies inbound leads",
  "author": "alice",
  "tags": ["sales", "lead-gen"],
  "source_type": "git",
  "source_ref": "https://github.com/example/sales-qualifier@main"
}

From Admin, by hand: no request body to write yourself:

  1. Open /admin/registry and click Publish entry for a new one, or click any row to open an existing entry.
  2. Fill in the same fields as the API body above through a plain form, tenant, name (slug), display name, tags, and source_type / source_ref.
  3. Save changes updates the entry in place (a real content change still writes a new version, exactly like the API path); Delete removes it and its version history.
  4. The same "publishing is not deploying" rule applies here too, the entry is discoverable metadata, not a live agent, regardless of which path you used to create it.

Admin writes go through PUT / DELETE /admin-api/registry/{name} (an Admin-only route, distinct from the client-facing /registry/entries/{name} above) and are audited the same way every other Admin mutation is.

In the product

Admin → Registry: catalog entries
Runkite Admin Registry

What to expect

Reference: docs/registry.md · Agents