The Registry Layer Every AI Agent Team Is Missing

The real enterprise agent problem isn't intelligence. It's inventory. Who owns this agent? What tools does it call? Which model version is it running? Most companies can't answer these questions for a single agent, let alone fifty.

Sonny Merla explains in One Registry to Rule them All—Amplifon, operating across 26 countries with 20,000+ people and over 10,000 stores, launched a centralized registry for MCP servers and A2A agents because the alternative was chaos. Not hypothetical chaos. Dozens of teams on three continents, each wiring up their own security, deployments, everything.

I've watched the governance gap widen in real time. Teams build agents fast. Nobody tracks what they connect to or what breaks when a model gets deprecated. Amplifon's approach—treating discovery and metadata as first-class infrastructure—is boring, essential work that separates platforms from science projects.

The Sprawl Problem

What happens when you have dozen of teams across three continents all building AI agents, each one wiring up their own connections, reinventing their own security model, deploying their own infrastructures? You get chaos. — Sonny Merla, Amplifon

Merla opened with this, and it's the cleanest framing of why enterprise agent adoption stalls. Not because the technology doesn't work—because nobody can see what's deployed or how it connects to everything else.

Amplifon launched their "Amplify" program in January 2025 around three pillars: governance, platform, and factory. Governance sets the rules. Platform provides infrastructure. Factory is where teams build and ship. Without that separation, every team becomes its own platform team—and platform-by-accident is how you get agent sprawl.

Three Registries, One Catalog

Here's where the architecture gets interesting. Amplifon didn't build one registry. They built three: an MCP registry (tools and integrations), an A2A registry (agent-to-agent discovery via agent cards), and a use-case registry that links agents, tools, models, and systems together.

Each MCP server gets enriched with enterprise metadata—ownership, environment, authentication model, cost attribution, and use-case linkage. Mauro Luchetti put it bluntly: "Each server has an owner." Ownership as first-class metadata. Not an afterthought buried in a Confluence page nobody reads.

These are not simply metadata that are nice to have. This is something that really bring out the impact analysis functionality. — Mauro Luchetti, Quantyca

That impact analysis piece stopped me for a second. If you know which agents use which MCP servers and which models power which use cases, you can actually answer "what breaks if we deprecate GPT-4o?" without a two-week scavenger hunt. Most organizations can't answer that question at all.

CI/CD as the Discovery Layer

The operational detail that caught me off guard: agent discovery isn't manual. When a developer tags a branch, GitHub Actions publishes both the Docker image and the metadata artifact—agent card for A2A, server.json for MCP—directly into the registry.

When an agent is deployed, it automatically publishes its agent card to the registry via CICD integration. — Mauro Luchetti, Quantyca

Self-documenting agents. The usual approach is documentation as an afterthought—someone updates a wiki, maybe. Tying metadata publication to the deployment pipeline removes the opt-in problem entirely.

Mattia Redaelli added a key detail: the template repositories are framework-agnostic. Teams use LangChain, Agno, whatever—as long as the external interface matches the blueprint contract. Standardize the surface, not the internals. At ENVAIO, shipping IoT products with hardware constraints taught me the same lesson from the other direction: force consistency at the integration boundary, give teams freedom everywhere else.

The Metadata Maintenance Question

But here's the catch—and the speakers didn't address it much. Registries are only as good as the data in them. Day one, everything is clean. Six months later? Ownership changes hands. Teams get reorganized. Servers get forked and nobody updates the metadata.

The CI/CD integration helps with initial registration. But updates, deprecations, ownership transfers? That's the hard part. The strongest argument against centralized registries isn't that they're unnecessary—it's that maintaining them compounds as operational work, and most organizations underestimate the effort.

(Still—I'd rather have a stale registry than no registry. At least you know where to start looking.)

Too Much Platform, Too Soon?

One question I keep turning over: is this the right sequence? Amplifon is building MCP and A2A registry infrastructure while—by their own admission—the platform is still heading to production. The demo used sample data.

That's not a criticism, exactly. You have to build the runway before the planes land. But enterprise platform teams sometimes build elaborate governance layers for ecosystems that never materialize at planned scale. Simpler workflow-based solutions, validated with two or three teams, might prove out the model faster. Then again, at 26 countries and 10,000 stores, Amplifon's scale might justify the upfront investment in ways smaller organizations can't match.

Why This Matters

Every enterprise AI strategy deck mentions "governance." Almost none specify what it looks like in practice. Amplifon's registry system goes beyond policy documents into platform infrastructure—metadata schemas, automated discovery, lineage tracking, CI/CD-integrated publishing.

The gap between "we have an AI governance framework" and "we can trace which agent uses which tool, model, and system in production" is enormous. One is a PDF. The other is a platform.

What Works

Treat agent metadata as a deployment artifact, not documentation. If publishing metadata isn't part of CI/CD, it won't happen. Amplifon's GitHub Actions integration is the right pattern.

Build registries before you need them. Retrofitting governance onto an existing agent ecosystem is far more expensive than baking it in from the start.

Standardize interfaces, not implementations. Framework-agnostic blueprints with fixed external contracts give teams autonomy without creating integration nightmares.

Invest in lineage. Knowing which agents exist is useful. Knowing how they connect to models, tools, and systems is where governance actually works. Impact analysis requires the graph, not just the nodes.

Caveat: this architecture is pre-production. Amplifon is transparent about that. The patterns are proven individually—but the compound effect at global scale hasn't been battle-tested yet. Watch this space.

Full talk: Watch on YouTube