Agent registry vs. agent catalog vs. agent inventory

Ninety-six percent of organizations are already using AI agents, according to an OutSystems survey from January 2026. Only 21% maintain a real-time registry of what agents exist in their environment. Only 12% have a centralized platform to manage agent sprawl. One reason for that disconnect: the terms organizations use to describe the problem (registry, catalog, inventory) don't reliably describe the same thing across vendors, frameworks, or teams. An organization that thinks it has an agent registry may have an agent catalog. One that thinks it has an agent inventory may have a spreadsheet. The terminology matters because the solutions are different and each addresses a different failure mode.

The three concepts map to three distinct governance problems: knowing what agents exist, governing what they're authorized to do, and enabling teams to find and reuse them. All three are needed. None substitutes for another.

Agent inventory: knowing what you have

An agent inventory is a structured enumeration of all AI systems in an organization. Its primary purpose is compliance: satisfying regulatory requirements that mandate documented AI asset management, not operational enforcement of what agents can do.

NIST AI RMF GV.1.6 requires organizations to "maintain an inventory of AI systems resourced according to risk priorities." The EU AI Act requires providers of high-risk AI systems to register in an EU database, with a compliance deadline of August 2, 2026. CISA's "Careful Adoption of Agentic AI Services" guidance (May 2026) frames agent inventory in supply-chain risk terms, recommending organizations apply SBOM (Software Bill of Materials) minimum elements when procuring agentic AI: each agent should be documented as a software supply chain component with provenance, dependencies, and known risk surface.

Several characteristics distinguish an inventory from a registry. First, scope: an inventory covers all AI systems, not just deployed agents. Models, datasets, applications, workflows, and agents all belong in an inventory. A registry is agent-specific. Second, cadence: many inventory programs are periodic assessments (a quarterly review, a pre-audit scan) rather than a live, continuously updated system. Third, depth: an inventory typically records what systems exist and their risk classification. It doesn't manage permissions, enforce lifecycle controls, or generate runtime audit trails.

The SBOM analogy is useful here. An SBOM documents what software components an application contains, their provenance, and their known vulnerabilities. An agent inventory does the equivalent for deployed AI agents: what exists, who built it, what it depends on, and what risk tier it falls into. CISA has explicitly endorsed this framing, and a 2026 arxiv paper proposed extending standard SBOM schemas to cover agentic systems, including agent chains, tool integrations, and permission structures.

The inventory is the starting point. Gartner's six-step framework for managing AI agent sprawl (April 2026) puts "build centralized agent inventory" at Step 2, before identity governance, before lifecycle management, before enforcement. You can't govern what you haven't found.

Agent registry: governing what agents are authorized to do

An agent registry is the operational governance layer: each deployed agent gets a managed identity, defined permissions, a lifecycle state, and an audit trail. Where an inventory answers "what AI systems do we have," a registry answers "who is this agent, what is it allowed to do, who approved it, and what has it done."

The CMDB analogy is the most precise framing for enterprise IT buyers. A CMDB (Configuration Management Database) is the ITIL system of record for IT configuration items: every asset, service, and infrastructure component with its relationships, ownership, and change history. It's the foundation for change management, incident response, and compliance. An agent registry is the equivalent for AI agents: each agent is a configuration item with a unique identity, dependency relationships (tools, data sources, sub-agents), an approval workflow, and a complete change log.

The key components of a registry that distinguish it from an inventory: verified identity per agent (managed separately from human accounts and service principals), scoped and time-bound permissions rather than standing access, a formal lifecycle (draft, pending approval, active, deprecated, decommissioned), and an event log covering every registration, permission change, invocation, and data access. The CSA's Agentic AI NIST AI RMF Profile (March 2026) is explicit on this: for agentic deployments, NIST GV.1.6 inventory requirements must be extended to mandate registry-level dynamic tracking, because agents can spawn ephemeral sub-agents whose existence still needs to be attributable to an accountable principal.

