🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Modernize containers for AI agents using AgentCore Gateway (CNS422)
In this video, Roland Barcia and Carlos Santana demonstrate building an AI agent for home appliance support using AWS AgentCore and EKS. They show how to expose existing containerized microservices (appointments, claims, customer services) as MCP tools through AgentCore Gateway without rewriting code. Carlos, as platform engineer, uses EKS Auto mode with Karpenter, deploys microservices with OpenAPI specifications, and configures MCP Gateway with Cognito authentication and AgentCore Identity for secure access. Roland, as agent developer, creates a Strands-based agent in AgentCore Runtime that connects to the gateway. The live demo shows the agent successfully handling a refrigerator emergency claim, creating appointments, and reasoning through multiple API calls. They announce new EKS capabilities including managed Argo CD, Crossplane, ACK controllers, and pre-provisioned control planes.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction: Building an Agent to Expose Containerized Business Logic
Welcome everyone. I'm Roland Barcia, worldwide director for our specialist organization. I lead all our specialist technologies, and I'm joined here by Carlos Santana, who will introduce himself. Carlos is a platform engineer and Kubernetes expert who will be helping us demonstrate some exciting capabilities today.
We want to build an agent because people don't like talking to support cases—they take a while. Instead of calling someone, I would love to build an agent to give it some prompts around situations like when people are dealing with home appliance issues. We're going to build an agent, and I know we have a lot of business logic, but it's kind of locked up inside our existing containerized application. What are we going to do? Carlos, who is a platform engineer and Kubernetes expert, and I are going to show you how we can expose this. We're going to actually show it live in a minute, but basically I want to be able to ask it some questions around how it can help me. You'll see a little preview with some of the tools and existing systems that are there. That's what we're going to build.
We have things like claims, appointment services, and account information—all deterministic logic I built years ago. Carlos and I built all these things together over years within a modern microservices-based system using Kubernetes. We have a lot of opportunity and a challenge around taking your existing applications, your existing legacy applications, and exposing them through MCP or other mechanisms. There are different options, and you're living now with nondeterministic logic and deterministic logic. You have years and years of applications that were built to be reused, and now I want to make use of them in an agentic world.
How are we going to do that? Tomorrow we have an architecture session at six o'clock at the Wynn where we go more into the architecture issues between different options for creating MCP servers and exposing existing applications. But here we're just going to get into a very specific way. Exposing your existing assets is a great way to make your existing agents and automate things as well with the architecture we're going to get into: Agent Core.
Agent Core Architecture and EKS Capabilities Overview
I'm an agent developer. I write Python. I like to write agents. I don't know Kubernetes. I don't know the existing microservices architecture, which could have been written in Java or something else. But we use Agent Core. Agent Core has a lot of components, and there are a lot of sessions this week. I primarily run my agents inside of Agent Core runtime. I use things like Agent Core identity to make sure I have access to things I want to use. I want to use Agent Core Gateway as well so I can access all the nice tools that I might have in my agentic systems. I want to use memory to keep track of different conversations. We're going to use these components, and there are not listed or new announcements like evaluations and the policies that exist inside of Gateway. We won't be showing those today, but we will get into some of the code.
Of course, EKS—I love EKS. With EKS, Kubernetes is still super important. We have one of the best Kubernetes platforms out there with the most instance types and a lot of new exciting features. Last year we had auto mode. This year we have some announcements.
We have just launched EKS capabilities, which is a fully managed Argo CD, Crossplane, and AWS Controllers for Kubernetes (ACK), with those controllers running on Amazon EKS. You just see the Custom Resource Definitions (CRDs). This allows platform engineering teams to not worry about scaling, maintaining, or patching these controllers. Some of them, like Argo CD, are part of the CNCF. We take care of that compute, and you don't have to pay for that compute. You just concentrate on deploying the applications with GitOps, and that could be ACK or Crossplane to deploy infrastructure. It could be an Amazon VPC, it could be an S3 bucket, and that's one of the major announcements we did recently.
Another capability is provisioning control planes. We have pre-provisioned control planes to allow at-scale, on-demand large clusters with many nodes. Another one is around Amazon EKS MCP server hosted, so you can connect things like Qiro or our agents in Strands right to connect and do DevOps with agentic DevOps. So what's the architecture we're going to build? We're going to have a simple chat UI because all AI demos have a chat interface where you prompt against it. We're going to have existing microservices APIs with Amazon EKS. We're going to expose that through the gateway and use AgentCore Identity to make sure we have secure access to these services.
Then I'm going to deploy my AgentCore runtime application. I use Strands as the SDK to deploy that. We're also going to expose the agent itself with A2A, which is something you can do inside of AgentCore runtime. Today it's just being consumed by the chat UI, but you can envision in the future this orchestration living next to other orchestrations, and so we want to be prepared for that as well. Of course, we're going to use Bedrock to do inference with our models as well. So this is the architecture, and we're going to show some of the code with that.
The Challenge: Exposing Hundreds of Microservices Through MCP Gateway
Carlos, you have a bunch of microservices that I want to use. You told me that I don't have to learn Kubernetes because you're going to just give me some nice tools through MCP with the code and expose those existing systems. You're going to show the audience how we did that with code. The scenario is that our management told us that we have to make everything MCP available for our microservices, and some of these systems have hundreds of microservices. If my team is going to spend time writing MCP servers and wrappers and another wrapper, it will take us a full year. So why not take advantage of the MCP gateway or AgentCore? That's what we're going to show with some of those microservices being used from the EKS server on the EKS cluster.
Today, I'm going to play the role of the agent developer. I just want to get access to my tools and use them. I want to write my agents, write prompts, and do prompt engineering. Carlos, you're the platform engineer, and you're going to go ahead and take the existing systems and make them available to me as tools. We're going to do that today, so you're going to start with the infrastructure. We'll show you the EKS cluster. In this case, we're using EKS Auto, and some of the practices that a lot of customers use to deploy microservices. They use an ingress, they use a deployment, service annotations, very easy to deploy these microservices and then expose them through a load balancer and then use the gateway to access those microservices, but having a contract. That contract comes from the OpenAPI specification.
We'll go deeper into that. But then for the AgentCore runtime, we need to make sure that our Strands agent is the only one talking to my services. I don't want other agents around there just talking to the MCP gateway. There's another service feature for AgentCore called Identity that will handle that token exchange with the provider to be able to connect to the MCP server that actually gets created on the fly with one URL. One of the cool things about AgentCore Gateway is it can talk to existing MCP servers, and you can have semantic search so you can search across hundreds and hundreds of tools and make sure that you're getting the tool you need.
You can also expose existing assets like your Lambda functions, and if you describe things with Swagger or OpenAPI spec, it automatically converts them to MCP servers. It's not the only way. Sometimes for use cases you want to code existing MCP servers, but in this case I need this agent code done. So as an agent developer, I just want to use my tools. I want to use Bedrock's LLMs. I want to write my agent runtime. I want to access them, and I want to use Identity to make sure I can access these tools securely. We're going to combine these things and show some of the code and some of the application stuff that we've written, and then we'll actually show this live. Hopefully it'll work with the demo, so we're going to switch over now to the demo. Are you ready? Yeah, let's go. A little bit of code. Who wants to see some code?
Platform Engineer Demo: Exploring the EKS Cluster and Microservices Infrastructure
Let me show you some code. That's why you're here, right? This is a code talk. Let me show you what we have. I'm going to go to the console and check my home here. Let me verify if my EKS cluster is ready. As you can see here, I have an EKS cluster and it's configured. Let me close a few of these windows. We're using version 1.33, and this is something that allows us to show what happens if I want to upgrade. I'll do upgrade insights. This is the new capability that we announced, and we're getting our pop-up, so this is good that it's working and you can check it out from there.
Then we have EKS auto mode, right? EKS auto mode is enabled as you can see here, and we'll have our compute that is here. These nodes are coming from node pools. We are using auto mode. EKS uses something called Karpenter. Who uses Karpenter in their EKS clusters? Karpenter is the auto scaling that automatically provisions your nodes based on pods that are pending. That way you don't have to manage it manually. It's a much easier way of managing those nodes.
What else we have here? This is a vanilla one with add-ons. I have one called external DNS. This allows us to basically add a domain name to my ingress when I create an ingress or a service. External DNS is part of the CNCF. One thing is we recently added EKS community add-ons, so things like external DNS, cert manager, and Prometheus metrics. These are add-ons that get deployed through the EKS add-ons API. These are things that you don't have to do through Helm charts or container images that you have to scan and check for compatibility issues between the version of Kubernetes and these add-ons.
A lot of our customers are now switching from self-managed Helm charts deploying these community add-ons to deploying them through the EKS add-ons API. You can do that with ACK, CloudFormation, Terraform, or anything that handles the API or the CLI that handles the API. So that's our cluster here. I can show you the capabilities that we support. Here are the capabilities that you can add, things like Argo CD, ACK, and Curl. This is giving you an overview of all we have, and this is me as the platform engineer having to manage a fleet of clusters. Usually in a business we have multiple EKS clusters in pre-prod and prod, and having this here helps us a lot.
Let me show you one more thing. I was looking at upgrade insights. As you saw, it was version 1.33, but there are upgrade insights that we give you showing what things you're ready to upgrade or if there's something warning or something that will block you from upgrading. So that's my cluster. Let's go to the console here to see what microservices I'm deploying so I can show you an example of those microservices on their infrastructure. You're going to have access to this code. Basically it's going to be divided into two sections. One section is agents and another section is called infrastructure. Roland has been working in the agent folder, and I've been working on the infrastructure folder.
In the infrastructure folder we have our manifests. For example, there are two main ways or the two most popular ways of deploying Kubernetes resources: Kustomize and Helm. In this case, I'm using Kustomize. I have here like Roland pointed out in the architecture, right? Appointments, customer, and technician. So it has their typical deployment with the container image that has the REST API for getting appointments and creating appointments. It has a service and then it has an ingress, and this is what I wanted to show. This is how you expose the load balancer. When you create this, it will actually create a load balancer, and this ingress points to the service, right? The service that I just showed here. Then it will add an annotation for the hostname.
Let's look at how that looks like in kubectl. Who calls it kubectl? I always call it QC. We call it kubectl. And who just uses Q? If I do get pods, let's see the nodes, right? How many nodes do I have here? Let me check on time. How are we doing? We have plenty of time.
So these are the notes. These notes are provisioned by the note group. Can I make this a bit bigger? Okay, so for those of you who raised your hand, K is just an alias to kubectl. It's just so many years of using it that my brain is used to K. So we have node pools, and these are the Karpenter pools. Karpenter is not running as a pod in here because it's in auto mode. So Karpenter is managed by the EKS service, so you don't have to install it. No Helm charts. It just runs in auto mode. These instances are managed, meaning we will handle the rotation of those AMIs. We're going to handle the CVE patching. Every node can run no more than 21 days, with a default of 14 days, but we're going to take care of rotating those. These are running Bottlerocket, which is our container-optimized operating system that we recommend for running EKS workloads because it has a low footprint of files and processes, which makes it more secure.
These are the node pools, and when you have node pools and you have pods in pending, it will create node claims. We do node claims, and then these are like the instances. This is like Karpenter going directly to the EC2 fleet API and getting the node as fast as possible. Then the node gets created, and then the pod gets scheduled. The Kubernetes scheduler puts it here. Let's take a look at what we have in deployments. Well, let's show all the pods so you can see. Actually, there's no core DNS as you can see here. If I do get pods, there's no core DNS. You would have a standard Kubernetes cluster not using it in auto mode. Usually you see things like a CNI daemon set. You see things like core DNS, and these are things that are now in the node. These are pods that you don't have to worry about.
In here we see the external DNS that I showed, and then metric server. If you have an HPA, like we do, and you want to scale this based on metrics, the number of pods, you would use an HPA, a horizontal pod autoscaler. You configure this HPA saying based on this CPU or memory or a custom metric, I want to have this number of pods, and it will scale up, scale out, or scale in the number of pods. That's why metric server is there. Guestbook is something I was testing. The EKS capabilities to deploy from Argo CD that I have in a hub cluster in a different region deploying to this cluster. It's there. I was testing it. But the thing I want to show is these three microservices that are in the deployment. So if I do get deployments dash N development, we have three deployments. This is typically what our business does. When the management team came to us saying, "Hey, can we get MCP servers?" we were saying, "Well, do we wrap this same code again and create a Docker file and create MCP servers? Then I have six spots." We discovered through our accounting, for example, our time, that AgentCore has this capability of MCP Gateway, so we don't have to code the MCP servers. We can just take these APIs, have their documentation, their OpenAPI schema, or Swagger, or back in the days we used to call it Swagger. Now we have OpenAPI spec V3. With that information, we can tell the MCP Gateway how to access and what services are available so they can convert it into MCP tools.
If I want to do this in this example, like I showed you, I have the ingress here. I can do K get ingress, and then for the ingress, it usually prints the hostname and the external DNS name that I configured in Route 53. Usually this is the easiest way to configure hostnames for when you create an ingress. You put in an annotation that you want to put the domain name for this application. In this case, I have appointments dash development dot home insurance demo dot cloud native start dot com. That's just a domain name that I have available for demos. Then we have customer, and then we have technicians. So let's pick one of the microservices and let's take a look at what is behind it.
So if I open here and say docs. Who can tell me what is this? Who recognizes this UI? Who has used it? So for people recording, there are a lot of people raising their hand. This is a kind of Swagger UI, which we now call OpenAPI UI. These are my microservices, and this becomes appointments. So in the home insurance company, we have appointments, claims, and customers. A customer creates a claim based on their policy, and then if they have a problem, like if the fridge is still running water here on stage, we need someone to come in and fix it.
We can test it here to see if it works. I can just list what appointments I have, click here, and then execute it. Then I get all my appointments. This is the typical way that our current system, before Agentic, our customer service and everyone in the business used to access these APIs through another API, another UI, standard forms. These are not agentic. This is the standard way that we have established, and we have gone through change management every time we need to do an update. That is our process, and most companies have a process like that for change management of anything that you deploy.
If we want to see the JSON, we can click here and get our JSON. This is a way of describing the REST API. As you saw, all those endpoints get, I am doing appointments. So like get an appointment, create an appointment, delete an appointment, list appointments. This is the standard way of creating this documentation, and a lot of frameworks, right? Spring Boot, Express JS, we are using FastAPI, have a way to generate this Swagger or OpenAPI specification. But you can also use things like Kiro, which is our agentic IDE or CLI, to inspect the source code and say generate me the OpenAPI specification for this file, or get me started and start doing that.
But that is a requirement that we have, and I am going to show in a minute that there is something for the MCP gateway that is not in here. So if I search, let me see if it is here. If I search for server in the specification, there is a field called server which has a URL. So the MCP, we are going to give this JSON file to the MCP gateway to access this API, but it needs the address. So one way, the way to express the location of this REST API, if it is going to be development versus production, maybe I have two domain names or a path-based routing, it would know how to call it. So we are going to show the code how we inject that. We are good so far.
Setting Up MCP Gateway with Python: Creating Identity Provider and Targets
So if you have microservices up and running, you need a Swagger file, a JSON file, and we need to inject the URL. So I am going to do it with code, and then let us see how we can expose this on the MCP gateway. So let us go to Kiro. I am using the Kiro IDE. Actually, almost all this code was working with me in Kiro back and forth, creating this code, so he is aware of what things are happening here. Let me go and show you. This code, when you get it, will have a lot of test files, because I use Kiro and as a spec-driven development, Kiro created all these test files to make sure that the requirement that I put in at the beginning was met as we developed this demo code.
In this case, I am going to go to the MCP gateway Python folder source, and I have set up .py. Then I have a pip project. So we are using Python to create the gateway and this infrastructure, but you can use whatever other infrastructure as code tool that you have, like things like CDK. In this case, we were talking about CloudFormation, Terraform, the CLI, whatever you have. In this case, I am just going to show Boto3, right, the Python SDK. So let me show, go here and open. I have the terminal so big that I am going to make it a little bit smaller. Pip project is basically the entry point to this thing. So I have an entry point called MCP gateway setup that is going to use the source setup, setup Python code, and the main function.
Let me navigate to this directory. If I run the ls command on the source directory, I can see all the things I was testing, including the different pieces to create the MCP gateway. The setup.py file is setting up the MCP gateway.
Looking at the code, I have the main function here. I have some helper functions just to speed up things because we don't have enough time to cover everything. Let me find the main function. This is the main function. If I run this script, it asks you to pass two parameters: the REST API domain name.
When you run this, you can pass a domain name. In this case, it was cloudnativestart.com. You also pass the environment, specifying whether you're going to deploy to the development namespace or the production namespace. Many customers have these environments in separate IaaS clusters. They have a pre-production cluster and a production cluster. For demo purposes, I'm using namespaces. You pass those two things, and then we start using the Boto3 library.
The first thing we do is create an MCP gateway. To create an MCP gateway, we need an IAM role for the MCP gateway service. The instance of the MCP gateway needs identity, like an IAM role, and the documentation shows that. I have a function that creates an IAM role with the right IAM policy, and I get that IAM role back.
The next thing I do is get a Cognito setup. This is how I'm going to protect the MCP gateway. When Roland creates the agent and accesses the MCP gateway, there will be inbound traffic from the agent core to the MCP gateway. In this case, I'm using Cognito to protect it. This function creates it and checks if I already have it created. For demo purposes, if it's not created, it will create it. It needs things like the Cognito pool resource server ID and resource server name. This basically handles the scope. If you want read versus write access, the scopes are defined down here.
I create that and get back the information I need to return: the user pool ID, the client ID, the client secret, the Cognito discovery URL, the token URL where you get a token from the Cognito service, and the resource server ID where the scopes need to match when you ask for a token. Let me go back to the main function. Down here is where the main function continues. After Cognito is created, I'm going to create the gateway.
There's an API, and the things you need to pass to this gateway are three things. Keep in mind that you create a gateway first and then you add your targets. You can create a gateway with the protection that you want, and then you start adding targets. Targets could be different microservices, one Swagger file at a time. In this case, I have three Swagger files or three microservice endpoints. I'm going to be adding three targets into it.
The information includes the Cognito details and the IAM role that the gateway instance is going to use to run. The next thing is the identity provider name. This passes in the identity provider service in Agent Core, as you saw in the slides. There's an Agent Core identity component. Think about it like a helper for the agent to be able to get that token. Instead of the token having the client secrets in code or an environment variable and doing that token exchange from machine to machine, Identity can do that for me. It has a nice SDK that will show how the decorator would inject that token. I need to create the identity to protect the MCP. The identity is a service that will handle protecting the MCP gateway. The MCP Gateway does not protect the Cognito. Cognito is protecting the identity.
The identity service is a service that will handle getting the token for the agent, but it needs to know where to get it from. You're going to get it from Cognito by requesting it with the proper scopes. This is why I'm passing the user URL, the authorization endpoint, and the token endpoint. The identity service is the one that will call Cognito to get the token back.
Once I have that piece of information, there's some information that I need to pass to Roland or Roland's team. I need to pass the gateway URL. Once you create the gateway, even without a target, you can keep using that URL. Roland will need the MCP URL to use the MCP SDK to connect to it when he creates the agent. I also need to give him the identity provider name. In Agent Core, as you develop multiple agents and MCP gateways, you may have different identity providers, so you need to select which instance of that provider we just created in this script. The resource server ID comes from Cognito when you ask for a scope. For example, for that gateway, you get a token that has the right claims, like a JWT token with the right claims.
Let's run the script to see if we can get our MCP gateway created. I have different scripts in here. You can see I have scripts to test the gateway and test the connection. I'm going to show that in a minute. We're also creating an S3 bucket to save those JSON files. Let's create the gateway. We're going to run it once, and then I'm going to run it again. In this case, it's going to create the Cognito, create the identity service, and create the MCP gateway and get that information stored in SSM Parameter Store for Roland to use.
We have emojis because Quiro likes to put emojis on status, which I think is cool. It describes all this text output. I think it's very useful. Quiro put it in for me. This is the gateway that Roland is going to use, so I'm going to give it to him. Let's go to the console and see a little bit of this. This is the AgentCore landing zone or the first page that you see. On the left, we have gateways, and we have our reinvent app gateway that we just created. It has the MCP URL that I'm going to pass to Roland and the identity, the inbound identity using Cognito and the discovery URL on how it's going to be created. So far so good.
Configuring Gateway Targets and Security with Cognito and Secrets Manager
Now let's create the targets for my three microservices: appointments, technicians, and claims. The next piece of this setup is Part B, creating the MCP gateway targets. You can create the gateway once and then get the targets. Let me comment out this code here. Then I'll run it again. This is the information that it's going to do. I'm going to show you the code. I'm going to do appointments with a description, customer, and technician. The claims are inside the customer. So it's three services: appointments, customer, and technician. The claim information is stored inside customer with the policy.
It will go over each of the three targets. It will build the URL, remember the URL that was missing. So I'm going to fetch the JSON file, insert that URL in this function, upload it, and then upload it to an S3 bucket. The way the MCP gateway works is you have to put this JSON file in the S3 bucket and then give the gateway the S3 location of this file to create the target. This is the API URL that you're going to hit, the path, and the bucket name, and then you create the target with the credential provider ARN.
What this does is if your REST API is protected, which it should be most likely, it could be a parameter or it could be an authorization header, like an authorization header.
I like having a header like an authorization header, the URL to that bucket, what I want to call the target, a nice description for it, and then the gateway ID to which gateway I should attach this target as I create the target.
This code actually runs three times. As you can see here, it ran three times and got the JSON code. Jason opened his spec API, inserted the server, put it in three buckets, and created the gateway. The S3 bucket should be here. Let's see if it's here. Agent Core Gateway. Yeah, so these are the three JSON files that this code created. It grabbed that and created the appointment, Jason customer, Jason technician, Jason, and that's what I passed when I created the target. This location of these Jason files is here. So this is where the JSON is located, and then the target can be created. We grab it and then we expose it. If we go to the Agent gateway here at the bottom, I have my technician, my customer, and my appointment. There's not much information, but it says their status. It takes about a minute to be created. The JSON and the S3 location of that JSON file and an ID. There's not much detail about it. This will click and go into how to authenticate to the REST API.
Let me go back to the code. How are we doing with time? We're good. The other thing I wanted to show is the S3 bucket, the gateway, and then the information I'm passing to Roland, which is the SSM parameters. I think it's here. Let me open a new screen. I think it's parameter store. I use parameter store because it's configuration. It's not like a secret. If I had a secret, I would store it in Secret Manager. I'll show you in a minute. Secret Manager is used when you have to configure IAM policies because the identity service is using a client token, a client secret, and that secret is stored in Secret Manager.
Any time the identity service needs to do a token exchange, it will go to Secret Manager, grab the value that is there, get it, and then do the token exchange with Cognito. The same thing happens when the MCP gateway connects to your REST API. If you have an API key, for example, or an authorization header, and this is configured to access this REST API, it also stores credentials in Secret Manager. The service has an integration. Agent Core has an integration with Secret Manager to do that for you. It's a convenient way of doing that and also providing the SDKs to trigger it from the code.
When I run the code, this is what happened behind the scenes when I created the target and I created the identity. This is the information that I'm giving Roland. For example, the most important one is the MCP URL. As you can see, the value here matches the gateway bedrock agents West 2. We are in West 2 Amazon AWS.com/MCP. Roland is going to use the MCP client stream streamable HTTP endpoint to connect to it with the token when identity gets the token back. It's one way you can have multiple ways of interchanging this information. If it's something that is already known, we did it through code because that makes it more secure to handle the parameter passing.
I showed the S3 bucket where we're storing the JSON or the Secret Manager. I showed you Secret Manager will have a few pieces because we are also doing the inbound identity service. When somebody wants the UI to talk to Agent Core, it's not like anything can talk to your Agent Core. We want to protect that connection to the agent. You can see here this is the information saved as an API key, the API key that accesses the service, and then the reinvent Cognito here. I can show this, right? This is the client secrets, and I'm going to delete this by the way, so it doesn't matter.
This is the client seeker. So if you have automation to rotate this client seeker in cognito, maybe you generate a new one if it got leaked, then you can have some automation that actually rotates, goes into cognito, rotates the client secrets for a new one, comes back to Secrets Manager, and you can just put it here. Then the next time the Identity Service needs to grab this to exchange for a cognito token to access the MCP Gateway on behalf of the agent, it will have it there.
So the automation is there, and that's why we provide all these services. All of them have APIs and we offer SDKs so you can use CloudFormation, the CLI, Terraform, or CDK to actually do this rotation. Some companies have policies where customers want to rotate maybe every 90 days or every 6 months, so that's the integration with Secrets Manager. You will see that this information, if you get all the details about the Identity Service, so actually I can show that here that it got created. So you can see here the reinvent cognito gateway provider. That is the provider that my code created, and this is the information that is stored behind the scenes on how to get access to the client secret which is here. I could go here and click on it and it will go there, so that's the integration. And the security aspect of using agent identity. I think that's it, Roland.
Agent Developer Demo: Building the Strands Agent and Live UI Test
I have the same parameters for you. Let me remove my things so you don't need this. You don't need this. You're going to create an agent and then show us the UI. We're going to show the agent. All right, Carlos, thank you. Over here I'm inside the agent project. I'm more of an AWS native developer, so I use Agent Core Runtime, which is serverless. We're using Agent Core Gateway and Agent Core Identity, but the UI actually built it with ECS and Fargate because he's a Kubernetes guy and I'm not. I'm just an agent developer. We have a lot of our core highly scalable business logic on the EKS cluster.
So over here in the code, we're inside my project now. For convenience we put it all in Carlos's laptop, but we did this separately. We have home insurance, which is my agent. So the first thing we did is Carlos showed talking about loading the SSM parameters. He already showed them, so this is basically the code to actually go and retrieve the SSM parameters to get the information I need, which is basically the gateway provider name, the gateway resource server, and the MCP URL that he showed. This is just basic code that we use in AWS to go and get my parameters from the SSM store using the APIs in AWS. So the next thing we want to do is show the code around getting the MCP client and getting the authorization token. Now, we don't want to store credentials, make the staple, so we're going to use a decorator in Python so that every time we go and create the gateway client or we access the gateway client, we want to be able to get a refresh token. So this is a good pattern to do using a decorator pattern. It's going to call the SDK APIs to get the access token. So each time it calls this function, you're going to get a refresh token, which is a security best practice.
So here you see we're going to get the URL and then we're going to use the standard MCP client SDK to actually create an MCP client using a Python Lambda function. We're creating that using streamable HTTP client because it's a remote MCP server that's hosted by the gateway. We get the authorization header which is refreshed with the decorator each time, some timeout parameters, and so on. That's the next step that I do in my code as an agent developer. We have, of course, access to the model. I believe we're using Claude Haiku 4.5 from Anthropic. And then this is just some cleanup code around stopping the gateway. So here we have Part C, right? We're going to create the AI agent and we're going to make it an A2A server. So we're going to get the headers that we need because we want our agents to be able to access AWS resources like the gateway and identity. We're going to get our Agent Core SDK token as well. We're going to get our session ID as well, so we're going to have a session. And we're going to use a little helper called agent context to kind of store the session ID as well if it's not found.
Since we're using Agent Core runtime, if a request comes in and the runtime is still up and running, we check if we've already gotten the agent. If it goes away, it'll lazily create the agent again. Over here, we use the agent context get agent. If it's not there, we actually go ahead and create it. We start the client gateway. We set the client gateway and we get the list of tools. Here we have our Strands agent. So we use the Strands SDK. We give it the list of gateway tools that we get from the gateway, give it our model, we give it some of our system prompts and a description, and we go ahead and create the Strands agent. Then we wrap the Strands agent as an A2A server. That way in the future if another agent wants to invoke this agent, that's set up and we run that inside of Agent Core runtime.
So let me show you some of this. This is the first time I'm doing this on Carlos's machine, so we're going to look at Agent Core runtime. We've deployed this code to deploy that is there as well. We have this Home Insurance agent which was deployed version 41. So we deployed this a few times. We have an existing running one already. You can see we had a two week gap. I was traveling that week for a customer visit. So we have this running in our runtime. It's a serverless runtime. It does all the things around observability as well prebuilt in. We're really excited about that. We also have the UI running in ECS Fargate. I'm going to run it locally for the demo here.
So I'm going to go back. I got all of Carlos's history there. All right, yep, you've run UI. So let's go and run the UI application. We're good. Yeah, local host 8000. I think I have it opened up already. I think the greater one, yep, cool. Let me refresh it to see if it's connected. Demo goats are inside, yeah, Wi-Fi demo goats. All right, there we go. So I'm going to say, let's see, get your caps lock up. I don't want, yeah, like we did have the tools. Do you have access to the tools? Let's see, so this is the video that you saw at the beginning, like asking do you have access to the tools, and they should come back with something about appointments, customer, right? The three microservices. Let's see, yep, so there you go. Where is it? The three tools, the three different microservices: appointment scheduling, technician services, and so on. I'm going to say Carlos was dancing salsa. You have to be specific. He crashed into the fridge. It's water everywhere. There's still water everywhere. And buttons don't work, right? Yeah, all right, so this is what happens when Carlos does salsa dancing. Let's see what we can get. And you are user Emily. I think she has a valid policy. We'll see. Yes, so notice we logged in. I was like perfectly. I successfully created your claim with 019. Claim has been submitted marked as high urgency given water is everywhere. This is definitely a high priority issue. Would you like me to schedule an emergency service appointment repair? Yes, please schedule that quickly before Carlos's wife finds out. See what we can get here. So it's going from the UI to the agent to the MCP gateway to the ECS cluster and back, right, and the LLM in the middle, right? The LLM, this information, yeah, my agent is sending that to the LLM and this agents have reasoning, right, so it can go multiple times to the LLM to reason about it with multiple calls, not just one MCP call. Still processing here we go. All right, so an appointment, yeah, so it says perfect. Yeah, I've got you set up appointment time, et cetera. David Chang, so in two hours, December 2nd at 9 p.m., pretty late technician visit.
I can hear the concerns in your question. While I'm quite skilled at handling refrigerator emergencies, insurance claims, and scheduling repair appointments, I'm afraid my expertise doesn't extend to managing Carlos's salsa dancing habits. That's definitely outside the scope of my home insurance assistant capabilities. The LLM gives me some suggestions: you need a dance instructor, maybe get a Cuban like me, and then you can maybe get clear more space. Maybe don't dance by your refrigerator. Maybe some dance lessons for you and your wife, and maybe some protective padding around your appliances. So some good recommendations for you as well.
Key Takeaways, Resources, and Upcoming Sessions
That's smart. I think that's kind of the demo that we have. We showed some of the code and we will be putting this in samples very shortly. We have a slide with the QR code that has all the right things. Let me switch back to PowerPoint. This is the demo that Ron already played. This was our backup because the Wi-Fi didn't work. We didn't need the video, which I'm pretty sure we didn't need anyway.
So what we learned and resources: we definitely have the ability to expose your existing systems and your deterministic logic. Use MCP Gateway to expose that logic, make sure you have security, and make sure your agents are the only ones that can secure it and act on behalf of the right users. Agenta can unlock a bunch of modernization for you. We do have some samples and stuff we'll be doing both on the EKS side and AgentCore examples, and we'll be posting them. We have some resources here if you want to take a picture. This is where you're going to see the access to the resources that we mentioned and some also useful links, and the code is there. Check it out, it's there.
Some sessions: tell your friends we're repeating this tomorrow if they want to see the code. I'm doing session RC 3:14 at 5:30 tomorrow over at the Wynn. That session is going to be with another colleague of mine named Redula, and she and I will talk a lot about the architecture considerations and things. If you can find us in the expo, you can ask questions. Since this is recorded, we'll take questions after we stop recording.
The other sessions: the 3:17 is here in Mandalay Bay at 4 p.m. You can meet me again. We're doing a hands-on workshop on EAS MCP. If you're learning about MCP, how to use MCP EAS to troubleshoot your ECS cluster or analyze it or manage and do DevOps with that, we're hosting an event for our technical field community and some customers at the Venetian Rock house later at 5. If you want to pass by and ask questions and chat about those things, you'll find us there as well. Thank you for coming.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)