AI Engineer Europe 2026
One Registry to Rule them All - Sonny Merla, Mauro Luchetti, & Mattia Redaelli, Quantyca
Read the talk
One Registry to Rule Them All: Connecting Enterprise Agents to Their Use Cases
Amplifon’s agent platform combines a shared AI gateway, linked MCP and A2A catalogs, and deployment blueprints to make distributed development visible and governable.
From a talk by Sonny Merla, Mauro Luchetti and Mattia Redaelli
Before you start: Familiarity with LLM agents, APIs and CI/CD will help; MCP catalogs describe tools and integrations, while A2A Agent Cards describe agents that other software can discover and contact.
When every team builds its own infrastructure
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Separate strategic control from delivery
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Know what changes will affect
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A shared gateway above three linked registries
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:
| Registry | What it records | What it enables |
|---|---|---|
| MCP | Tools, system integrations and model-accessible functionality | Discovery of available tooling |
| A2A | Implemented agents and their standard Agent Cards | Discovery and reuse of existing agents |
| Use case | Relationships among business use cases and technical assets | Governance and lineage |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make MCP records useful for operations
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:
| Metadata | Question it answers |
|---|---|
| Ownership | Which team, use case or project is responsible? |
| Environment | Is this server running in development, test or production? |
| Authentication | What must a developer do to access it? |
| Cost attribution | Which server is incurring spending? |
| Use-case linkage | Which use cases consume this server? |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Publish Agent Cards with deployments
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect technical assets to business use cases
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From catalog entries to inspectable records
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Inspect integrations and trace affected use cases
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Standardize the service boundary, preserve framework choice
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.
python
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Release the service and its metadata together
Both blueprints include a CI/CD publication path. Redaelli describes tagging a branch to start GitHub Actions, which performs two related publications:
- Publish the Docker image to the artifact repository.
- 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make governance part of delivery
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Official community registry implementation and documentation for publishing and discovering MCP server metadata.
An open-source platform for tracing LLM applications, analyzing usage and evaluating outputs.
Further reading
Explains Agent Cards, curated catalogs, private discovery and protection of sensitive agent metadata.
Updates since the talk
Documentation updated August 26, 2026 covering AI traffic governance, MCP security, routing and token quotas.
Read the complete timestamped transcript
- 0:03
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?
- 0:14
You get chaos. Hi, I'm Sonny Merla, Global Data Science and AI Manager at Amplifon, and I'm here today with Mauro Luchetti, AI Center of Ex-Excellence Manager, and Mattia Redaelli, AI Engineer at Quantyca, the team that design and build the technical solution that we are about to describe.
- 0:31
Today, we are going to show you how Amplifon tackled down this problem by launching their own Amplify program, and specifically how we design an enterprise-grade registry system for MCP and the A2A agents.
- 0:45
For who don't know Amplifon, Amplifon is the world leader, uh, in hearing care solutions. Um, we operate across twenty-six countries around the globe. We are, uh, more than twenty thousand people, and we operate over ten thousand stores across the globe.
- 0:58
Uh, we are in the AI transformation right now. We are experimenting with AI solutions, technologies, and so we are facing challenges like building solutions that are stable over time and understanding how to make them scale responsibly accordingly to guidelines that are defined centrally.
- 1:17
So how Amplifon decided to adopt AI at scale? We launched in January 2025, the AmplifAI program. Uh, it's a global and cross-functional program designed to, uh, set the rules for the AI adoption, and it is basic-basically composed by, uh, an operating model and an execution plan.
- 1:35
The operating model is based on two main souls, the control tower and the committee. The control tower is a limited set of people, including chief, deci-deciding what are the guidelines for security, legal, technology, but also, uh, what are the strategy, the, the focus for the strategy, and so the use cases, uh, to developers first.
- 1:55
Then there is the committee, uh, that has the responsibility for running the strategy in the countries, but also in the, the corporate side. So prioritizing also the use cases more granularly, also to, to release the value to the organization.
- 2:11
Which are the main focus of the AmplifAI program? We have three of them: governance, platform, and factory. So the governance, we want to ensure the alignment with the AI regulatory, also the strategy and the guidelines that we define centrally.
- 2:25
So it's also a matter of make the people aware of the existence of a program, the also the rules of the play, and also then, uh, make all the people informed of how we deliver and roll out the value.
- 2:38
Then there is the platform side. So we have, uh, to set up the infrastructure on which we operate as developers and implementation teams. So certifying infrastructures and way of working to deliver processes and also services to, um, scale AI application.
- 2:57
Then we have the, the factory. So this is the most practical, uh, part of the story. So we have the development teams that needs to have, uh, a focus on rolling out solutions to the market.
- 3:09
Also caring about the, uh, rollout across countries that is very important for, for Amplifon. So thinking about the solution as scalable, scalable and also reusable across different domains. So which are the main problems that we see as an organization that tries to roll out AI at scale in a pervasive way in the organization?
- 3:29
So we foresee for sure, uh, maintenance and operations, uh, problems, uh, governance and compliance problems, but also enterprise scaling, so how the developers, uh, needs to, uh, develop to make the, the solution stable over time.
- 3:44
Um, starting from the maintenance and operations side, uh, even the short life cycle of the LLM models that are at the core of the AI application and the AI agents that we develop and roll out, we want to be sure that we are able to address, um, the, the usage of these kind of LLE-LLMs across the, the
- 4:03
use cases that we, we roll out. So we want to be ready and prepared to act promptly every time we, we see a disruption in the model we use in the use case.
- 4:13
Um, on the other side, with the governance and compliance view, we need to be sure, uh, to know about where we use AI in the organization, what are the main use cases, also for the regulatory point of view, but also for the usage, um, across the organization.
- 4:29
So we want to have a catalog. We want to have a way to understand also the assets used by the single, uh, use cases. So what they implemented, what they used, um, to also create a sort of, um, lineage of the information.
- 4:43
On the other side then, there is a, a point, uh, related to the, the way we develop AI solution in the organization across multiple teams that operates on different infrastructures.
- 4:53
So we want to make the developments, uh, at least in terms of governance, centralized. Then so with clear guidelines, uh, reusable also on different infrastructures and different teams. This is the, the goal.
- 5:07
So we, we want to make easy the life of developers to focus on the business logic inside the use cases, avoiding to reinvent the wheel every time we need to, to take, to take care about the security, uh, but also the deployment, uh, and maintenance of the, the use cases.
- 5:24
So now I let Mauro to introduce how we address these topics, uh, at Amplifon.
- 5:30
Thank you, Sonny. And, uh, let's try to bring a more technical point of view in this. Uh, the first component, uh, that we built, uh, in order to, uh, you know, let's try, uh, try to, to address those problems are, uh, an AI gateway.
- 5:44
Um, first of all, it brings us, uh, unified access. Uh, so all the, uh, developers that want to use a model, uh, they can, uh, use this, uh, gateway, and, uh, they can point to, uh, the unified endpoint and, uh, use, uh, all the models that Amplifon has, uh, in, uh, uh, in, uh, its catalog.
- 6:08
Uh, then there's a security aspect. Um, uh, if you want to use the models, you have to, uh, you know, connect to the gateway. You have to, uh, authenticate yourself and, uh, we have done this, uh, with the intra-Entra ID, uh, integration.
- 6:25
Uh, then there's, uh, a budgeting aspect because, uh, obviously Amplifon has lots of use cases. And if a use case came to you and asked for, you know, for budget for using those, uh, those model, uh, you can set in this AI gateway, uh, a budget.
- 6:41
So, uh, um, a, a cost, a monthly cost or, I mean, you can set it monthly, weekly and so on, but you can set a budget and, uh, while the developers are using, uh, those budget, it erodes and it can, uh, brings to developers, uh, you know, the remaining part of those budget, so they can, they can
- 7:03
control it. And then there's the, uh, the, the control aspect. Uh, so all the, the, uh, you know, all the, um, uh, requests that, uh, um, are, are done through, uh, LLM models or responses, all the, the, all the analytics, uh, that we need to put in place, uh, um, on top of all the requests are done
- 7:27
using, uh, a central auditing, monitoring and analysis tools obviously connected to this AI gateway. And then for the, uh, governance part, I mean, this is the entry point. This is the top layer, I would say.
- 7:42
And then we have three different, uh, registries. Uh, the first one is the MCP registry. So as you, as you can, uh, imagine, all the tools, all the integration with Amplifon systems, uh, all the functionalities that we want to provide to LLM models are exposed through this MCP registry, uh, which is the, the, the central catalog of
- 8:03
all, all, uh, available tools. Uh, then there's the, uh, eight-way, uh, Agent2Agent registry. So, uh, it brings-- Uh, it's a full catalog of full, uh, implemented, uh, full available, uh, agents, and it uses agent card, uh, standard.
- 8:20
It exposes agent card and also, uh, it can, um, it can, uh, give the developer the ability to connect to, uh, already, uh, developed, uh, agents. And then there's the use-case registry, which is the, uh, you know, the registry that connects the-- connect all those, uh, all those, uh, information together, all those metadata together, and, uh, bring
- 8:44
out the real governance functionality, the lineage functionality, and, uh, again, connects all those aspect, uh, together. Let's try to go, uh, in more detail about each of those registry.
- 8:57
Um, I don't want to, uh, obviously, uh, tell anybody what MCP is, not at this conference. Uh, but we started from the, uh, official MCP registry, uh, maintained by the community.
- 9:09
Uh, this is the, you know, the, the public community-wide catalog of all available MCP servers. Um, and, uh, we essentially build on top of that. So, uh, Amplifon has built, uh, its own, uh, private MCP registry as an extension, um, in functionalities and also in, uh, you know, enterprise context that we want to add to each of
- 9:33
the, uh, registered, uh, servers. Um, it contains two main things, uh, as you can imagine. The, uh, you know, the custom internal servers that, uh, the, the, the internal Amplifon team have built for specific systems, specific integration, specific tool that Amplifon want to provide.
- 9:53
And also a curated set of, uh, public server that have been approved, that have been, you know, um, certified by Amplifon, uh, for, for, for Amplifon use cases. And, uh, both these servers that we want, that we registered in, in, in this catalog are enriched with some additional, uh, enterprise metadata.
- 10:13
Uh, let's, let's see what are those metadata. Uh, first of all, the ownership. Uh, each server has an owner. Uh, so which is-- Which team, uh, which use case, which project is in a way, uh, owner is responsible for that specific server.
- 10:31
Um, what are the environment in, in which the server is running? So it is running, is it running in dev, test, prod, and so on? Uh, what are the authentication model?
- 10:41
Uh, so, um, how I can effect-- Uh, how I can, as a developer, use, uh, that server? What are the, uh, mechanism that I, uh, need to put in place?
- 10:52
Um, the cost attribution. So, uh, this is linked to the AI gateway functionality, the budgeting aspect that, that we have described before. And, uh, uh, this is done in order to see, uh, what server, uh, is, is spending what, essentially.
- 11:07
And, uh, then the, uh, use case linkage. So, uh, what are the use cases that are, uh, effect-- That are actually using that specific, that specific server? And these are not, uh, simply, you know, metadata that are nice to have.
- 11:22
This is something that really, uh, bring out the impact analysis functionality. This is where, uh, effectively we enable the governance and the auditability, uh, and we have the complete trail of
- 11:36
What AI tooling exists and how, uh, they're, they're being, uh, used by, uh, Amplifon developers. And then we have a second registry, which is the A2A registry. Uh, this is fully based on the agent card, um, that, you know, describe the agent's identity, uh, its endpoint, um, uh, the agent capabilities, the supported, uh, modalities, authentication requirements, and
- 12:01
so on. Um, we, um, have built some blueprints, and then we talk, uh, about those blueprints. But essentially, when an agent is deployed, um, it automatically publish, uh, publishes its agent card to the registry via CI/CD, uh, integration.
- 12:19
So, uh, in this way, any other agent, any other, uh, developer can discover this new agent and obviously can interact with it. Um, so in a way, we, uh, are trying to make, uh, all those, uh, agent development self-documenting.
- 12:36
Now we will see how use-case registry connects those two other registry together.
- 12:43
So how do we can use, uh, the MCP registry and A2A registry from a business point of view? We want to have a use-case registry, so to map the agents and the tools in specific use case adopted across the organization.
- 13:00
And this is the reason why we designed, uh, this specific building block that aims to contain the information of, uh, what are the assets used by the single, uh, use case, what they implement, what are the models they used also for the maintenance topic that we mentioned before, and also, uh, understand how, uh, and where we develop
- 13:21
and deploy these kind of use cases. For example, which is the system that serve the use case and specific use case, uh, and what are all the other impacted by, uh, this use case.
- 13:32
So for example, if we have connection among multiple, uh, use cases, we want to see that clearly in an interface that can be a catalog for, for everyone. Well, let's see now how it works in practice.
- 13:45
So, uh, let's go in a walkthrough of the, the platform that we developed and that implement all these registries, uh, for the organization.
- 13:54
Okay, so we wanted also to give you a brief overview of our platform. Uh, here you can see that is the, uh, home page. Uh, you can go into the catalog, so what we described, uh, in detail before, so MCP, A2A, and use cases.
- 14:09
Uh, we also have the, uh, AI gateway part where we define, uh, what LLMs are, um, available, um, in the enterprise, uh, right now. Um, going back to the dashboard, if we move on to the catalog, um, this is the platform that we are going to, uh, deploy in production soon.
- 14:29
Uh, here we have, uh, demo data. Um, so we have six entities defined, um, until this point. Um, we have use cases, MCP, and A2A agents. Um, going into the, uh, use cases part, if we open a sample use case, for instance, we can define, uh, its status, uh, its version, its description, uh, uh, assets
- 14:54
used, so for instance, an agent and an MCP server, uh, what AI models it's using, uh, and the life cycle history of the, uh, of the use case.
- 15:06
Uh, if we go onto the, um, create use case page, uh, you can see that we can define a name, a description, uh, the status of the use case, the ownership, uh, and also the assets linked to that.
- 15:21
Um, if we move to the AI tools section, so MCP servers, um, you can see that we have two sample, um, MCP servers. So, um, the actual, uh, server JSON is, is described here.
- 15:39
Uh, we can also see into the, uh, A2A agents the same, uh, thing for, uh, agent cards. So for instance, uh, here we can define the... We can have the, uh, LangChain test agent that has, uh, these, uh, capabilities and description from the agent card.
- 15:56
Um, we also define the inspector page where you can, um, select, uh, an MCP server, and you can launch, uh, the inspector in another tab, so you can also connect and, uh, check what that MCP is, uh, providing you.
- 16:14
Uh, we also have the same inspector, uh, that is just checking for, um, uh, compatibility with the, uh, A2A, uh, agent card, and you can do the same here.
- 16:27
Uh, we also have wizards, uh, so you can, um, in order to make the life of the developer easier, um, define the server.json for MCP and the agent card for A2A with a form, uh, and then preview it, uh, here instead of starting from, uh, the actual JSON on the repo if it's the first, uh, let's say,
- 16:51
server for you. Um, we can, uh, also check the lineage, uh, because for instance, you can go onto the use case, open, uh, a use case that you want to check, open the object lineage.
- 17:05
In this lineage view, you can see that, for instance, the use case, um, uh, here that is ticket optimization with AI, uh, is connected to an agent, is connected to another agent here, and also has AI models connected to it.
- 17:25
Uh, so we can have the, uh, full lineage of the use case and also be able, as Mauro said before, to, um,
- 17:35
be sure and also, uh, make modifications in case some parts of the lineage are affected by an outage or a problem, and, uh, go back to the use case affected.
- 17:47
So, uh, moving into the enterprise development cycle. So, uh, we talked a lot about, uh, metadata and registries, uh, but how do actually, uh, Amplifon developers, uh, develop, uh, MCP servers and Agent2Agent servers to, uh, deploy them in production?
- 18:08
Uh, we deployed and developed two repositories, uh, one for MCP and one for Agent2Agent protocol. Uh, these two repositories are template repositories on GitHub, so then, uh, developers and teams can start from, from them and, uh, work their way up to a production, uh, environment.
- 18:29
Um, the idea is that these two blueprints actually have, uh, boilerplates, uh, provided, uh, and also, uh, infrastructure and tooling, uh, already present. So for instance, Docker files, uh, package manager, um, both are gFast API servers, so they are exposed in the same way, um, and also the authentication, uh, and cost rat- cost tracking
- 18:54
is handled inside the, the blueprint. We also have an integration, uh, to Langfuse, uh, which is an observability tool, uh, that we deployed at the platform level. Uh, so the, uh, development teams, uh, can also trace their agents, uh, run evaluations, uh, and check, uh, how the agent is performing.
- 19:17
Um, also the, um, A2A server blueprint is agnostic, so it's not based on a particular framework, so LangChain or Agno or, um, any other framework. But actually it's composed of interfaces and, uh, ports, uh, so that every team can implement their own solution, um, in, uh, their framework of choice.
- 19:41
Um, the important thing is that they provide the same interface, uh, that we, uh, saved in the, in the blueprint so that, uh, the development is, uh, easy on the developers and they can focus on the actual value of the agent.
- 20:00
Oh, um, Mauro talked about the, um, CI/CD, uh, that is in place in the, um, uh, A2A, uh, blueprint and also the MCP blueprint. Uh, the idea is that, uh, once you are ready with, uh, your, uh, development, uh, you can tag, uh, a certain branch and, uh, GitHub Actions.
- 20:23
So, um, starts and, uh, uh, all-- not only publishes the Docker image on our artifact repository, uh, but also publishes the metadata, uh, of that agent, so the agent card for, uh, Agent2Agent protocol and the server.json, uh, for MCP, uh, onto the, uh, backend, uh, let's say proxy of the, the
- 20:48
catalog of the registries. Um, in this image, we can also see that, um, in case an AI agent, uh, needs to call, uh, either an MCP or an A2A proxy, um, the idea is that they can go through the, um, Apigee AI gateway that we deployed.
- 21:10
And, uh, these two proxies, so the MCP one and the, uh, A2A one, um, go, uh, look up into the, uh, actual catalog of, uh, agents and MCPs to retrieve the actual URL of the backend that the agent, uh, wants to call, and then the agents authenticate itself, uh, with another header,
- 21:35
um, onto the, the actual server.
- 21:38
So to bring it back to the business perspective, uh, what we achieved with the AmplifAI platform and the registry, uh, we developed. We have right now a catalog, uh, to, to make the governance happen.
- 21:49
So we see the MCP and A2A server that we deploy across the organization and across multiple teams. Uh, we have a full traceability of the use cases, agents, tools, and also models adopted, um, across, across the use cases.
- 22:05
Then we have the production-ready blueprints for developers to start from something standard across, across teams, but, uh, ready for building and focusing on, um, the business logic in the use cases.
- 22:17
Then we have the CI/CD pipelines standardized for deploying the service to production, but also the metadata into the registry. Of course, it is still in progress, the, the, the work on this platform, so we are keep growing the capabilities.
- 22:32
Uh, so feel free to, to reach out to us and keep in touch if you have any similar, uh, point of view or also, uh, something different that you want to discuss, more than welcome.
- 22:43
Thank you. Feel free to reach out.