A registry also has to cover what the inventory missed. Microsoft Agent 365 (the registry layer in Microsoft's governance stack, generally available in May 2026) explicitly surfaces "sanctioned, third-party, and emerging shadow agents." A CSA survey from April 2026 found 82% of enterprises had discovered previously unknown AI agents in their environments in the past year. A registry that catalogs only approved agents addresses less than a fifth of the actual governance surface.

For a full breakdown of what an agent registry contains and which frameworks require one, see the agent registry explainer.

Agent catalog: finding and reusing agents

An agent catalog is a discovery layer. Its primary users are developers and orchestrators looking for agents they can invoke without building from scratch. The catalog answers: what agents exist, what they do, and how to connect to them.

The term "catalog" is used in two distinct ways that are worth keeping separate.

The first is an internal discovery surface: a searchable interface built on top of the registry, exposing agent capabilities, invocation details, and metadata to developers and other agents. In this sense, the catalog is the consumer-facing front end of the registry. The registry is the system of record; the catalog is how teams query it. This is the framing TrueFoundry and most developer-platform vendors use.

The second is an external marketplace: a curated store of pre-built or third-party agents, closer to an app store than an enterprise directory. AWS Marketplace now has a dedicated AI Agents and Tools category. Microsoft has an M365 Agent Store for deploying agents to end users. Salesforce's AgentExchange is a merged marketplace for external agents. These are catalogs in the app-store sense, not in the governance sense.

Salesforce publishes the clearest vendor definition of the catalog concept: "An AI agent catalog creates a shared source of truth showing who built each agent, what systems it connects to, and where it's being used." Notably, Salesforce's definition includes "a registry layer that tracks each agent's name, owner, purpose, connected systems, and version history," positioning a catalog with governance depth as, functionally, a registry with a discovery interface on top.

The A2A (Agent2Agent) protocol's "Agent Cards" sit in this category. An Agent Card is a self-describing JSON manifest that documents an agent's capabilities, skills, authentication details, and connection endpoint. Agent Cards are the standard payload for agent discovery. What they're not is governance infrastructure: A2A doesn't define a registry API, doesn't manage permissions, and doesn't enforce lifecycle controls. The A2A spec is a catalog content standard; the registry is the governance infrastructure that hosts and manages it.

How the three relate: a sequence, not a choice

The three concepts aren't alternatives. They're sequential layers, each depending on the one before it.

An inventory establishes the compliance baseline: here are all the AI systems we run, classified by risk. A registry builds the operational governance layer on top: each agent has an identity, authorization record, and audit trail. A catalog surfaces the registry to developers and orchestrators: here's what exists and how to use it.

Gartner's sequencing makes this explicit. Step 2 of its six-step agent sprawl framework is "build centralized agent inventory." Step 3 is "define agent identity, permissions, and lifecycle model": the registry layer. The catalog emerges from the registry once the governance layer is in place.

Organizations that try to skip the sequence typically end up with one of three partial implementations: a compliance inventory that tells regulators what exists but can't enforce anything at runtime; a developer catalog that helps teams find agents but doesn't track who approved them or what they're permitted to access; or a registry that covers sanctioned agents but has no mechanism for discovering the ones that were never registered. Each is useful on its own terms. None of the three substitutes for the others.

How major platforms name their products

Platform naming doesn't reliably track the conceptual distinction. The clearest example of a vendor maintaining the separation in practice is AWS. Amazon Bedrock AgentCore includes an Agent Registry (preview, April 2026): an internal, governed system for registering, approving, and managing agents with IAM integration and formal lifecycle workflows. Separately, AWS Marketplace runs an AI Agents and Tools category (launched July 2025): an external vendor catalog for purchasing pre-built agent capabilities. Two products, two names, two purposes.

Microsoft has the most architecturally differentiated stack. Microsoft Entra Agent ID and Agent 365 (generally available May 2026) form the registry layer: managed identity per agent, Conditional Access integration, lifecycle governance, and cross-cloud registry sync with AWS Bedrock and Google Cloud in preview. The M365 Agent Store is the end-user catalog: a curated discovery surface for deploying approved agents to end users, managed via the M365 admin center. Azure API Center serves as a developer-facing registry for agent APIs, A2A protocol agents, and MCP servers.

Google's Gemini Enterprise Agent Platform (rebranded April 2026) uses "registry" and "catalog" interchangeably in its documentation: the Agent Registry is described as "a centralized, unified catalog." Google also maintains a separate Skill Registry for managing agent skills as self-contained packages, which adds a third layer beyond agent identity.

Salesforce and MuleSoft occupy the catalog end of the spectrum. Salesforce publishes "What is an AI Agent Catalog?" as its primary governance concept and frames AgentExchange as a marketplace for external agents. MuleSoft Agent Fabric (GA October 2025) is built on MuleSoft's existing Exchange catalog infrastructure, extended to cover agents and MCP servers. Salesforce's internal documentation does acknowledge a "registry layer" within the catalog, but the primary product framing is catalog-first.

ServiceNow's AI Control Tower and Collibra's AI Agent Registry (GA 2025) both use "registry" as their primary governance term, consistent with their data governance and ITSM positioning. Collibra explicitly connects agent registration to business use cases, datasets, and risk assessments, which is the closest any vendor comes to connecting the registry layer to data trust context.

What governance frameworks say

Framework terminology maps fairly predictably to the three layers.

Inventory-level requirements. NIST AI RMF GV.1.6 requires an "inventory of AI systems": enumeration and risk classification, not runtime identity management. The EU AI Act requires a compliance database registration for high-risk AI systems. CISA's agentic AI guidance uses "inventory" in supply-chain risk management contexts, referencing SBOM minimum elements as the applicable standard.

Registry-level requirements. Singapore's IMDA Model AI Governance Framework for Agentic AI (January 2026, updated May 2026) makes agent identity and registration one of its four pillars and requires a trusted agent registry with verifiable credentials and short-lived tokens. The NIST NCCoE's February 2026 concept paper on AI agent identity and authorization is focused on the registry infrastructure layer: credential lifecycle, audit trails, and non-repudiation. The CSA's Agentic AI NIST AI RMF Profile extends GV.1.6 to require registry-level dynamic tracking specifically for agentic deployments.

Catalog-level standards. The A2A protocol's Agent Card spec is the closest to a catalog standard: a common format for capability description and discovery. No major governance framework mandates a discovery catalog specifically, though the IMDA framework's "ecosystem and interaction governance" pillar implies it.

Which one your program needs

The answer depends on where your program currently is and what problem you're trying to solve.

If you need to satisfy a regulatory requirement (NIST AI RMF review, EU AI Act compliance, a pre-audit AI asset disclosure), start with inventory. Build the enumeration first, classify by risk tier, and produce a structured artifact that compliance and legal teams can work from. This is the baseline every program needs, regardless of maturity.

If agents are running in production and the concern is authorization, access controls, and accountability (what each agent is permitted to do, who approved it, and what it's done), the registry is what you need. This is where most enterprise security and AI governance teams are focused in 2026: not just knowing what exists, but enforcing policy at runtime and generating audit evidence structured for review.

If the bottleneck is developer productivity (teams building duplicate agents because they can't find what exists, or spending time on integration work that a standard discovery interface would eliminate), the catalog is the right investment. This is more a platform engineering concern than a security concern, but in large organizations it's also a governance concern: shadow agents often get built because sanctioned alternatives weren't discoverable.

For organizations where AI agents are operating on sensitive enterprise data in regulated industries, all three layers are required and the sequence matters. Inventory establishes what exists. The registry governs who each agent is and what it's allowed to touch. Connecting the registry to data classification and quality signals, so teams know not just what an agent is authorized to query but whether the data it's acting on is correctly classified, fresh, and complete, is what makes runtime agent governance auditable rather than asserted.

Bigeye's Agent Trust Hub provides the registry layer connected to the data trust layer: agent identity and authorization records alongside data classification status, lineage context, and data quality signals for every asset an agent can reach. Guardian agents enforce access controls at the point of query using current classification and policy state. For teams working through the full AI agent governance stack (inventory, registry, and enforcement), the governance article covers the frameworks, accountability requirements, and where most programs need to build.