All glossary terms
A AI governance Agent operations

Agent registry

An agent registry is the system of record for every AI agent an organization runs. Its authority is measured by what happens to an agent that is not in it. A record you can read is documentation. A record you cannot deploy without is a control.

Definition

An agent registry is the system of record for every AI agent an organization runs: what each agent is, who owns it, what it is permitted to do, what data it can reach, and what it has done. Its authority is set by what happens to an agent that is not in it.

What is an agent registry?

An agent registry is the system of record for every AI agent an organization runs: what each agent is, who owns it, what it is permitted to do, what data it can reach, and what it has done. It is the control that turns a collection of independently built agents into a governable estate.

The comparison most people reach for is a catalog, and it undersells the thing. A catalog helps you find what exists. A registry is where an agent acquires an institutional identity: a stable identifier, an accountable owner, a scope it was approved to operate within, and a record that can be produced later when somebody asks what happened. Discovery is one use of that record. Governance, cost attribution, incident scoping, and audit are the others, and they are why the term moved from architecture diagrams into board risk conversations inside about a year.

This points to the distinction that matters most and gets the least attention. A registry's authority isn't defined by what it contains. It's defined by what happens to an agent that isn't listed in it. If an unregistered agent can still run anyway, the registry is just documentation: accurate, useful, but structurally powerless to stop the very thing it was meant to prevent. If an unregistered agent can't reach production at all, that same list becomes a control. Same fields, same schema, completely different function.

The scale case for having one is no longer contested. Gartner expects the average global Fortune 500 enterprise to run more than 150,000 agents by 2028, up from fewer than 15 in 2025, and reports that only 13 percent of organizations believe they have the right agent governance in place today. Building a centralized agent inventory is the second of the six steps Gartner sets out for managing agent sprawl, and it recommends AI trust, risk and security management tooling to discover and categorize agents, including ones nobody sanctioned. Source: Gartner, April 2026.

The self-registration paradox. A registry populated only by voluntary self-registration ends up holding exactly the agents whose owners were already governing them well. The agents that created the need for a registry are the ones least likely to be entered into it by hand. This is why discovery has to come before schema, and why a registry that launches as a form for teams to fill in tends to describe the estate its authors already knew about.

What does an agent registry record?

An agent registry record holds ten fields: identifier, owner, purpose, approval record, data access, identity and permissions, model, tools, environment, and review date. Each one exists because a specific question becomes unanswerable without it.

Schemas vary between platforms and no standard has settled yet, so the useful way to specify a record is by the question each field answers rather than by copying one vendor's data model. The ten below are the set that recurs across governance reviews and audit requests.

  • Agent identifier. A stable unique ID, independent of display name or host platform. Without it, logs, cost, and incidents cannot be correlated to one agent, especially after a rename or a migration.
  • Owner. A named individual and their team, not a distribution list or a department. Without it there is nobody to ask, nobody to approve changes, and nobody accountable for cost. This field does more work than the other nine combined.
  • Purpose. One line, in business terms, describing what the agent is for. Without it, reviewers cannot judge whether observed behavior is inside or outside the agent's remit.
  • Approval record. Who approved it, for what scope, on what date, against which version of policy. Without it compliance is unevidenced, and an auditor treats an unevidenced control as a failed one.
  • Data access. The systems and data classifications the agent can reach. Without it, the blast radius of an incident cannot be scoped without a manual investigation.
  • Identity and permissions. The service identity it runs as and its privilege level. Without it, over-permissioned agents stay invisible, including ones that inherited privileges from whoever created them.
  • Model and provider. The model, version, and provider the agent calls. Without it, a model deprecation or a provider incident cannot be assessed for exposure.
  • Tools and integrations. The external tools, APIs, and MCP servers the agent may invoke. Without it the reachable surface is unknown, so a compromised tool cannot be traced to the agents using it.
  • Environment and state. Development, test, or production, plus where the agent is deployed. Without it, experiments and production systems are indistinguishable in the same list.
  • Review and retirement date. When the record expires and who must re-approve it. Without it the estate only grows, because nothing in the lifecycle ever ends.

