One Registry to Rule them All - Sonny Merla, Mauro Luchetti, & Mattia Redaelli, Quantyca

What happens when dozens of teams across three continents build AI agents, each wiring its own connections, inventing its own security model and deploying its own infrastructure? The immediate problem is duplication. The longer-term problem is that the organization cannot easily see what it has built, what depends on it or who must respond when something changes.

Sonny Merla introduces this challenge from Amplifon’s perspective, alongside Mauro Luchetti and Mattia Redaelli of Quantyca, the team behind the technical solution. Their AmplifAI platform includes an enterprise registry system for MCP servers and A2A agents. Merla describes Amplifon’s hearing-care business as spanning 26 countries, more than 20,000 people and over 10,000 stores. At that scale, experimenting with AI also means finding a way to keep applications stable and scale them responsibly under centrally defined guidelines.

Amplifon launched AmplifAI in January 2025 as a global, cross-functional program with an operating model and an execution plan. A small control tower, including senior leadership, sets security, legal and technology guidelines, establishes strategic priorities and selects the first use cases. A committee carries that strategy into countries and corporate functions, prioritizing individual use cases more granularly. Central direction and local execution have distinct responsibilities.

The execution plan has three complementary parts:

• Governance: align AI adoption with regulation, strategy and central guidelines; make people aware of the program’s rules and communicate the value delivered.
• Platform: provide certified infrastructure and development practices for delivering scalable processes and services.
• Factory: give development teams responsibility for rolling out solutions to markets, with reuse across countries and business domains built into their approach.

The factory therefore needs more than permission to experiment. It needs a shared technical foundation that supports repeated delivery across the organization.

Maintenance makes dependency visibility urgent. LLMs have short life cycles, while the applications consuming them must remain useful over time. When a model changes or suffers a disruption, Amplifon wants to identify the use cases that depend on it and respond promptly. That requires tracking model usage across applications, rather than leaving the information inside individual teams.

Governance adds a related requirement: know where AI is used, what each use case implements and which assets it consumes. A catalog can establish that inventory; relationships between its records provide lineage. Together, they make it possible to inspect AI adoption for regulatory purposes and understand how technical assets support business activity.

Centralize governance while allowing teams to work on different infrastructures. Shared guidelines and reusable operational capabilities should let developers concentrate on business logic instead of repeatedly rebuilding security, deployment and maintenance. The platform’s job is to make that division practical.

The first technical component Luchetti introduces is an AI gateway. Developers point to a unified endpoint to access models in Amplifon’s catalog. Entra ID integration supplies authentication, making the gateway a common entry point for model access.

The gateway also tracks budgets assigned to use cases. A budget can cover a month, a week or another period; consumption reduces the available balance, and developers can inspect what remains. Central auditing, monitoring and analysis tools connect to the gateway to analyze model requests, responses and usage. Access, consumption and operational visibility therefore meet at the same entry point.

Beneath that entry point, three registries divide the cataloging work:

The use-case registry joins the other catalogs’ metadata so that a tool or agent can be understood in terms of the business activity it supports.

Amplifon started from the community-maintained MCP Registry, extending it with private functionality and enterprise context. Its internal catalog combines custom servers built for Amplifon systems with a curated set of public servers approved by Amplifon. Both categories receive additional metadata. This is an approved enterprise inventory, not an assumption that the public registry contains every available MCP server.

The extra fields answer operational questions that a server’s technical description alone cannot:

Cost attribution connects to the gateway’s budgeting capabilities. Consumer links support impact analysis: a server record becomes an entry point for finding affected use cases. These relationships turn metadata into an audit trail of available tooling and its use.

The A2A registry is based on Agent Cards: descriptions of an agent’s identity, endpoint, capabilities, supported modalities and authentication requirements. The standardized description provides the discovery information; Amplifon’s registry and publication workflow supply the enterprise implementation around it.

When an agent is deployed through a blueprint, its CI/CD integration automatically publishes the Agent Card to the registry. Other agents and developers can then discover the new agent and connect to it. Linking publication to deployment makes development self-documenting in a specific sense: releasing an agent also publishes the description needed to find and use it.

The use-case registry supplies the business view of those technical catalogs. It maps agents and tools to adopted use cases, records the assets they implement or consume, and identifies the models they use. Model dependencies are particularly relevant to the maintenance problem: the catalog needs to connect a model disruption to the business applications that require attention.

