The agent sprawl problem begins the moment two teams build the same capability without knowing the other one exists.
Enterprise AI governance usually starts with an inventory spreadsheet: models, use cases, owners, risk classes and vendors. That is necessary while the estate is small. Agentic systems make the inventory much more dynamic.
An agent can depend on skills, tools, MCP servers, prompts, policies, models and other agents. Each component may have its own lifecycle and owner. Discovery also becomes part of runtime: builders and agents need to find approved capabilities rather than recreate or hard-code them.
AWS made its Agent Registry generally available on 31 August 2026 as a searchable, governed catalogue for agents, tools, skills, MCP servers and custom resources, with ownership, approval workflows, audit, infrastructure-as-code and cross-account discovery.
The interesting enterprise pattern resembles a CMDB for delegated intelligence.
Discovery without governance creates shadow capability
If every developer can discover every internal tool, reuse improves but exposure expands.
If nothing is discoverable, teams create duplicates and shadow integrations.
A registry needs to answer both:
What exists?
and
What are you allowed to know exists and use?
Records should therefore be permission-aware. Sensitive capabilities may be visible only to specific teams or environments.
Discovery is a governance surface.
Every agent needs an owner
A production registry record should contain more than a name and description.
Useful metadata includes:
- accountable business owner;
- technical owner;
- purpose;
- approved environments;
- data classifications;
- allowed users or agents;
- models and runtimes;
- tools and dependencies;
- risk tier;
- current version;
- evaluation status;
- last review;
- deprecation date;
- incident contact;
- cost centre.
The registry becomes the place from which an organisation can answer, “Who is responsible for this autonomous capability?”
That question becomes critical during incidents.
Register skills and tools, not just agents
Focusing only on top-level agents misses much of the risk and reuse opportunity.
A “change supplier address” capability might be:
- embedded inside three agents;
- exposed as an MCP tool;
- packaged as a reusable skill;
- called by a workflow;
- available to a coding agent.
The organisation should be able to trace those relationships.
If a vulnerable tool must be withdrawn, the registry should reveal every dependent agent.
This turns inventory into dependency intelligence.
Approval should be lifecycle-aware
Registration is not approval.
A robust lifecycle might be:
DRAFT → EVALUATED → APPROVED → PRODUCTION → DEPRECATED → RETIRED
Promotion can require evidence:
- evaluation threshold passed;
- owner assigned;
- security review;
- data review;
- rollback defined;
- telemetry enabled;
- policy attached.
The registry should expose the current governance state, not imply that discoverable equals safe.
Infrastructure as code matters
As the registry becomes operational infrastructure, manual console records are not enough.
Records and policies should be reproducible through CI/CD, with:
- version control;
- change review;
- environment promotion;
- tags;
- automated ownership checks;
- drift detection.
That keeps the catalogue aligned with what actually runs.
Automatic discovery can help, but discovered assets should enter a controlled state until reviewed.
Multi-vendor estates need a logical registry above provider catalogues
Large organisations will not run every agent on one cloud.
Provider-native registries are useful. Enterprise governance still needs a logical view that can span:
- cloud A;
- cloud B;
- SaaS agents;
- self-hosted runtimes;
- departmental automation;
- third-party agents.
The physical catalogues may remain distributed while the governance metadata is federated.
The Lexdatum view
An agent registry is not a marketplace of clever bots. It is the control inventory for machine-executable organisational capability.
Done well, it reduces duplication, improves discovery, supports incident response and gives governance something concrete to manage.
Before an enterprise asks how to orchestrate thousands of agents, it should be able to answer a simpler question:
Which agents, tools and skills exist today—and who owns every one of them?
Sources
Research note: This analysis is based on public information available on 1 September 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported claims are identified as such. This is not legal, security, financial or investment advice.