Two fields are worth singling out. Owner is the one that fails quietly: it is easy to populate with a team alias, and a team alias is not a person who can be asked a question or held to a budget. Review date is the one most often omitted entirely, and its absence is what turns a registry into an append-only list.

What are the five levels of registry authority?

Registries range across five levels of authority, from a hand-maintained list that records agents to a system that can decommission them. The level, not the schema, determines whether a registry changes outcomes.

Placing your own registry on this ladder is a more useful exercise than comparing field lists, because two organizations can hold identical records and get entirely different results from them.

A rising staircase of six blocks. Level 0, no registry. Level 1, a manually maintained list, labelled documentation. Level 2, automated discovery keeps the list current, labelled observation. Level 3, registration required before production, labelled control. Level 4, the record drives runtime permissions and budget, labelled enforcement. Level 5, records expire and trigger decommissioning, labelled lifecycle. A dashed line between levels 2 and 3 marks where a record becomes a control.
  1. L0
    No registryNobody can state how many agents run in production. Effect: every governance question requires a project to answer.
  2. L1
    Manual list, which is documentationA spreadsheet or wiki page someone maintains by hand, accurate on the day it was written. Effect: useful for orientation, structurally unable to prevent anything.
  3. L2
    Discovered inventory, which is observationAutomated discovery keeps the list current across every platform where agents can be created. Effect: the count becomes trustworthy, and duplicates become visible for the first time.
  4. L3
    Registration gate, which is controlAn agent cannot reach production without a record. Effect: this is the level at which a registry starts changing behavior rather than describing it.
  5. L4
    Runtime authority, which is enforcementPermissions, budget ceilings, and policy are read from the record, so editing the registry changes what the agent can do. Effect: governance stops being a document and becomes a configuration.
  6. L5
    Lifecycle authority, which closes the loopRecords expire. An agent whose review date passes without re-approval is decommissioned and its credentials withdrawn. Effect: the estate can shrink, which no earlier level permits.

The step from Level 2 to Level 3 is organizational, not technical. Discovery and schema are engineering problems with known solutions. Making registration a precondition for production requires that somebody be willing to block a deployment, and to be supported when they do. Most registry programs stall here, with good tooling and no authority, which is why the honest first question about a registry initiative is who signs off on the gate rather than which platform will hold the records.

What breaks without an agent registry?

Without an agent registry, five things become impossible rather than merely difficult: scoping an incident, evidencing compliance, attributing cost, preventing duplication, and retiring anything. Each is a downstream control that reads from the record, so the absence compounds.

  • Incident scoping. When an agent behaves unexpectedly, the first questions are what data it can reach, what depends on its output, and who can stop it. Without a record those answers are assembled during the incident, and assembly time is time the behavior continues.
  • Evidenced compliance. An action taken by an agent in a regulated function carries the same obligations as the same action taken by an employee. Producing who authorized it and under what scope is a lookup with a registry and a reconstruction project without one.
  • Cost attribution. Inference and infrastructure spend can only be attributed to an owner if agents have owners on record. Otherwise agent spend arrives as one undifferentiated number that no individual is accountable for and nobody can be asked to reduce.
  • Duplication prevention. Teams build agents that already exist because there is no place to look first. A registry is the only control that addresses this, and duplication is usually the first thing a complete inventory surfaces.
  • Retirement. Nothing can be decommissioned on a schedule that has no record of what exists or when it was last reviewed. Agents that stopped being useful keep their credentials, their data access, and their running cost indefinitely.

The pattern across all five is that the registry is rarely the control a governance program is really trying to build. It is the control every other control depends on, which is why it tends to be discovered second, after something else has already failed for want of it. For the condition that results when agents accumulate faster than this record can be kept, see agent sprawl.

How is an agent registry different from a model registry or an AI inventory?

An agent registry catalogs autonomous agents and their permissions, ownership, and lifecycle. A model registry catalogs trained model artifacts and their versions. An AI inventory catalogs all AI assets for regulatory accountability. They overlap, they are owned by different teams, and most large organizations need more than one.

