- Amplifun addressed the challenges of chaotic, decentralized AI agent development across global teams by launching the "Amplify program" to standardize and govern AI solutions.
- The core of this program is an enterprise-grade registry system coupled with an AI Gateway, designed to provide unified access, enhanced security, and controlled budgeting for AI model usage.
- This comprehensive platform centralizes the management of AI tools and agents, enabling full traceability, reusability, and allowing developers to focus on business logic while ensuring compliance and operational stability.
One Registry to Rule them All - Sonny Merla, Mauro Luchetti, & Mattia Redaelli, Quantyca
- The Amplify program's operational model includes a
Control Towerfor defining global guidelines and strategies, and aCommitteefor country-level strategy execution and use case prioritization. - The program focuses on three pillars:
Governance(regulatory alignment, awareness),Platform(certified infrastructure for developers), andFactory(scalable, reusable solution rollout across countries). - An
AI Gatewayacts as a central access point, providing unified access to AI models, enforcing security via Intra-integration, managing budgeting for use cases, and centralizing auditing and monitoring of all requests. - The system includes three main registries: an
MCP Registry(for tools/integrations), anA2A Registry(for deployed agents), and aUse Case Registry(connecting MCP tools and A2A agents to specific business use cases). - The private
MCP Registryextends the public community standard by enriching entries with enterprise metadata like ownership, environment, authentication models, cost attribution, and use case linkages, enabling critical impact analysis and auditability. - The
A2A Registryis a catalog of deployed agents, where agents automatically publish theirAgent Card(describing identity, capabilities, etc.) via CI/CD for discoverability and interaction. Developer blueprintsare provided as template GitHub repositories for building MCP servers and A2A agents, offering boilerplate code (e.g., FastAPI, Docker), integrated authentication/cost tracking, and observability tooling to accelerate and standardize development.CI/CD pipelinesautomate the deployment process, publishing Docker images to artifact repositories and simultaneously updating the respective registries with the latest metadata (Agent Card or server.json).- A crucial
Object Lineageview provides a visual map of connections between use cases, agents, and AI models, enabling developers and governance teams to perform impact analysis and address issues promptly.
AI agent — A software entity that can perceive its environment, make decisions, and take actions to achieve specific goals, often interacting with other systems or tools.
LLM (Large Language Model) — An advanced artificial intelligence model capable of understanding, generating, and processing human-like text, often forming the core intelligence of AI agents.
MCP (Model-Client Protocol) — A protocol and associated registry standardizing how AI agents discover and interact with external tools, services, or functions.
A2A (Agent-to-Agent protocol) — A protocol and registry designed to facilitate the discovery, connection, and interaction between different AI agents within an ecosystem.
AI Gateway — A central proxy component that provides unified access, security, budgeting, and monitoring for developers and agents to various AI models and tools.
Agent Card — A standardized metadata format used to describe an AI agent's identity, capabilities, endpoints, supported modalities, and authentication requirements for publication in a registry.
Object Lineage — A visual representation or tracking system that maps the dependencies and connections between various AI assets, such as use cases, agents, tools, and models, for traceability and impact analysis.
Blueprint repository — A template repository that provides boilerplate code, standardized infrastructure setup (e.g., Docker, FastAPI), and integrated tooling to accelerate and ensure consistency in developing AI components.
CI/CD pipeline — An automated process for continuous integration and continuous delivery, used to build, test, deploy AI components, and publish their metadata to associated registries.
Observability tool — Software used to collect, analyze, and visualize data (logs, metrics, traces) from applications and systems, providing insights into their internal state and performance.
What happens when you have those in-of-teams across three continents all building a AI agents, each one wearing up their own connections, reinventing their own security model, deploying their own infrastructures. You get cows. Hi, I'm Sonny Merla, Global Data Science in the AI Manager at Amplifun, and I'm here today with Mauro Lucati, AI Center of the Excellence Manager and Mathieu Rida, AI Engineer at Quantica, the team that designed and built the technical solution that we are about to describe. Today, we are going to show you how Amplifun take down this problem by launching their own Amplify program, and specifically how we design an enterprise-grade registry system for MCP and the A to A agents. For HudaNo Amplifun, Amplifun is the world leader in hearing solutions. We operate across 26 countries around the globe. We are more than 20,000 people and we operate over 10,000 stores across the globe. 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. So how Amplifun decided to adopt AI at scale? We launched in January 2025 the Amplify program. It's a global and cross-functional program designed to set the rules for the AI adoption and it is basically composed by an operating model and an execution plan. 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, deciding what are the guidelines for security, legal, and technology, but also what are the strategies, the focus for the strategy and so the use cases to develop as first. Then there is the committee that has the responsibility for running the strategy in the countries but also in the corporate side. So prioritizing also the use cases more granularly, and also to release the value to the organization. Which are the main focus of the Amplify 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. So it's also a matter of make the people aware of the existence of a program. He also the rules of the play and also then make all the people informed of how we deliver and roll out the value. Then there is the platform side. So we have 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 the AI application. Then we have the factory. So this is the most practical part of the story. So we have the development teams that needs to have a focus on rolling out solutions to the market. Also caring about the roll out across countries that it's very important for Amplify. 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 a iaia scale in a pervasive way in the organization. So we foresee for sure maintenance and operations problems, governance and compliance problems, but also enterprises killing. So how the developers needs to develop to make the solutions table over time. Starting from the maintenance and operations side, 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 the usage of this kind of LLM across the use cases that we roll out. So we want to be ready and prepared to act promptly. Every time we see a disruption in the model, we use the use case. On the other side, with the governance and compliance view, we need to be sure to know about where we use the iaia in the organization, what are the main use cases, also for the regulatory point of view, but also for the usage across the organization. So we want to have a catalog, we want to have a way to understand also the assets used by the single use cases, so what they implemented, what they used to also create a sort of lineage of the information. On the other side, then there is a point related to the way we develop AI solution in the organization across multiple teams that operates on different infrastructure. So we want to make the developments at least in terms of governance centralised, then so with clear guidelines, reusable also on different infrastructure and different teams. This is the goal, so 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 care about the security, but also the deployment and maintenance of the use cases. So now I let Mauro to introduce how we address these topics at Amplifrom. Thank you, Sony, and let's try to bring a more technical point of view in this. The first component that we built in order to address those problems are an AI gateway. First of all, it brings us a unified access, so all the developers that want to use a model, they can use this gateway and they can point to the unified endpoint and use all the models that Amplifrom has in its catalog. Then there's security aspect. If you want to use the model, you have to connect to the gateway, you have to authenticate yourself, and we have done this with the intra-integration. Then there's a budgeting aspect because obviously Amplifrom has lots of use cases, and if a use case came to you and asked for budget for using those models, you can set in this AI gateway a budget, a monthly cost, or I mean you can set it monthly, weekly, and so on, but you can set a budget. While the developers are using those budget, it erodes and it can bring to developers, they're remaining part of those budget, so they can control it, and then there's the control aspect. All the requests that are done through LM models or responses, all the analytics that we need to put in place on top of all the requests are done using a central auditing, monitoring, and analysis tools, obviously connected to this AI gateway. Then for the governance part, this is the entry point, this is the top layer, I would say, and then we have three different registries. The first one is the MCP registries, so as you imagine all the tools, all the integration with the Amplifrom systems, all the functionalities that we want to provide to LM models are exposed through this MCP registry, which is the central catalog of all available tools. Then there's the eight-way agent to agent registry, so it brings, it's a full catalog of full implemented, full available agents, and it uses agent card standard, it exposes agent card, and also it can give the developer the ability to connect to already developed agents, and then there's the use case registry, which is the registry that connects all those information together, all those metadata together, and bring out the real governance functionality, the lineage functionality, and again, connects all those aspects together. Let's try to go in more detail about each of those registries. I don't want to obviously tell anybody what MCP is, not a disconference, but we started from the official MCP registry, maintained by the community. This is the public community-wide catalog of all available MCP servers, and we essentially built on top of that, so Amplifrom has built its own private MCP registry as an extension in functionalities, and also in enterprise context that we want to add to each of the registrary servers. It contains two main things, as you can imagine, the custom internal servers that the internal Amplifrom team have built for specific integration, specific tools that Amplifrom want to provide, and also a created set of public servers that have been approved, that have been certified for Amplifrom use cases. Both these servers that we want that we registrate in this catalog are enriched with some additional enterprise metadata. Let's see what are those metadata. First of all, the ownership. Each server has an owner, which team, which use case, which project is in a way owner is responsible for that specific server. What are the environment in which the server is running? So it is running in dev, task, prod, and so on. What are the authentication models? So how I can affect, how I can, as a developer, use that server. What are the mechanisms that I need to put in place? The cost of tributions, so this is linked to the AI gateway functionality, the budgeting aspect that we have described before, and this is done in order to see what server is spending what essentially, and then the use case linkage. So what are the use cases that are actually using that specific server? And these are not simply metadata that are nice to have. This is something that really bring out the impact analysis functionality. This is where effectively we enable the governance and the auditability, and we have the complete trail of what AI tooling exists, and how they are being used by the AMP developers. And then we have second registry, which is the gateway registry. This is fully based on the agent card that describes the agent's identity. It's in point the agent capabilities, the supported modalities, authentication requirements, and so on. We have built some blueprints, and then we talk about those blueprints, but essentially, when an agent is deployed, it automatically publishes its agent card to the registry via the RCI-CD integration. So in this way, any other agent, any other developer can discover this new agent, and obviously can interact with it. So in a way, we are trying to make all those agent development stuff documenting. Now we will see how use case registry connects those two other registry together. How do we can use the MCP registry and the gateway registry from a business point of view? We want to have a use case for registry. So to map the agents and the tools in specific use case adopted across the organization. And this is the reason why we designed this specific building block that aims to contain the information of what are the assets used by the single use case, what they implement, what are the modalities they used also for the maintenance topic that we mentioned before, and also understand how and where we develop and deploy these kind of use cases, for example, which is the system that serves the use case, the specific use case, and what are all the other impacted by these use cases. So for example, if we have connection among multiple use cases, we want to see that clearly in an interface that can be a catalog for everyone. Let's see now how it works in practice. So let's go and walk through of the platform that's been developed and that implement all these registries for the organization. Okay, so we wanted also to give you a brief overview of our platform. Here you can see that is the homepage. You can go into the catalog. So what we described in detail before, so I'm CP, HWA, and use cases, we also have the IIG gateway part where we define what elements are available in the enterprise right now. I'm going back to the dashboard. If we move on to the catalog, this is the platform that we are going to deploy in production soon. Here we have the demo data. So we have six entities defined. Until this point, we have use cases, MCP, and HWA agents. Going into the use cases part, if we open a sample use case, for instance, we can define its status, its version, its description, assets used. So for instance, an agent and an MCP server, what AI models it's using, and the lifecycle history of the use case. If we go into the create use case page, you can see that we can define a name, a description, the status of the use case, the ownership, and also the assets linked to that. If we move to the AI tools section, so MCP servers, you can see that we have two sample MCP servers. So the actual server JSON is described here. We can also see into the HWA agents, the same thing for agent cards. So for instance, here we can define the, we can have the long chain test agent, the capabilities and description from the agent card. We also define the inspector page where you can select an MCP server and you can launch the inspector in another tab. So you can also connect and check what that MCP is providing you. We also have the same inspector that is just checking for compatibility with the HWA agent card. And you can do the same here. We also have widgets so you can in order to make the life of the developer easier, define the server.json for MCP and the agent card for HWA with a form, and then preview it here instead of starting from the actual JSON on the repo if it's the first, let's say server for you. We can also check the lineage because for instance, you can go into the use case, open, I use case that you want to check, open the object lineage. In this lineage view, you can see that for instance, the use case here that is ticket optimization with AI is connected to an agent, is connected to another agent here and also as AI models connected to it. So we can have the full lineage of the use case and also be able, as MAUR said before, to be sure and also make modifications in case some parts of the lineage are affected by an outage or a problem and go back to the use case affected. So moving into the enterprise development cycle, so we talked a lot about metadata and registries, but how do actually amplify developers develop MCP servers and agent to agent servers to deploy them in production. We deployed and developed two repositories, one for MCP and one for agent to agent protocol. These two repositories are template repositories on GitHub, so then developers and teams can start from them and work their way up to production environment. The idea is that these two book prints actually have boilerplate provided and also infrastructure and tooling already present. So for instance Docker files, package manager, both are fast API servers, so they are exposed in the same way and also the authentication and cost tracking is handled inside the double print. We also have an integration to an infuse, which is an observability tool that we deployed at the platform level. So the development teams can also trace their agents, run evaluations, and check how the agent is performing. Also the HWA server blueprint is agnostic, so it's not based on a particular framework, so chain or agno or any other framework, but actually it's composed of interfaces and ports so that every team can implement their own solution in their framework of choice. The important thing is that they provide the same interface that we saved in the blueprint so that the development is easy on the developers and they can focus on the actual value of the agent. Mauro talked about the CICD that is in place in the HWA blueprint and also the MCP blueprint. The idea is that once you are ready with your development, you can tag a certain branch and GitHub action starts and not only publishes the Docker image on our artifact repository, but also publishes the metadata of the agent, so the agent card for agent to agent protocol and the server.json for MCP. On to the, let's say proxy of the catalog of the registers. In this image, we can also see that in case an AI agent needs to call either an MCP or an HWA proxy, the idea is that they can go through the API gateway that we deployed and these two proxies, so the MCP1 and the HWA1 go up into the actual catalog of agents and MCPs to retrieve the actual URL of the backend that the agent wants to call and then the agents authenticate itself with another header onto the actual server. So to bring it back to the business perspective, what we achieved with the amplifier platform and the registry we developed. We have right now a catalog to make the governance happen, so we see the MCP and HWA server that we deploy across the organization and across multiple teams. We have a full traceability of the use cases, agents, tools and also models adopted across the use cases. Then we have the production ready-blue prints for developers to start from something standard across teams, but ready for building and focusing on the business logic in the use cases. Then we have the CICD pipelines and the ties for deploying the service to production, but also the metadata into the registry. Of course, it is still in progress that the work on this platform, so we are keep growing the capabilities. So feel free to reach out to us and keep in touch if you have any similar point of view or also something different that you want to discuss more than welcome. Thank you, feel free to reach out.
TL;DR
- Amplifun addressed the challenges of chaotic, decentralized AI agent development across global teams by launching the "Amplify program" to standardize and govern AI solutions.
- The core of this program is an enterprise-grade registry system coupled with an AI Gateway, designed to provide unified access, enhanced security, and controlled budgeting for AI model usage.
- This comprehensive platform centralizes the management of AI tools and agents, enabling full traceability, reusability, and allowing developers to focus on business logic while ensuring compliance and operational stability.
Takeaways
- The Amplify program's operational model includes a
Control Towerfor defining global guidelines and strategies, and aCommitteefor country-level strategy execution and use case prioritization. - The program focuses on three pillars:
Governance(regulatory alignment, awareness),Platform(certified infrastructure for developers), andFactory(scalable, reusable solution rollout across countries). - An
AI Gatewayacts as a central access point, providing unified access to AI models, enforcing security via Intra-integration, managing budgeting for use cases, and centralizing auditing and monitoring of all requests. - The system includes three main registries: an
MCP Registry(for tools/integrations), anA2A Registry(for deployed agents), and aUse Case Registry(connecting MCP tools and A2A agents to specific business use cases). - The private
MCP Registryextends the public community standard by enriching entries with enterprise metadata like ownership, environment, authentication models, cost attribution, and use case linkages, enabling critical impact analysis and auditability. - The
A2A Registryis a catalog of deployed agents, where agents automatically publish theirAgent Card(describing identity, capabilities, etc.) via CI/CD for discoverability and interaction. Developer blueprintsare provided as template GitHub repositories for building MCP servers and A2A agents, offering boilerplate code (e.g., FastAPI, Docker), integrated authentication/cost tracking, and observability tooling to accelerate and standardize development.CI/CD pipelinesautomate the deployment process, publishing Docker images to artifact repositories and simultaneously updating the respective registries with the latest metadata (Agent Card or server.json).- A crucial
Object Lineageview provides a visual map of connections between use cases, agents, and AI models, enabling developers and governance teams to perform impact analysis and address issues promptly.
Vocabulary
AI agent — A software entity that can perceive its environment, make decisions, and take actions to achieve specific goals, often interacting with other systems or tools.
LLM (Large Language Model) — An advanced artificial intelligence model capable of understanding, generating, and processing human-like text, often forming the core intelligence of AI agents.
MCP (Model-Client Protocol) — A protocol and associated registry standardizing how AI agents discover and interact with external tools, services, or functions.
A2A (Agent-to-Agent protocol) — A protocol and registry designed to facilitate the discovery, connection, and interaction between different AI agents within an ecosystem.
AI Gateway — A central proxy component that provides unified access, security, budgeting, and monitoring for developers and agents to various AI models and tools.
Agent Card — A standardized metadata format used to describe an AI agent's identity, capabilities, endpoints, supported modalities, and authentication requirements for publication in a registry.
Object Lineage — A visual representation or tracking system that maps the dependencies and connections between various AI assets, such as use cases, agents, tools, and models, for traceability and impact analysis.
Blueprint repository — A template repository that provides boilerplate code, standardized infrastructure setup (e.g., Docker, FastAPI), and integrated tooling to accelerate and ensure consistency in developing AI components.
CI/CD pipeline — An automated process for continuous integration and continuous delivery, used to build, test, deploy AI components, and publish their metadata to associated registries.
Observability tool — Software used to collect, analyze, and visualize data (logs, metrics, traces) from applications and systems, providing insights into their internal state and performance.
Transcript
What happens when you have those in-of-teams across three continents all building a AI agents, each one wearing up their own connections, reinventing their own security model, deploying their own infrastructures. You get cows. Hi, I'm Sonny Merla, Global Data Science in the AI Manager at Amplifun, and I'm here today with Mauro Lucati, AI Center of the Excellence Manager and Mathieu Rida, AI Engineer at Quantica, the team that designed and built the technical solution that we are about to describe. Today, we are going to show you how Amplifun take down this problem by launching their own Amplify program, and specifically how we design an enterprise-grade registry system for MCP and the A to A agents. For HudaNo Amplifun, Amplifun is the world leader in hearing solutions. We operate across 26 countries around the globe. We are more than 20,000 people and we operate over 10,000 stores across the globe. 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. So how Amplifun decided to adopt AI at scale? We launched in January 2025 the Amplify program. It's a global and cross-functional program designed to set the rules for the AI adoption and it is basically composed by an operating model and an execution plan. 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, deciding what are the guidelines for security, legal, and technology, but also what are the strategies, the focus for the strategy and so the use cases to develop as first. Then there is the committee that has the responsibility for running the strategy in the countries but also in the corporate side. So prioritizing also the use cases more granularly, and also to release the value to the organization. Which are the main focus of the Amplify 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. So it's also a matter of make the people aware of the existence of a program. He also the rules of the play and also then make all the people informed of how we deliver and roll out the value. Then there is the platform side. So we have 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 the AI application. Then we have the factory. So this is the most practical part of the story. So we have the development teams that needs to have a focus on rolling out solutions to the market. Also caring about the roll out across countries that it's very important for Amplify. 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 a iaia scale in a pervasive way in the organization. So we foresee for sure maintenance and operations problems, governance and compliance problems, but also enterprises killing. So how the developers needs to develop to make the solutions table over time. Starting from the maintenance and operations side, 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 the usage of this kind of LLM across the use cases that we roll out. So we want to be ready and prepared to act promptly. Every time we see a disruption in the model, we use the use case. On the other side, with the governance and compliance view, we need to be sure to know about where we use the iaia in the organization, what are the main use cases, also for the regulatory point of view, but also for the usage across the organization. So we want to have a catalog, we want to have a way to understand also the assets used by the single use cases, so what they implemented, what they used to also create a sort of lineage of the information. On the other side, then there is a point related to the way we develop AI solution in the organization across multiple teams that operates on different infrastructure. So we want to make the developments at least in terms of governance centralised, then so with clear guidelines, reusable also on different infrastructure and different teams. This is the goal, so 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 care about the security, but also the deployment and maintenance of the use cases. So now I let Mauro to introduce how we address these topics at Amplifrom. Thank you, Sony, and let's try to bring a more technical point of view in this. The first component that we built in order to address those problems are an AI gateway. First of all, it brings us a unified access, so all the developers that want to use a model, they can use this gateway and they can point to the unified endpoint and use all the models that Amplifrom has in its catalog. Then there's security aspect. If you want to use the model, you have to connect to the gateway, you have to authenticate yourself, and we have done this with the intra-integration. Then there's a budgeting aspect because obviously Amplifrom has lots of use cases, and if a use case came to you and asked for budget for using those models, you can set in this AI gateway a budget, a monthly cost, or I mean you can set it monthly, weekly, and so on, but you can set a budget. While the developers are using those budget, it erodes and it can bring to developers, they're remaining part of those budget, so they can control it, and then there's the control aspect. All the requests that are done through LM models or responses, all the analytics that we need to put in place on top of all the requests are done using a central auditing, monitoring, and analysis tools, obviously connected to this AI gateway. Then for the governance part, this is the entry point, this is the top layer, I would say, and then we have three different registries. The first one is the MCP registries, so as you imagine all the tools, all the integration with the Amplifrom systems, all the functionalities that we want to provide to LM models are exposed through this MCP registry, which is the central catalog of all available tools. Then there's the eight-way agent to agent registry, so it brings, it's a full catalog of full implemented, full available agents, and it uses agent card standard, it exposes agent card, and also it can give the developer the ability to connect to already developed agents, and then there's the use case registry, which is the registry that connects all those information together, all those metadata together, and bring out the real governance functionality, the lineage functionality, and again, connects all those aspects together. Let's try to go in more detail about each of those registries. I don't want to obviously tell anybody what MCP is, not a disconference, but we started from the official MCP registry, maintained by the community. This is the public community-wide catalog of all available MCP servers, and we essentially built on top of that, so Amplifrom has built its own private MCP registry as an extension in functionalities, and also in enterprise context that we want to add to each of the registrary servers. It contains two main things, as you can imagine, the custom internal servers that the internal Amplifrom team have built for specific integration, specific tools that Amplifrom want to provide, and also a created set of public servers that have been approved, that have been certified for Amplifrom use cases. Both these servers that we want that we registrate in this catalog are enriched with some additional enterprise metadata. Let's see what are those metadata. First of all, the ownership. Each server has an owner, which team, which use case, which project is in a way owner is responsible for that specific server. What are the environment in which the server is running? So it is running in dev, task, prod, and so on. What are the authentication models? So how I can affect, how I can, as a developer, use that server. What are the mechanisms that I need to put in place? The cost of tributions, so this is linked to the AI gateway functionality, the budgeting aspect that we have described before, and this is done in order to see what server is spending what essentially, and then the use case linkage. So what are the use cases that are actually using that specific server? And these are not simply metadata that are nice to have. This is something that really bring out the impact analysis functionality. This is where effectively we enable the governance and the auditability, and we have the complete trail of what AI tooling exists, and how they are being used by the AMP developers. And then we have second registry, which is the gateway registry. This is fully based on the agent card that describes the agent's identity. It's in point the agent capabilities, the supported modalities, authentication requirements, and so on. We have built some blueprints, and then we talk about those blueprints, but essentially, when an agent is deployed, it automatically publishes its agent card to the registry via the RCI-CD integration. So in this way, any other agent, any other developer can discover this new agent, and obviously can interact with it. So in a way, we are trying to make all those agent development stuff documenting. Now we will see how use case registry connects those two other registry together. How do we can use the MCP registry and the gateway registry from a business point of view? We want to have a use case for registry. So to map the agents and the tools in specific use case adopted across the organization. And this is the reason why we designed this specific building block that aims to contain the information of what are the assets used by the single use case, what they implement, what are the modalities they used also for the maintenance topic that we mentioned before, and also understand how and where we develop and deploy these kind of use cases, for example, which is the system that serves the use case, the specific use case, and what are all the other impacted by these use cases. So for example, if we have connection among multiple use cases, we want to see that clearly in an interface that can be a catalog for everyone. Let's see now how it works in practice. So let's go and walk through of the platform that's been developed and that implement all these registries for the organization. Okay, so we wanted also to give you a brief overview of our platform. Here you can see that is the homepage. You can go into the catalog. So what we described in detail before, so I'm CP, HWA, and use cases, we also have the IIG gateway part where we define what elements are available in the enterprise right now. I'm going back to the dashboard. If we move on to the catalog, this is the platform that we are going to deploy in production soon. Here we have the demo data. So we have six entities defined. Until this point, we have use cases, MCP, and HWA agents. Going into the use cases part, if we open a sample use case, for instance, we can define its status, its version, its description, assets used. So for instance, an agent and an MCP server, what AI models it's using, and the lifecycle history of the use case. If we go into the create use case page, you can see that we can define a name, a description, the status of the use case, the ownership, and also the assets linked to that. If we move to the AI tools section, so MCP servers, you can see that we have two sample MCP servers. So the actual server JSON is described here. We can also see into the HWA agents, the same thing for agent cards. So for instance, here we can define the, we can have the long chain test agent, the capabilities and description from the agent card. We also define the inspector page where you can select an MCP server and you can launch the inspector in another tab. So you can also connect and check what that MCP is providing you. We also have the same inspector that is just checking for compatibility with the HWA agent card. And you can do the same here. We also have widgets so you can in order to make the life of the developer easier, define the server.json for MCP and the agent card for HWA with a form, and then preview it here instead of starting from the actual JSON on the repo if it's the first, let's say server for you. We can also check the lineage because for instance, you can go into the use case, open, I use case that you want to check, open the object lineage. In this lineage view, you can see that for instance, the use case here that is ticket optimization with AI is connected to an agent, is connected to another agent here and also as AI models connected to it. So we can have the full lineage of the use case and also be able, as MAUR said before, to be sure and also make modifications in case some parts of the lineage are affected by an outage or a problem and go back to the use case affected. So moving into the enterprise development cycle, so we talked a lot about metadata and registries, but how do actually amplify developers develop MCP servers and agent to agent servers to deploy them in production. We deployed and developed two repositories, one for MCP and one for agent to agent protocol. These two repositories are template repositories on GitHub, so then developers and teams can start from them and work their way up to production environment. The idea is that these two book prints actually have boilerplate provided and also infrastructure and tooling already present. So for instance Docker files, package manager, both are fast API servers, so they are exposed in the same way and also the authentication and cost tracking is handled inside the double print. We also have an integration to an infuse, which is an observability tool that we deployed at the platform level. So the development teams can also trace their agents, run evaluations, and check how the agent is performing. Also the HWA server blueprint is agnostic, so it's not based on a particular framework, so chain or agno or any other framework, but actually it's composed of interfaces and ports so that every team can implement their own solution in their framework of choice. The important thing is that they provide the same interface that we saved in the blueprint so that the development is easy on the developers and they can focus on the actual value of the agent. Mauro talked about the CICD that is in place in the HWA blueprint and also the MCP blueprint. The idea is that once you are ready with your development, you can tag a certain branch and GitHub action starts and not only publishes the Docker image on our artifact repository, but also publishes the metadata of the agent, so the agent card for agent to agent protocol and the server.json for MCP. On to the, let's say proxy of the catalog of the registers. In this image, we can also see that in case an AI agent needs to call either an MCP or an HWA proxy, the idea is that they can go through the API gateway that we deployed and these two proxies, so the MCP1 and the HWA1 go up into the actual catalog of agents and MCPs to retrieve the actual URL of the backend that the agent wants to call and then the agents authenticate itself with another header onto the actual server. So to bring it back to the business perspective, what we achieved with the amplifier platform and the registry we developed. We have right now a catalog to make the governance happen, so we see the MCP and HWA server that we deploy across the organization and across multiple teams. We have a full traceability of the use cases, agents, tools and also models adopted across the use cases. Then we have the production ready-blue prints for developers to start from something standard across teams, but ready for building and focusing on the business logic in the use cases. Then we have the CICD pipelines and the ties for deploying the service to production, but also the metadata into the registry. Of course, it is still in progress that the work on this platform, so we are keep growing the capabilities. So feel free to reach out to us and keep in touch if you have any similar point of view or also something different that you want to discuss more than welcome. Thank you, feel free to reach out.