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:

PUT /registry/entries/{name} with metadata + source_type / source_ref.
POST /registry/search by name substring, tags (all must match), or author.
Browse history via GET /registry/entries/{name}/versions.
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:

Open /admin/registry and click Publish entry for a new one, or click any row to open an existing entry.
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.
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.
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

What to expect

Tenant-private — not a cross-tenant public marketplace.
No review queue — publish is immediately visible in-tenant.
Admin name collisions — use ?tenant_id= when two tenants share a name.

Reference: docs/registry.md · Agents