Guide
Build an agent inventory you can operate
You're on call when a support agent starts making unexpected requests. The inventory says “support assistant, owner: platform.” It doesn't tell you where the agent runs, which credentials it uses, or who can approve a change.
A useful inventory should let another operator find those answers without tracking down the person who built the agent. Start by checking whether the deployment, registered identity, and recent activity describe the same service.
Compare what is deployed, registered, and making requests
Use three independent views: what teams say they run, what has a registered identity, and what available evidence shows making requests.
These views should agree, but none is complete by definition. A deployment record may survive after a workload is retired. A registered identity may never have been used. Observed traffic may reveal an integration missing from the service catalog.
Dome's Agent Registry workflow supplies the durable identity, credentials, configured access, and lifecycle record. Registration and key issuance are separate, so rotating a credential need not replace the identity used to investigate past activity. Registration alone grants no access.
The service catalog can remain the home for business ownership and operational commitments. Link it to the Dome agent ID instead of maintaining two competing descriptions of the organization.
A worksheet for the first reconciliation
The following entries describe a hypothetical estate, not a discovered customer deployment.
| Service | Declared deployment | Identity and activity | Owner decision | Disposition |
|---|---|---|---|---|
| Support assistant | Production deployment exists | Registered agent, recent governed calls | Support platform owns permissions and recovery | Confirm endpoint and key inventory; retain |
| Nightly reconciler | Scheduled job exists | Registered agent, no recent calls | Finance engineering expects a monthly run | Compare with the job schedule before declaring it stale |
| Research prototype | No current deployment listed | Registered identity still making calls | Original owner has moved teams | Find the runtime and new accountable owner; contain if authority cannot be justified |
| Document classifier | Production deployment exists | No matching registered identity | Application team says it uses a direct provider key | Record the direct path and decide whether to onboard or explicitly retain it |
| Retired importer | Deployment removed | Identity and keys remain | Retirement approved | Complete authority retirement and retain the historical record |
For every mismatch, assign someone a next step. An unexplained row marked red won't tell the on-call engineer what to do.
A direct connection is not automatically a violation. It is an exception to the intended coverage only if the operating design requires that workload to use Dome. Record the decision so the estate's coverage can be described honestly.
Can another operator take over?
Replace the generic owner field with a link to an operating record that answers who can:
- Approve a change in the agent's purpose or allowed operations.
- Rotate its credentials and update the deployed runtime.
- Investigate its activity and reconcile a backend effect.
- Contain it during an incident.
- Accept ownership when the team or service changes.
One small team may handle all of this. Name the people or on-call roles who can actually make the decisions.
For a handover, ask the incoming owner to find the agent record, locate the active deployment, and explain one recent permitted and denied request. If that requires the departing engineer's memory, the inventory is missing operating information.
A quiet identity isn't necessarily retired
Dome's lifecycle documentation distinguishes provisioned, active, suspended, and revoked identities. Provisioned agents can send traffic, subject to the other access controls, and become active on their first gateway request. “Provisioned” therefore does not mean “unable to act.”
Last-seen activity comes from requests through the gateway. A quiet record may represent a scheduled workload, a disconnected client, or traffic using another path. Staleness does not automatically suspend the identity.
Keep runtime state separate from identity state. A process may still be running when its governed requests are refused. Retirement needs both the deployment decision and the access decision.
Recheck when the service changes
Reconcile when onboarding a service, transferring ownership, changing its routing, or retiring it. Choose a periodic review interval that fits the estate's rate of change.
Prioritize an active agent with no owner over an unused record waiting for a planned launch. Both need an explanation, but only one may be doing unowned work right now.
Start with one production service. Use the agent management guide to inspect its identity and access, then compare those records with the deployment and its observed requests. A useful inventory is one another operator can act on without first finding the person who built it.