The same record captures development and deployment context, including the systems serving a use case and other systems it affects. Where use cases connect to one another, those relationships should be visible in a shared catalog interface. The resulting structure links business intent, implementation assets and operational dependencies.

Redaelli’s walkthrough begins at the platform home page, which links to the MCP, A2A and use-case catalogs. A separate AI gateway area defines the LLMs available within the enterprise. At the time of the walkthrough, the platform was awaiting production deployment; its catalog contained six demo entities rather than a production inventory.

Opening a sample use case exposes its status, version, description, linked assets, AI models and life-cycle history. The displayed Ticket Optimization with AI record includes an MCP server and LangChain Test Agent among its assets. The record brings the business description and its implementation dependencies into the same view.

The create-use-case form collects a name, description, status, ownership and linked assets. Moving to the AI tools section exposes the server.json records for two sample MCP servers. The A2A section similarly displays Agent Card information: the LangChain test agent’s description and capabilities come from its card. The interface presents the protocol metadata alongside the enterprise catalog records.

The platform also provides entry points for checking integrations. Selecting an MCP server on the inspector page opens an inspector in another tab, where a developer can connect and examine what the server provides. An A2A inspector checks compatibility with the Agent Card. These checks complement browsing a stored description.

Metadata wizards help developers create those descriptions. A form generates and previews an MCP server.json or an A2A Agent Card, so someone building their first server does not have to begin by editing JSON in a repository. From the use-case page, the developer can then open object lineage to inspect the relationships among catalog entries.

For Ticket Optimization with AI, the lineage view shows connections to two agents and AI models. If a linked component experiences an outage or another problem, those relationships provide a path back to the affected use case and help determine where modifications are needed. The walkthrough demonstrates dependency visibility; it does not show an automated repair.

The development workflow starts from two GitHub template repositories: one for MCP and one for A2A. Both provide FastAPI servers, Dockerfiles, package-management tooling, infrastructure and boilerplate. Authentication and cost tracking are handled inside the blueprints, giving teams a common operational starting point on the way to production.

A platform-level Langfuse integration lets development teams trace agents, run evaluations and inspect performance. For the A2A blueprint, the shared foundation does not require a particular agent framework. Teams can use LangChain, Agno or another implementation because the blueprint is organized around interfaces and ports. What must remain consistent is the interface exposed to the surrounding platform.

A small Python example illustrates that boundary: the service depends on an agent interface, while an adapter supplies the framework-specific implementation.

from typing import Protocol

from fastapi import FastAPI
from pydantic import BaseModel


class Agent(Protocol):
    async def respond(self, message: str) -> str: ...


class Request(BaseModel):
    message: str


class Response(BaseModel):
    message: str


def create_app(agent: Agent) -> FastAPI:
    app = FastAPI()

    @app.post("/respond", response_model=Response)
    async def respond(request: Request) -> Response:
        return Response(message=await agent.respond(request.message))

    return app

Here, /respond is an illustrative application endpoint, not an A2A protocol endpoint. The relevant design is the dependency direction: a team supplies an implementation of Agent, while the service boundary stays fixed. Amplifon’s blueprint applies that separation within its shared A2A service.

Both blueprints include a CI/CD publication path. Redaelli describes tagging a branch to start GitHub Actions, which performs two related publications:

1. Publish the Docker image to the artifact repository.
2. Publish the service metadata—the A2A Agent Card or MCP server.json—to the registry catalog backend/proxy.

The release workflow therefore updates both the deployable artifact and the catalog information describing the service.

At runtime, agents can reach MCP or A2A proxies through the deployed Apigee AI gateway. Each proxy looks up the requested service in the catalog and retrieves its actual backend URL. The calling agent then authenticates to the actual server using another header. This separates catalog-based destination lookup from authentication at the destination; the talk does not specify the header name or credential exchange.

Merla closes with the capability this combination provides: a catalog of MCP and A2A servers across teams, with traceability among use cases, agents, tools and models. The registry gives the organization a place to inspect what exists and how it connects, while the production-ready blueprints give developers a standard starting point for implementing business logic.

Standardized CI/CD connects those two sides by publishing service artifacts and registry metadata as part of the same delivery workflow. Platform development remains in progress, with capabilities still growing. The durable architectural choice is to make the information needed for governance a product of development and release, rather than a separate inventory exercise teams must remember afterward.