The single most valuable artefact in any enterprise agent program is the registry. It is also the most often missing one. More than half of organisations deploying AI lack a systematic inventory of what they have deployed — which is why the registry is also the most common compliance gap.
What an agent registry is
An agent registry is the centralised catalogue of every agent in production: what each one does, what tools it can invoke, what data it can read, what actions it can take, who its human principal is, what its current authority scope is, what version of the model it runs, and how to turn it off. Done well, the registry is operational infrastructure: a service the rest of the organisation calls to discover, invoke, audit, or revoke agents. Done badly, it is a spreadsheet that nobody updates.
The NIST RMF subcategory GV 1.6 calls for an inventory of AI systems. For agentic systems specifically, the Cloud Security Alliance's Agentic Profile extends this: the registry must capture tool access, delegation relationships, and authority review schedules. None of those are properties of the model. All of them are properties of the deployment. That is why the registry is a piece of infrastructure, not a model artefact.
The fields that matter
The minimum useful registry has, for each agent, a record with the following fields. The agent's identity (a stable ID, not a name that might change). Its owner (the human accountable, named, with a backup). Its purpose, written in one sentence anyone in the company would understand. Its autonomy tier (0–4, per Chapter 3). Its tool list, with each entry linking to an Action-Consequence Map row from Chapter 9. Its data scope: what it can read, what it can write, with what scoping. Its model and prompt versions, with hashes. Its delegation relationships: which agents can call it, which it can call. Its authority review date. Its kill-switch procedure. Its incident history.
That is more than most teams maintain on their first attempt, and less than the EU AI Act will eventually require for high-risk deployments. The discipline is to build the schema before there is anything to register, so that the first agent enters the registry on the day it goes to production, not six months later when the auditor asks.
Build, buy, or extend
There are three reasonable patterns. The first is to build the registry as a small internal application — typically a database with a thin web interface — owned by the central AI platform team. This is the most flexible approach and the one most large enterprises end up with eventually. It is also the one that requires actual engineering investment.
The second is to extend an existing inventory system: a CMDB, a service catalogue, an API gateway's registry. This works if the existing system can carry the agent-specific fields (autonomy tier, tool access, delegation), and if the team that owns it is willing to add them. Most enterprise CMDBs were not designed for this and adding the fields is more political than technical.
The third is to buy. Several vendors now sell agent registries as products, and orchestration platforms like LangSmith and Arize provide registry-adjacent functionality. Buying is fastest. The risk is lock-in: the registry is the most stable artefact in the agent program, and you do not want it tied to whichever orchestration vendor is fashionable this year. If you buy, ensure the schema is exportable.
The registry is the artefact most likely to become a security target. It contains the most concentrated description of every agent's authority in the organisation. Treat its access controls with the same seriousness you would treat the IAM control plane itself. The registry of registries is a thing real attackers care about.
Keeping it alive
A dead registry is worse than no registry, because it is consulted as if it were true. The mechanisms that keep one alive are mostly procedural. New agents cannot enter production without a registry record (this requires the deployment pipeline to enforce it). Tool changes require a registry update (this requires the tool registration to be coupled to the agent's). Authority review dates trigger a real review with a real human in the loop (this requires a calendar). Decommissioned agents are marked decommissioned, not deleted (so the audit trail survives).
The single best test of whether your registry is alive is to pick one agent at random and ask: when was its last authority review? If the answer is "I would have to ask", the registry is a document. If the answer is in the registry, with a date and a name, you have built infrastructure.
The next chapter is the catalogue of risks the registry exists to defend against — and the techniques to mitigate them, drawn from OWASP's 2025 LLM Top 10 and MITRE ATLAS.