Agent Operations Platform
Agent Registry
The Agent Registry is the registration and lifecycle layer for agents themselves. Every agent — new or existing, built in-house or bought from a vendor — receives a registry record the platform can reason about: a name, an owner, a workspace, and the credentials that flow from it.
Workflow
Register the first.Then the fiftieth.
The same loop applies to every agent. Each step is one CLI command, one API call, or one line of declarative state in CI — register once, repeat without thinking.
- 01
Register
Create the registry record. Name, owner, workspace, tier. Receive an API key.
- 02
Provision
Declare the tools and models the agent is intended to use. Capabilities are scoped at the workspace.
- 03
Enable
Move from provisioned to active. The agent can now reach its declared surface — subject to policy.
- 04
Observe
Watch the audit stream. Tighten rules as patterns emerge. Suspend or revoke from the same surface.
Consistent operations
Standard agent lifecycle
The Registry is where code becomes a first-class object in the platform. Every agent moves through the same managed lifecycle, with the registry record carrying the credential, the call context, and the chain of accountability across every hop.
Record created. API key issued. No traffic yet.
Calls flow through Gateway and Broker, subject to policy.
Access halts within seconds. Audit retains everything.
Credential dead. Record retained for compliance.
Registration
Each agent has an immutable registry record — a name, an owner, and a workspace. The API key issued at registration becomes a short-lived JWT on every call — the credential everything else flows from.
Credential chain
Agents can act on behalf of users (act-as) and other agents (on-behalf-of). The chain is signed end-to-end, preserved across hops, and auditable per step — following the OAuth 2.0 Token Exchange model (RFC 8693).
Call context
Every call carries the agent registry record, act-as claims, request headers, and policy metadata. That record is the contract the Gateway and Broker evaluate against on every request.
Options
What the Registry lets you do
Beyond a basic record, the Registry surfaces operational controls — what you can opt into via the CLI, API, or SDK to harden how each agent behaves on the platform.
Tier-based trust
Assign each agent a tier that determines its default trust level and the policy bundle it inherits.
Hierarchical agents
Let one agent call another with chained credentials. The original caller is preserved through the chain for audit and act-as enforcement.
Declared capabilities
Scope each agent to specific tools, model pools, and integrations. Anything outside the declared surface is denied by default.
Act-as enforcement
Require every call to carry verified end-user identity. The Gateway and Broker fail-closed without it.
Lifecycle controls
Move agents through provisioned → active → suspended → revoked. SDK-side events fire on transitions so callers can drain cleanly.
SDK-emitted events
Emit audit events from inside the agent process — decisions, errors, custom signals — alongside the calls the Gateway and Broker already record.
In practice
From CLI to running agent
Registration is a control-plane operation — done from the CLI, the API, or a CI pipeline. The SDK then wraps the issued API key in the agent process.
dome agents register \
--name support-triage \
--tier standard \
--tool zendesk \
--pool premium-reasoning \
--require-actas oidc
dome agents activate support-triageimport dome
client = dome.DomeClient(dome.DomeConfig(
base_url="https://api.dome.example.com",
token="dome_at_...", # agent API key
))
client.start()
client.check(
tool="zendesk/create_ticket",
on_allow=lambda d: ...,
on_deny=lambda req, reason: ...,
)