Definitions
“Registry,” “inventory” and “catalog” are not universal product categories with one agreed boundary. Define the terms for your architecture. In this guide, an inventory is the owner-validated record of systems or deployments, their purpose, boundaries, data, permissions and governance evidence. A registry is an operationally queryable source of identifiers and metadata used to publish, find or resolve available agents, tools or services. A catalog is a curated discovery view for people or software; it may read from a registry or be the registry's user interface.
A single product can combine these functions, and a spreadsheet can serve as an inventory without being a runtime registry. Check what a vendor's product actually stores, validates, discovers and exposes instead of relying on its label.
What each is for
- Inventory: answer “what is this system for, who is accountable, what data/actions are in scope, and what review evidence applies?”
- Registry: answer “what resource is available, under which stable identifier/version, where is its interface, who may discover it, and what metadata or protocol does it expose?”
- Catalog: help an intended audience browse, filter or search the approved entries and understand how to request or connect to them.
These are operational distinctions, not standards definitions. NIST AI RMF 1.0 MAP asks organisations to document system purpose, context and components; that governance record remains useful whether runtime metadata lives in a registry, catalogue or configuration repository. NIST describes the AI RMF as voluntary and says version 1.0 is being revised.
For a current vendor example, AWS documentation describes AWS Agent Registry as a managed catalog for agents, tools, skills, MCP servers and custom resources, with searchable records and approval controls. AWS's own term “registry” describes that specific product. Its existence does not establish a universal definition or mean the registry replaces an organisation's owner-validated risk and governance records. See the AWS Agent Registry documentation and AWS's 7 September 2026 availability announcement.
Who owns it
Assign a business/system owner to validate purpose, users, data, permitted actions and governance decisions. Assign a platform or service owner to maintain registry identifiers, versions, endpoints, access policy and lifecycle state. A person may hold both roles, but the responsibilities should remain explicit. A registry publisher should not be able to mark their own record “approved” unless the organisation's policy allows it and records the review.
Choose a source of authority for each field. The registry may be authoritative for a published endpoint or revision; the system owner may be authoritative for purpose and business accountability; a controlled risk register may be authoritative for assessment status. Link them with a stable ID and retain evidence dates. A discoverable entry does not prove approval, completeness, safety or legal compliance.
When to use which
Use a maintained inventory when owners need to reconcile systems, understand intended use, track data and permissions, or link assessments and change decisions. Add a registry when multiple teams or compatible clients need reliable discovery, version resolution, publication approval or machine-readable metadata. Provide a catalog view when people need to search and compare approved entries.
Before adopting a registry, ask: Which assets can it register and discover? Does discovery cover only one cloud/provider or also on-premises and other environments? Are records manual, imported or verified against live endpoints? How are versions and deprecations handled? Who can publish, approve, search and invoke? Can data be exported and linked to the organisation's inventory and evidence? Do not treat a supported connector list as proof of complete coverage.
Starter approach
Hypothetical example: the owner records `support-draft-prod` in the governance inventory with its purpose, support-team owner, internal data category, draft-only action and human review. A runtime registry record `agent://support-draft/prod` points to deployed revision `r12` and its interface. The stable ID links the two records. If revision `r13` adds a ticket-write tool, the platform owner updates the registry metadata and the system owner reviews the permission and approval evidence before the inventory is marked reviewed. These sample IDs and records are illustrative, not discovered assets or a site feature.
For a small team, begin with a controlled inventory and a stable ID column. Use existing deployment/configuration records as evidence for endpoint and revision fields. Add a separate registry only when there is a real discovery or lifecycle-management need. Keep assessment decisions and supporting evidence in their approved system of record.
The local Agent Inventory Tool is a browser-side manual starter: it flags missing context and downloads a CSV and offers browser print/save-to-PDF, but does not host a registry API, sync deployed agents, scan infrastructure, or verify completeness. A CSV inventory is not a live catalog.
Continue with the AI agent inventory builder, the AI inventory template, or the AI agent inventory template.
Sources: AWS Agent Registry documentation; AWS availability announcement (7 September 2026); NIST AI RMF 1.0; NIST AI RMF status.