Keep track of every AI agent by running an agent registry: one maintained record of each agent, its owner, purpose, model, tools, data access and status. Feed it from the places agents are actually built and switched on, check it against what is running, and make registration a condition of an agent getting credentials or going live.
Why agents are hard to count
A few years ago an AI feature was a project with a budget, a team and a launch date. Someone knew it existed. Agents are different. They are switched on inside SaaS products, assembled in low-code builders, created in cloud AI platforms and written directly into internal services. Many start as an experiment by one person and quietly become part of how work gets done.
The result is that most organisations cannot answer simple questions with confidence. How many agents are running? Which of them can send email, change records or move money? Who is responsible for each one? If a model provider announces a deprecation, or a vulnerability is found in a tool integration, which agents are affected?
Every other control depends on those answers. You cannot audit what an agent did, stop agents reaching restricted data or plan for a model being deprecated for an agent nobody knows about.
What an agent registry should record
A registry is only useful if each entry answers the questions people will ask when something goes wrong. For each agent, record at least the following.
Identity and ownership
Give every agent a unique identifier and a plain-language name. Record a named business owner who is accountable for what the agent does, and a technical owner who can change or switch it off. A team name is not enough: teams reorganise, and an agent with no individual owner tends to drift.
Purpose and authority
Describe what the agent is for in a sentence or two, and what it is allowed to do on its own. Note whether it only reads and suggests, or whether it can act, and which actions need a person to approve them. That line between suggestion and action is where most of the risk sits, as the guide to stopping an agent taking a wrong action explains.
Model, tools and data
List the model and version it uses, where that model runs, the tools and integrations it can call, and the data sources it can read or write. Include the credentials it holds and whether it acts under its own identity or on behalf of a user. This is the part of the entry that lets you answer impact questions quickly.
Status and evidence
Record where the agent is in its life: proposed, in pilot, live, paused or retired. Link to its evaluation results, its approval record and where its logs and monitoring live. A retired agent should stay in the registry with its credentials revoked, so its history can still be explained later.
How to find the agents you already have
Starting a registry from a blank form and asking teams to fill it in rarely produces a complete picture. Work from several sources at once and reconcile them.
Look at your identity provider and secrets store for service accounts, API keys and OAuth grants that belong to automated clients. Review the AI features enabled in your main SaaS platforms, since many now include agents that can be turned on by an administrator. Check cloud accounts for AI platform projects and model endpoints, and search code repositories for model provider SDKs and agent frameworks. Model provider billing is another useful signal: spend with no known owner usually means an agent nobody has registered.
Then talk to the teams behind what you find. The aim of this first pass is not to shut things down but to learn what exists and give each agent an owner.
Keep the registry true over time
A registry that is correct on the day it is built and wrong a few weeks later is worse than none, because people trust it. Three habits keep it honest.
First, make registration a gate rather than paperwork. An agent should not get production credentials, access to an internal API or a route through your secure connection layer until it has an entry and an owner. If your agents connect to tools through a common gateway or MCP layer, that gateway is a natural place to refuse unregistered clients.
Second, generate as much of each entry as you can. Model versions, tool lists and permissions can often be read from configuration and deployment metadata rather than typed in by hand, which keeps them current.
Third, reconcile regularly. Compare the registry with what the discovery sources show is actually running, and treat any gap in either direction as something to resolve: an unregistered agent that is live, or a registered one that has no recent activity and may be a candidate for retirement.
Use the registry, not just maintain it
The registry earns its keep when it drives decisions. Risk reviews can focus on agents that can act, touch personal data or run without approval steps. Incident response can find every agent using an affected model, tool or credential in minutes rather than days of asking around. Cost reviews can tie spend to owners, as covered in controlling what an agent costs to run. And the people who operate agents after launch have a single place to see what they are responsible for.
It also makes regulatory and customer questions easier. Frameworks for AI governance increasingly expect organisations to know which AI systems they run and what those systems do. A maintained registry, linked to audit trails and evaluation evidence, turns that expectation into something you can show rather than assert.
Start small and make it the default
You do not need a dedicated platform to begin. A structured record kept under version control, with a clear schema and an owner, is enough to start. What matters is that new agents cannot go live without an entry, and that someone checks the registry against reality on a schedule. Tooling can come later, once you know what you need to track.
CodeDTX's enterprise AI governance framework and MCP integration work helps teams set up agent registries, build registration into their deployment path and connect it to the controls that depend on it. If you are not sure how many agents your organisation runs, talk to CodeDTX.
Frequently asked questions
What is the difference between an agent registry and a model inventory?
A model inventory lists the AI models an organisation uses. An agent registry goes further: it records each agent built on those models, what it is for, which tools and data it can reach, what it may do without approval and who owns it. Several agents can share one model while carrying very different risks, so governance needs the agent-level view as well as the model list.
Who should own the agent registry?
Give the registry itself a single owner, often a platform, security or AI governance team, who keeps the schema, runs the reconciliation and chases missing entries. Each agent in it still needs its own business and technical owners. The registry owner is responsible for the record being complete and accurate, while each agent's owners are responsible for what that agent does.
Do agents inside SaaS products need to be registered?
Yes, if they can act on your data or systems. An agent switched on inside a CRM, helpdesk or office suite can read records, draft messages or change data just as a custom-built one can. Register it with the same fields, noting that the vendor runs the model. Its owner should know which settings control what it can do and who is allowed to change them.
How often should the registry be checked against what is running?
Check continuously where you can, by reading deployment metadata and connection logs automatically, and run a full reconciliation on a regular schedule agreed with the registry owner. Also check whenever something significant changes, such as a new SaaS AI feature being enabled, a model being deprecated or a security incident. The goal is that gaps are found by the process, not by accident.
