AWS shipped a registry for AI agents in Bedrock AgentCore. Centralized discovery, metadata, governance controls, audit trails. One place to track what agents you have, what they’re allowed to do, and who can invoke them.
My first reaction: this is the right problem to be solving.
The Problem Nobody Is Talking About Yet
Most writing about AI agents focuses on capability — what a given agent can do, how accurate it is, how fast it runs. Almost none of it focuses on what happens after you have ten of them.
I can speak to this from experience, not speculation. Arc & Anchor is running ten agents right now: PA, intelligence analyst, finance, compliance, infrastructure, content, research, hiring, a CTO transition coordinator, and an orchestrator to route between them. It took about two weeks to go from zero to ten. That pace is not unusual if you’re building with current tools.
At ten agents, the governance overhead is manageable. I have profiles in markdown, a task board, a clear convention for how agents hand off to each other. It works.
At fifty agents — which is where a mid-sized enterprise is likely to be within 18 months — markdown files won’t be enough.
What the Registry Gets Right
The registry addresses the central failure mode of agent sprawl: agents get built, deployed, and forgotten. Nobody documents what they do. Permissions accumulate. When something goes wrong, no one knows which agent touched which system.
Centralized discovery means you have one authoritative answer to “what agents are running in this organization.” Governance controls mean you can express policies — which agents can call external APIs, which require approval before invoking, which are allowed access to sensitive data — in a form that the system enforces rather than the honor system.
Audit trails are the piece I find most important. When an agent chain produces an unexpected outcome — and they will — you need to reconstruct exactly what happened: which agent was invoked, with what inputs, what it called downstream, what it returned. Without that, debugging a multi-agent system is archaeology.
What It Doesn’t Solve
The registry doesn’t solve the problem of knowing what your agents should be doing in the first place.
I’ve spent more time on agent design — what scope does each agent have, what are the handoff conditions, where do the boundaries sit — than on any technical implementation detail. The interesting governance questions aren’t “where is agent X registered.” They’re: does agent X have the right scope, does it know when to escalate rather than act, does the human in the loop have enough visibility to make good decisions quickly?
Those are design problems. A registry tells you what exists. It doesn’t tell you whether what exists is well-designed.
Where This Goes
AWS building this infrastructure is a bet that in 12–18 months, enterprises will have multi-agent systems that are too large to govern manually. They’re right.
The teams that will be in a good position when that’s true are the ones that treat agent governance as a first-class concern now, before scale makes it a crisis. That means: clear scope definitions for each agent, documented handoff conventions, audit capability from day one, and explicit policies on what agents can do autonomously versus what requires human confirmation.
At Arc & Anchor’s current scale, the markdown-and-task-board approach works. But I’m already designing toward isolation — each agent eventually running as its own container with its own credentials and constraints. The registry model is the right target architecture: a system where you can look up any agent, see what it’s permitted to do, and trace any action it took.
The capability curve for AI agents is steep. The governance infrastructure is catching up. Teams that get ahead of this now will have significantly less cleanup to do later.