These are routinely treated as the same asset under different names, which leads to a specific and expensive mistake: satisfying a compliance requirement with an AI inventory and assuming the operational control has also been built.

Agent registry compared with AI inventory, model registry, tool registry, service catalog, and agent card discovery
Term What it catalogs The core question Usually owned by
Agent registry Autonomous agents, with ownership, permissions, and lifecycle state What agents do we run, who owns them, and what can they reach? Platform engineering, governance lead
AI inventory All AI assets: models, datasets, applications, use cases, and agents Which AI systems are we accountable for, and at what risk tier? Compliance, risk, legal
Model registry Trained model artifacts, versions, lineage, and evaluation results Which model version is in production and how was it validated? Data science, MLOps
Tool registry External tools, APIs, and MCP servers that agents may call What can our agents reach, and is every call audited? Platform engineering, security
Service catalog Configuration items, services, and their dependency relationships What IT services exist and what depends on what? IT service management
Agent card One agent's advertised capabilities, published for runtime discovery How does another agent find and correctly call this one? Solution architecture

The sharpest of these distinctions is the first pair. An AI inventory answers to a regulator, so it is organized by risk tier and use case and is often updated on a review cycle. An agent registry answers to an operator, so it is organized by agent and needs to be current continuously. An organization can hold a complete, audited AI inventory and still be unable to say which agent called which tool an hour ago. Both are legitimate records. Neither substitutes for the other.

The last row is worth separating too, because the vocabulary collides. An agent card is a capability advertisement a single agent publishes so other agents can discover and call it. A registry is an institutional record about that agent, held by the organization rather than by the agent. Machine-readable discovery and human-accountable governance are different jobs, and a system that does the first well does not automatically do the second.

How do you build an agent registry?

An agent registry is built in six steps: discover what exists, define the record schema, backfill and assign owners, wire registration into the deployment pipeline, make the record authoritative at runtime, and expire records on a schedule.

The order carries information. Programs that start by designing a schema and publishing a registration form produce a register of the agents that were already governed, which is the set that did not need registering.

The six steps, in order

Six numbered steps in a left to right sequence. One, discover across platforms. Two, define the record schema. Three, backfill and assign owners. Four, wire registration into the deployment pipeline. Five, make the record authoritative at runtime. Six, expire records on a schedule, with an arrow returning to step three as the review cycle.

  1. Discover across every platform

    Find what exists before deciding what to record about it. Discovery has to reach every environment where an agent can be created, including the ones that came bundled with a cloud or data platform the organization already licenses. Cover only the platform the AI team works in and the registry inherits that blind spot permanently.

  2. Define the record schema

    Start with the ten fields above and resist expanding. Every additional field is a field somebody has to keep accurate, and a registry with forty fields and thirty of them stale is less trustworthy than one with ten that are all current.

  3. Backfill, and assign a named owner to everything

    Populate records for the discovered estate. Any agent that cannot be given a named owner is a finding rather than a data-entry problem: it is either a candidate for retirement or evidence that a team has left the organization holding something nobody inherited.

  4. Wire registration into the deployment pipeline

    Registration has to be a step in shipping rather than a request submitted alongside it. Where the deployment path issues the identifier and the credentials, the record is created by construction and cannot be skipped, which is what moves a registry from Level 2 to Level 3.

  5. Make the record authoritative at runtime

    Have permissions, budget ceilings, and policy read from the registry rather than being configured separately per agent. Once the record is the source of those values, keeping it accurate stops being an act of discipline and becomes a condition of the agent working at all.

  6. Expire records on a schedule

    Give every record a review date and a defined consequence for passing it. Without an expiry the registry is append-only, and an append-only registry drifts toward being an accurate history of everything ever built rather than a statement of what runs today.

One thing is deliberately absent. There is no step for a central team that builds and registers agents on behalf of everyone else. Concentrating agent creation is a way to make a registry accurate by making the estate small, and it trades the governance problem for a delivery bottleneck that teams will route around.

How the six steps line up with Gartner's six steps

