In April 2026, AWS launched Agent Registry as part of AgentCore, now in preview. The announcement led with discovery: a central catalog where teams can find, share, and reuse agents across their enterprise. That framing is instructive. It tells you exactly what most engineering teams are still missing — and why discovery is only the first layer of what needs to be built.
The harder question isn't "what agents exist?" It's "what are they allowed to do, who's responsible for them, and how do you stop one if something goes wrong?"
The Sprawl Problem Nobody Talks About
Teams that have shipped more than three AI agents into production almost universally encounter the same thing: agent sprawl. It accumulates gradually — a document processing agent here, a customer data lookup agent there, an orchestrator that calls two subagents that each call their own tools. Within six months of active development, the number of distinct agent configurations, prompts, and deployment environments has grown past what any individual team member can hold in memory.
InfoQ's coverage of the AWS AgentCore launch highlighted that organizations are running agents across multiple infrastructure platforms simultaneously — AWS, other cloud providers, and on-premises — with no unified view of what exists. Most teams have no formal catalog. When asked how they would identify every agent with write access to production data, the most common answer is: check with multiple teams.
That is the definition of an uncontrolled system.
The operational risk is concrete, not theoretical. Without a registry, incident response for a misbehaving agent means manually tracing which configuration is deployed, who made the last change, and what tools it has access to — a process that turns minutes into hours. Teams that have been through this once don't forget it. Teams that haven't yet are building toward it.
Discovery Registries vs. Governance Registries
AWS Agent Registry and LangSmith's deployment registry solve an important problem: they make it possible to find agents that have been built and registered. AWS Agent Registry supports an approval workflow (draft → pending → approved), hybrid search that blends keyword and semantic matching, and lifecycle tracking from development through retirement. LangSmith's deployment registry adds versioning, instant rollbacks, and support for MCP and A2A protocols.
These are genuinely useful tools. They solve the discovery and deployment surfaces well.
What they don't solve is the governance surface. Knowing that an agent exists is different from knowing what policies govern it, what data it can access, whether it has been approved for production under compliance requirements, and who has the authority to suspend it immediately.
The practical difference is this:
- A discovery registry says: "Agent X exists and its latest version is 1.4.2."
- A governance registry says: "Agent X is owned by the payments team, approved for PCI-scoped environments only, carries a token budget of 50,000 per request, is bound to input validation policy #7, and can be suspended by the on-call engineer via CLI."
The first is a catalog. The second is a control surface.
Helicone and Arize — strong platforms for LLM observability and evaluation respectively — don't cover the registry problem in either form. Their architectures are observability-first: you can see what an agent did after the fact. You can't systematically manage what it's allowed to do before it acts.
What a Real Agent Registry Requires
A governance registry for AI agents is not a spreadsheet and it's not a deployment manifest. At minimum, it needs to record and enforce five things.
Ownership and accountability. Every agent needs a named owner — a team or individual who is responsible for its behavior in production. This isn't just organizational hygiene; it determines who gets paged when something goes wrong and who has the authority to make changes.
Capability scope. What tools can this agent call? What data can it access? What actions is it permitted to take? These constraints should be declared at registration time and enforced at runtime — not stored as comments in a config file and trusted on the honor system.
Policy binding. Which governance policies apply to this agent? Input validation, output filtering, token budgets, escalation triggers — these should be linked to the registry record and enforced at execution time, not scattered across separate systems that may drift out of sync.
Lifecycle state. Is this agent in development, staging, production, or retired? Lifecycle state should be queryable and should carry operational meaning. Agents in development state should not be able to call production data APIs regardless of their technical configuration.
Emergency controls. The registry should be the authoritative place from which an agent can be suspended or terminated. If the path to shutting down a misbehaving agent runs through five different systems with no single authoritative interface, teams will hesitate to use it — or won't know how.
The Hacker News community has been actively experimenting with pieces of this for over a year. A wave of independent "Show HN" projects launched in 2025 and early 2026 covering agent discovery, identity verification, reputation scoring, and skill indexing. The fragmentation is a signal: the infrastructure isn't settled, and the individual pieces don't add up to an operationally complete system.
How Waxell Handles This
Waxell's agent registry is designed as a governance control surface, not a deployment catalog. Every agent registered in Waxell carries its policy bindings, ownership metadata, lifecycle state, and capability scope as first-class record attributes — not as documentation attached to a deploy script.
When an agent executes, Waxell's runtime telemetry records what it did against what its registry record says it's allowed to do. If an agent attempts an action outside its declared scope, the governance plane records and flags the violation before it reaches production systems — captured in full in the execution log with the registry record, policy binding, and action attempted.
Practically, this means a security team can audit every agent's policy bindings from a single interface. An on-call engineer can suspend a misbehaving agent in seconds via the registry. A compliance reviewer can pull the complete execution history for any agent with documented policy enforcement without needing to contact the engineering team.
The registry is also how Waxell handles fleet-level operations: rolling out policy changes across a set of agents, identifying agents approaching budget thresholds, or flagging agents that haven't had their policy bindings reviewed since an update.
This is the architectural distinction that matters: the registry isn't a catalog you maintain manually. It's a live control surface that the governance plane enforces at runtime.
FAQ
What's the difference between an agent registry and a model registry?
A model registry tracks ML model versions, training artifacts, and evaluation metrics. An agent registry tracks deployed agent configurations — which model they use, what tools they're connected to, what policies apply, and who owns them. The two are complementary but address different layers of the stack. Most MLOps platforms have mature model registries. Agent registries are a newer, less standardized infrastructure layer, and most teams building with agentic frameworks are managing them informally at best.
Can't teams just track agents in a spreadsheet or internal wiki?
For a single team running two or three agents, a wiki might work. At scale, it fails for two reasons: it doesn't enforce anything (the wiki doesn't prevent an agent from calling an API it shouldn't), and it drifts (agents get updated without the wiki reflecting it). A governance registry is live, queryable, and machine-readable — it's part of the execution path, not documentation that lives alongside it.
Does AWS Agent Registry solve the governance problem?
AWS Agent Registry (AgentCore, launched April 2026) solves the discovery and lifecycle tracking problem well. It doesn't natively enforce policy bindings or connect the registry to runtime enforcement. It's a strong foundation for catalog management. Organizations that need runtime governance will need to layer policy enforcement on top — the catalog and the control surface are separate problems.
What should an agent registry look like for a regulated industry?
For teams operating under HIPAA, PCI-DSS, or EU AI Act requirements, the registry needs compliance-ready metadata: data classification of what the agent can access, documented approval status, and an immutable audit log of every registry change. Regulated teams should ensure the registry supports policy versioning — so that the policy binding in effect at the time of any specific execution can be reconstructed during an audit.
How does agent versioning work with a governance registry?
Each agent version should have a distinct registry record capturing which policy set was bound, what capability scope was declared, and whether it was approved for production. A rollback isn't just reverting code — it also means restoring previous policy bindings and confirming the runtime is enforcing the older configuration. Without version-aware policy bindings, a code rollback doesn't undo a policy change that was applied separately.
What's the first step for a team with no agent registry at all?
Start with an inventory: enumerate every agent configuration running in production, what data it has access to, and who owns it. Even doing this once as a manual exercise reveals gaps quickly. The inventory should then be migrated into a system that enforces — not just records — ownership and capability scope. The migration is worth completing before the fleet grows further; the larger the fleet, the harder the retroactive governance problem becomes.
Sources
AWS Agent Registry for centralized agent discovery and governance is now available in Preview — AWS What's New, April 2026. Verified: launch announcement confirms AgentCore preview, discovery catalog framing, approval workflow (draft → pending → approved).
The future of managing agents at scale: AWS Agent Registry now in preview — AWS Machine Learning Blog, April 2026. Verified: describes hybrid keyword/semantic search, lifecycle tracking from development through retirement, team sharing model.
AWS Launches Agent Registry in Preview to Govern AI Agent Sprawl across Enterprises — InfoQ, April 2026. Referenced for context on multi-platform agent tracking across AWS, other cloud providers, and on-premises environments.
LangSmith: Agent Deployment Infrastructure for Production AI Agents — LangChain.com. Verified: confirms registry, versioning, instant rollbacks, MCP/A2A protocol support.
Show HN: A minimal identity registry for AI agents — Hacker News. Representative of independent community efforts to solve agent identity and discovery infrastructure in 2025–2026.
Show HN: AgentLookup – A public registry where AI agents find each other — Hacker News. One of multiple community-built registry and discovery projects launching in the same period.
Top comments (0)