--- title: "Glossary: Agent registry" canonical_url: "https://tokenobserve.com/glossary/agent-registry" published: 2026-09-02 last_updated: 2026-10-21 --- # Glossary: Agent registry An agent registry is the system of record for the AI agents an organisation runs: one record per agent carrying its identity, a named human owner, a declared purpose, its permissions, its lifecycle status and its operating limits. It becomes a control rather than a document only when it is the same record the enforcement point resolves on every call, because an inventory maintained alongside the runtime is updated by whoever remembers while the runtime is updated by whoever ships. ## Also called - AI agent inventory - AI system inventory - agent catalogue ## In practice Most organisations discover their agent estate twice: once in a spreadsheet assembled for an audit, and once in an incident. The spreadsheet lists the agents somebody remembered. The incident involves the one they did not. That gap is structural rather than careless, and it is the reason the interesting property of a registry is not what it contains but what reads it. A list that the gateway resolves on every request cannot drift from what is running, because there is only one list; a list exported nightly into a governance tool is a photograph of a moving thing. The fields that matter are the ones a regulator or an incident will ask for. A named human owner, because accountability for something that is not a human has to land on somebody, and a team alias is not a person. A declared purpose written as a sentence, because most of the obligations that apply to a deployed AI system reduce to using it in accordance with its intended purpose, which requires a stated purpose to compare behaviour against. A lifecycle status, because suspension has to be a state change rather than a redeployment. Beyond those: risk tier, team and tags for scoping rules, permitted roles, spend and rate ceilings, and data-handling requirements such as no-training or region pinning. The design test for every additional field is whether some part of the request path reads it. A field nothing consults is documentation, and documentation drifts. That test also settles arguments about granularity: a risk tier that nothing enforces against is a label, so rules that must bite on high-risk agents are written against a tag the enforcement path matches on, and the tier is carried for review rather than pretended to be a control. A registry has two enforcement couplings that separate a working one from a decorative one. The first is that lifecycle is checked inline: a suspended agent is refused on its next call, with a typed error naming the state, rather than continuing until something redeploys. The second is referential integrity at write time: a role id that does not resolve should be refused when the record is saved, because a dangling grant silently reduces the agent to deny-by-default, and an agent failing every call reads as a deliberate policy decision rather than as the typo it is. The limit to state beside the claim is that a registry records what somebody registered. It does not discover anything. An agent calling a provider directly, a developer with a personal subscription, a workflow tool with its own key: none of them appears, and none of them is governed by anything scoped to the registry. Coverage claims therefore need a denominator from a different source: an estate where forty agents route through a governed endpoint and an unknown number do not is not fully governed, and the accurate form of that sentence has a number on both sides. Discovery is a separate discipline with a separate failure mode, and its cardinal rule is that a dead evidence feed must never look the same as a clean estate. ## Example: The four fields somebody has to fill in Registering a support triage agent requires a name, an owner email, a team and a declared purpose — “draft first-response replies to customer tickets for a human to send” — before anything else is decided. Status defaults to draft, so the record can exist while the decision to run it is still being taken. Everything optional that gets added afterwards is read by some step of the request path: the roles decide which tools and models it may reach, the tags decide which policies select it, the budget decides when it is cut off, and the data policy decides which providers it may be routed to. When somebody later suspends it, the change lands on the agent’s next call rather than at the next deployment, because the gateway resolves this record rather than a copy of it. ## Routinely confused with Model registry: A model registry versions trained models and their artefacts — weights, evaluation runs, lineage — and its subject is a model. An agent registry’s subject is a deployed actor with an owner, a purpose and a permission set, which may call several models and any number of tools. The two answer different audit questions and neither substitutes for the other. CMDB or service catalogue: A configuration management database records services and their dependencies for change and incident management, and is reconciled periodically. An agent registry has to be resolved synchronously in the authorisation path, which rules out reconciliation lag: a suspension that takes effect at the next sync is not a suspension. Observability inventory: An observability tool lists the agents it has seen traffic from, which is discovery rather than registration, and it lists them after the fact. A registry is the deliberate act of a named person declaring an agent’s purpose and owner before it runs, and it is what an unregistered agent is measured against.