Gartner published its own six steps for managing agent sprawl in April 2026, and buyers now arrive at governance reviews holding that list. Its second and third steps are the registry. The mapping below exists so the two can be read side by side without anyone having to translate.

Gartner's six steps to manage AI agent sprawl, mapped to what an agent registry supplies
Gartner step What the registry supplies
Establish agent governance and policies The place policy becomes checkable, because each record carries the policy version it was approved against
Build a centralized agent inventory This step is the registry. Gartner names AI trust, risk and security management tooling for discovering and categorizing agents, including unsanctioned ones
Define agent identity, permissions and lifecycle The identity, permissions, and review-date fields, plus the retirement state that gives the lifecycle an end
Develop AI information governance The data-access field records what each agent can reach; information governance decides what it should
Monitor and remediate agent behavior Runtime observability rather than the registry itself, though it reads agent identity from the registry to attribute what it observes
Foster a culture of responsible AI usage No direct equivalent, because this is a program practice rather than a record. The nearest contribution is discoverability: reuse becomes the default only once teams can find what already exists

Should a registry also control deployment?

There's a genuine architectural disagreement here, worth knowing before you evaluate any tools. One camp believes a registry should just be a record, nothing more, keeping routing and deployment as separate concerns. Their reasoning: a record that also executes actions becomes harder to reason about and harder to replace later. The other camp believes a record with no way to enforce it is exactly why registries fail, and that tying registration to deployment is the only reliable way to keep the record accurate.

Both views are reasonable; they just optimize for different risks: clean architecture versus practical completeness. The key thing to hold onto is that these two roles are separable. A registry can decide whether a deployment is allowed without being the thing that carries it out, and that setup gets most of the enforcement benefit while keeping the record easy to replace.

Which category of tooling holds the registry

Registry capability arrives from several directions, which is a common source of confusion during evaluation. Agent management platforms provide a registry alongside promotion workflows and runtime observability. Identity governance tools hold agents as non-human identities, strong on credentials and permissions and lighter on purpose and approval. Cloud and data platform consoles increasingly ship a registry covering agents built on their own stack, which is genuinely useful and is also why a large enterprise often has several partial registries and no authoritative one. AI governance and inventory tools cover the regulatory record well and the operational detail less so. The practical question is not which category to buy from, but which of the six steps above is currently missing and whether anything you already own can supply it.

Agent registry as a capability, and Agent Registry as a product name

The term now does double duty, which is worth stating plainly because it affects how the phrase is read in a vendor conversation. Several platforms ship a component named Agent Registry, including Google Cloud, MuleSoft, and Covasant's own CAMS. Throughout this entry, agent registry in lower case refers to the general capability described above, not to any of those products. When a specific product is meant, it takes a capital letter and a vendor name in front of it. If you are comparing named Agent Registry components, the useful questions are which authority level each one reaches, whether its discovery extends past its own platform, and which of the ten record fields it holds natively.

Frequently asked questions about agent registries

If your question is not here, our team will answer it directly.


Talk to a Specialist →
What is an agent registry?

An agent registry is the system of record for every AI agent an organization runs: what each agent is, who owns it, what it is permitted to do, what data it can reach, and what it has done. It is the record that downstream controls read from, which is why incident scoping, cost attribution, audit evidence, and retirement all depend on it. A registry's authority is set by what happens to an agent that is not in it: if an unregistered agent can still reach production, the registry is documentation rather than a control.

What information should an agent registry contain?

Ten fields cover the questions that governance reviews and audits actually ask. A stable agent identifier that survives renames and migrations. A named owner, meaning an individual rather than a team alias. A one-line statement of purpose in business terms. An approval record showing who approved what scope, when, and against which policy version. The systems and data classifications the agent can reach. The service identity it runs as and its privilege level. The model, version, and provider it calls. The external tools, APIs, and MCP servers it may invoke. Its environment and deployment state. And a review date with a defined consequence for passing it. Resist adding more, because every extra field is one somebody has to keep accurate.

What is the difference between an agent registry and an AI inventory?

An AI inventory answers to a regulator and an agent registry answers to an operator. An AI inventory catalogs all AI assets, including models, datasets, applications, and use cases, organized by risk tier to demonstrate accountability, and it is often updated on a review cycle. An agent registry catalogs autonomous agents specifically, organized by agent, and needs to be current continuously because runtime controls read from it. An organization can hold a complete and audited AI inventory and still be unable to say which agent called which tool an hour ago. Most large organizations need both, and satisfying the compliance requirement does not mean the operational control has been built.

Is an agent registry the same as a model registry?

No. A model registry catalogs trained model artifacts, their versions, their lineage, and their evaluation results, answering which model version is in production and how it was validated. An agent registry catalogs the agents that call those models, answering who owns each agent, what it is permitted to do, and what data it can reach. One agent may call several models and one model may serve many agents, so neither record can be derived from the other. They are also usually owned by different teams, with model registries sitting with data science and MLOps and agent registries with platform engineering or a governance lead.

Do you still need an agent registry if all your agents are on one platform?

A single-platform estate gets a partial registry for free, and the gap is usually larger than it appears. A platform-native registry records the agents built on that platform, which leaves out agents embedded in third-party software the organization has bought, agents created on any other cloud or data platform already under license, and anything built outside sanctioned tooling. It also typically records what the platform needs for operation rather than what governance needs for accountability, so fields like named owner, approval record, and review date may be absent. The practical test is whether the existing registry can produce a named owner and an approval record for every agent touching regulated data, not whether it lists the agents the platform itself deployed.

How do you keep an agent registry from going out of date?

Stop relying on people to maintain it and make accuracy a byproduct of how agents ship and run. Three mechanisms do most of the work. Automated discovery finds agents that were never registered, so the record does not depend on anyone remembering. Registration wired into the deployment pipeline means records are created by construction, because the path that issues the identifier and credentials also creates the entry. And making the record authoritative at runtime, so permissions and budget ceilings are read from it, means an inaccurate record produces an agent that does not work, which is a far stronger incentive than a governance reminder. Manually maintained registries drift because nothing breaks when they do.

Should an agent registry control deployment, or only record agents?

This is a genuine architectural disagreement rather than a settled question. One position holds that a registry should be a record only, with routing and deployment kept separate, because a record that also executes is harder to reason about and harder to replace. The other holds that a record with no enforcement path is precisely why registries fail, since nothing keeps it complete. Both optimize for different risks, architectural cleanliness against practical completeness. The useful distinction is that authority and mechanism are separable: a registry can be the authority for whether a deployment is permitted without being the system that performs it, which captures most of the enforcement benefit while keeping the record replaceable.

Who should own the agent registry?

Ownership usually works best with platform engineering running it and a governance or risk function setting what it must record. Platform engineering can wire registration into deployment pipelines, which is the mechanism that keeps the record complete, and it is close enough to the agents to notice when the record is wrong. Governance defines the schema, the approval requirements, and the review cadence, because those are policy questions rather than engineering ones. The arrangement that reliably fails is a registry owned solely by a governance function with no path into the deployment pipeline, because it can specify what should be recorded and has no way to make recording happen.

How does an agent registry support audit and regulatory compliance?

An agent registry turns compliance questions into lookups instead of investigations. In a regulated function, an action taken by an agent carries the same obligations as the same action taken by an employee, so an auditor asks who authorized this, for what scope, on what data, and under whose accountability. A registry holding an approval record, a data-access record, and a named owner answers all four from the record. Without one, each answer is reconstructed after the fact from logs and recollection, and a control that cannot be evidenced is generally treated as failed rather than as a documentation gap. The registry is also what makes the rest of the evidence usable, because audit trails and monitoring can only attribute behavior to an agent that has an identity on record.

From record to control
Could you produce a named owner for every agent you run?

The Agent Registry in CAMS auto-discovers agents built on other platforms into one unified library, manages Dev, QA, and Production environments with defined promotion workflows, and keeps an activity log with actor attribution. See it against your own environment.

Book a demo Explore CAMS