AWS re:Invent 2025 - Building software like never before with Agentic AI (DVT220)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - Building software like never before with Agentic AI (DVT220)

In this video, AWS introduces Kiro, an agentic development environment launched November 17th, featuring spec-driven development that guides developers through requirements, design, and task lists for production-level code. Rackspace CTO Brian Lichtle shares their implementation results: 85% efficiency gains across 800 developers, saving over 8 FTE years in four months. The session also covers Amazon Bedrock AgentCore, a modular service for deploying AI agents at scale, demonstrated through building a customer support agent using the Strands framework that processes requests in real-time, showcasing how agentic AI transforms both software development workflows and customer-facing applications with autonomous decision-making capabilities.

; 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 Software Like Never Before with Agentic AI

Welcome to the session, Building Software Like Never Before with Agentic AI. My name is Svetlana Kolomeyskaya. I lead the outbound go-to-market for Agentic AI Development Experience services, and I'm joined today by my co-speakers. Al, would you like to introduce yourself?

Yes, thanks, Svetlana. Hi, Al Destefano. I'm a Senior Go-to-Market Specialist here at AWS, and I'm on the Agentic AI Developer Experience team. And very excited to also have a customer, Rackspace, co-presenting with us. Brian, would you like to introduce yourself?

I would. Thank you. I am Brian Lichtle, Chief Technology Officer for Rackspace IT. Thank you so much. All right, so let's get started.

So Agentic AI is really reimagining the future of software development. It's reshaping how we build, deploy, and scale software applications. And I think at this time, the majority of developers, the majority of you, are probably using some type of AI development tool. How many of you are using a tool day to day in production, like today you do your day-to-day job? How many of you are actually experimenting with three or more tools this year, right? Absolutely, so these tools are changing very, very quickly, and it's only the beginning, and the technology is evolving as well.

So what we're going to do today, we'll talk about the latest Agentic AI services from AWS and how they help drive business value for you and your organization. And so we'll talk about accelerating software development with Kiro, which is our Agentic development environment that was launched just a couple of weeks ago on November 17th. We'll also hear firsthand from Brian talking about Rackspace's journey with Kiro and what they were able to accomplish just in four months. And then we'll talk about building your own custom agents into software applications, and then we have a lot of demos for you because everybody loves demos. So let's dive in.

The Evolution of AI Development Tools: From Autocomplete to Agentic Systems

So I think it's fascinating to see such a rapid pace of innovation just in a few years. Just a couple of years ago, everybody was excited about autocomplete, right, helping developers write code faster, so the AI would just predict the next line of code that you're typing, or you would give it a prompt or a comment and it would give you a couple of lines of code. And then we moved to the next level, the assistants, the chat modality, so you can have a conversation via chat, right? The prediction became bigger, the length became bigger, and also the quality became better as well.

And this year it's really all about the Agentic space, so Agentic AI. And it's really looking to understand the context. The AI system understands the context, they also engage with you in back-and-forth conversations, and also autonomously can perform different actions on your behalf. So it's really, really fascinating. It's no longer a prediction. It's really you can start offloading a lot of functionality, a lot of things to the agent and just let it run with it.

So today we're seeing customers drive value with Agentic AI across two primary use cases. The first one is what I'm going to be covering, which is accelerating software development through every phase of the software development life cycle. So we'll talk about pre-built applications with Agentic AI built in. So we'll talk about Kiro and how it's bringing mature engineering practices to AI coding with spec-driven development leveraging AI agents. And later on I will talk also about building your own custom agents for software applications. So we'll talk about how to enhance different workflows within applications, how to enhance customer experience through the use of things like natural language within the application as well. So we'll talk about services that help build, deploy, and operate AI agents in production securely and at scale. So let's dive in.

For accelerating AI across the software development life cycle, it's not only across the development phase, but also it helps accelerate things across other phases of the software development life cycle, for example, requirements definition, sprint planning, backlog grooming. All of those things also it helps us do a lot of these things that, you know, a lot of us don't really want to work on, for example, creating test cases or documentation,

and all the way to retiring technical debt. So you may be taking ownership of an application that's a legacy application, and you have older versions of toolkits or languages. So how do you transform that into a more modern architecture? With all of that, AI systems can now act as partners through the entire software development process.

Addressing the Challenges of AI Development: Introducing Kiro

So we have a lot of promise of agentic development, but I also want to acknowledge some of the challenges with AI development that we hear from a lot of our customers, a lot of developers, especially for complex use cases and projects. So the promise is autonomy, right? The agents can take on and complete increasingly challenging tasks autonomously. But what we see is, especially with vibe coding, vibe coding is great for smaller tasks. It's great for prototyping, but not necessarily for production level workloads because we see that developers continue to, after the vibe coding and the code is created, modify the actual code or create bug fixes or fix those bugs.

Then another one is true collaboration. Developers and agents work together to get more done. But then we see that there's limited control with some of the existing tools out there, especially with inline coding or chat. Those interfaces sometimes lack the end-to-end experience that you may be looking for, right? You may want to have more visibility into the work that you're doing. The agents are running, you want to see monitoring, you want to be able to intervene into the actions and perform those.

And then the promise is higher quality. Agents can handle the heavy lifting, which is absolutely true, so they can help with things like test coverage and documentation. But then on the flip side, as projects grow, those things to maintain become a bit challenging as well. And existing tools don't necessarily provide intuitive ways to verify that the work that has been produced by AI agents really meets the developer's quality or meets the intent.

To address a lot of these things, a lot of these challenges, we launched Kiro, which is our agentic development environment for structured AI coding for production level applications. So Kiro helps developers and teams do their best work by bringing mature engineering practices to AI coding. During the preview, which we launched in July, it was meant for individual developers, so you could just use a credit card and swipe it and use it in your day-to-day work. And then with Kiro GA a couple of weeks ago, we launched Kiro Enterprise as well, so you would have different features that you would expect from enterprise: single sign-on, logging, monitoring, subscription management, governance and control, and more.

Spec-Driven Development: A Guided Approach to Production-Level Code

And then with Kiro, we have two different interfaces, so different experiences that you can leverage. One is the fully agentic Kiro IDE, and another experience which is Kiro CLI, which is your agentic experience in the terminal. So what I'm going to do is I'm going to walk you through a number of key features that we have in Kiro, and then show you some demos. Let's say throughout the day you are building a new application, you are adding a feature to an existing application or a new application as well, and let's say you're leveraging vibe coding.

So with vibe coding, what we heard is, with vibe coding you have a prompt and then it will generate a lot of code, and sometimes it's a lot of code that it generates, right? So I talked to a customer just last week and they told me that they generated 800,000 lines of code per month, and only 25% or maybe less than 25% actually gets into production. So how many of you are experiencing the same experience? How many of you are generating tons and tons of code which eventually is not making it into production? So in order to solve this, we created a spec-driven development feature which offers a guided experience.

It's really bringing back that rigor and discipline across the software development lifecycle, which we follow for a reason. When you define or create a prompt, rather than starting to create a lot of code, Kiro will work with you to define requirements using user stories and acceptance criteria. Once you're ready, it will work with you on the design, determining what languages you're using, which database schema you need, and what interfaces are required. Then it will create a task list, essentially your task backlog, and also an approach for how to tackle those tasks. By spending a little bit of time up front, it provides better outcomes in terms of the code that's being generated, and it also reduces the time spent on rewrites that you need to do.

Let me show it in action. All right, so I have an application here which is a full stack Flask application for managing events, contacts, and invitations. I already have it built here, so let me take a look at what I have. I have an events application with a title here, so we're at re:Invent, so I'm going to use re:Invent 2025. There is a description here. I have a date and location. What I do not have right now is a category field. I may want to say that re:Invent is a conference, and later on I may want to add a few other things like chalk talks and also breakout sessions.

I'm going to go ahead and create that feature leveraging Kiro. Vibe coding is still supported, but I'm going to use the spec-driven development. Here I'm going to enter a prompt. In this case, I'm going to create categories for my events and also filter my events by category. I'm going to submit my prompt, and Kiro will start working with you on the requirements. I'm going to open the menu, and you can see here all the specs on the other side. You can see requirements, design, and task list. This is that guided experience that I just talked about.

You can take a look at the requirements that were generated, and they are generated in the form of user stories and acceptance criteria. I'm going to take a look at it because we always want to have a human in the loop. If I don't like something, I can modify it directly here, or I can ask Kiro to add additional information or additional requirements. I noticed that I want to see the ability to see all events that are not assigned to a category, so I'm going to ask Kiro to add that. The acceptance criteria was modified, and I'm really happy with what I have so far, so I'm going to move to the design phase.

As part of the design document here, I'm going to have the markdown file. I have high level components and the interfaces. I'm going to have my API routes and the error handling, and I'm also going to have obviously the testing strategy. We can't forget about that, so we have unit tests and integration tests and others. After that, it looks good to me, and I'm going to create the task list. Here I get an option to build out an MVP so that I can test it faster, so I'm just going to select that. Perfect, things are looking good.

Now all of the files were reflected in that selection that I made to create the file, and I'm already starting to code, so I'm going to start with my first task. For some of the commands, it will require your approval. Here to run the bash commands, it's going to ask me to approve this. Then Kiro continues testing and prompting the user until this is all done.

So all passed. We are in good shape. We are ready to go, and we're also going to check the database because I added a new feature, so that means that I might need to have a table created here. So everything is great and ready to go. So what I'm going to do is continue obviously adding additional tasks and also complete all of the tasks as well. The key thing here is that we have the requirements traceability mapped to the tasks that we define in the requirements space here.

All right, so let me see what was developed. So now I have this application here. I can add additional categories, conference category. Let's add another one, breakout session. Right now we're in the breakout session and also chalk talk. So I'm going to add a breakout session. This is DVT 220. This is this session. And able to assign it now to a category. So we saw the process of the spec-driven development and that it goes through the requirements phase, right, the design and then the task list so you can write more production level code.

Automating Repetitive Tasks with Agent Hooks and Advanced Context Management

And then also throughout the day we're doing a lot of repetitive work. You need to create test cases, you need to create documentation every time you make changes, and sometimes, you know, it's the end of the day and you know you say, you know what, I will get to these tasks tomorrow and sometimes tomorrow never comes. So wouldn't it be nice if there's a way to automate some of those repetitive tasks? In order to do that, Kiro has the agent hooks which really automates a lot of these tasks. For example, it can say that every time you update a Python file, update my test cases, update my documentation, or maybe you have an application that supports multiple languages. So you can say that every time that a new label that's added, let's say in English, it's going to go update all the other files as well.

So let's take a look at the agent hooks in action. So here, I'm going to create an agent hook. And I'm going to use it to update the change log so every time I make a change to the file, I want to make sure that I document that. So what's been changed, a time stamp, and also I want to add a brief summary of what's been changed and I want to do it every time so I don't have to worry about this. So once I define that in natural language, Kiro will also take a look at it and add additional components. Not only is it going to look at the Python file, but it's also suggested that I will look at some of the text files as well. And now this change is going to be triggered based on the file save, but also other options are available as well. So this is the way to automate a lot of the repetitive work that you're doing.

The other thing we heard from our customers and developers is that with vibe coding, the generated code does not look like the code that I write, right? It's not based on my standards. It's not based on the organization standards, best practices, right? Is there a way to provide additional content that's tailored to my project? So we have a feature called advanced context management with steering files that does just that. So you can add your coding standards, your organizational standards, you can add testing approaches to use specific test libraries. You can use security guidelines, deployment process, all of those things that you can add as part of the steering files so that you can be added to your context so that you can produce better quality outcomes.

It can also work together with your spec-driven development. For example, you can create a steering file that has persona for your application. So every time then you create requirements that use the stories, it will leverage those persona files as well. So they work together. So let's take a look at the steering demo. And here in the demo what I'm going to use is I'm going to use a brownfield application.

Let's try it again. Here I'm going to have a brownfield application. So instead of writing requirements right away, I'm going to go and create some steering files to give context for my application. First, I'm going to have the product markdown file that describes what the product is doing, the core features, the user experience, business logic, and so forth. Kiro will create that for you, right? Then it will create the tech markdown file, which includes what technology you're using as part of that, the database schema, and it will also create the structure document where all your files are and all of those things. So this is all opinionated. Kiro will create that for you for brownfield applications, but you can also add additional steering files.

What I'm going to do here is create a steering file for my coding standards. Based on that, what I can do is I can add my own coding standards and start from scratch, but I can also ask Kiro to recommend some of the standards for me. Here the coding standard steering file was added, and you can continue adding additional ones. It's asking me to add an existing rules file, but we'll just go ahead and ask Kiro with a simple prompt to add recommendations. Based on that, you just get recommendations, and of course you can look at the files and make changes as well.

So get started with Kiro today and leverage your spec during development. We have a lot of announcements. We had announcements for Kiro Powers that really brings expertise from different partners. We also announced a Frontier Agent for Kiro as well that really acts as a virtual developer, an extra teammate, so to speak. Get started with Kiro, let us know if you have any questions, and we'd love to hear your feedback as well.

Rackspace's Journey: Achieving 85% Efficiency Gains with Kiro

With that, what I'll do is invite Brian so that you can hear a perspective from Rackspace on how they've implemented Kiro in their organization. Thank you, Brian, for joining and sharing your experience with us. To start, if you could give us a brief introduction to Rackspace and your role there. Simply put, Rackspace Technology is a premier AWS partner leading the way in data, AI, and managed services for our tens of thousands of customers worldwide, and my role at Rackspace is the Chief Technology Officer for IT.

Great, and let me show this. We'd love to hear about your team's process for evaluating AI development tools. I know that you selected Kiro, so how did you get to selecting Kiro as well? Rackspace is not unlike any other organization where developers like their own tools. Different organizations pick tools that they like, but that's not cohesive, and one of the things that we're building within Rackspace is the concept of one Rackspace. When you look at the capabilities of the other tools provided, each of them had their strengths, but they also had many, many weaknesses. There were things that they did and they did okay, but they did not do well, and that's when we were introduced to Kiro and identified all of the strengths that it had. I'll be honest, it wasn't perfect at the start, but where it has come and what it has led our organization to do, the practices that we can build across the entire organization, that's when we truly said Kiro is our tool of choice and it is a one Rackspace development community that we will focus around.

That's great. And what tangible outcomes or results were you able to observe implementing Kiro within your organization? Sure, so it's funny when we first created this slide, we were at 81% overall efficiency gains within the organization, and that was about a month ago. We'll talk about it a little bit, I think, the evolution of how we rolled it out to the organization and the impacts. One month ago we were at 81%, and so as Kiro has evolved, as our teams have evolved using Kiro, building that community around it, our efficiency has gotten better and better.

So what it really allows us to do is it has allowed our developers to truly shift from perpetual maintenance to continuous delivery and innovation, not only for us internally but for the customers that we serve. It has helped bolster our security, our compliance, and really helped us move to a true innovation phase.

That's great. 85% efficiency transforming 700 developers. Can you give me more details about these business metrics, how you got to this stage, and how you're collecting all this data?

Sure. We knew that when we started, we needed to show the tangible benefits of what Kiro brought. A lot of AI innovation is, hey, let me just build something and then I'll think about the benefits afterwards. But when you start thinking about what is the minimum viable data that I need in order to prove out the efficacy of what we're trying to do, that's what we went for. So we started by asking four simple questions in a web form: What is it you're trying to do? What is your estimation as to what it'll take to complete it? And then once it's done, not only what was the outcome, but more importantly, what were the lessons learned, followed by what's the final duration?

As we have evolved over time, we started asking a few more questions, but again, we wanted to keep this very simple so that it was not a burdensome thing for our development community, but it helped give us the informative data that we needed to make the decisions that this indeed was absolutely the tool for us. And so what you've seen is we're over 85% efficiency, over 51 projects logged, and when you look at the time saved in the four to five months that we've rolled this out, we've saved over eight FTE years' worth of time in our development cycles.

Real-World Impact: Modernizing Critical Applications and Serving Customers

That's amazing. And can you, I see that you've listed some of the use cases here. Do you mind walking through maybe one or two use cases specifically, which projects that you delivered with Kiro and some of the outcomes?

Sure. One of the most formative use cases that we have is we have an internal application that is one of the most pivotal applications within our organization. Our Rackers use it to run our everyday business to support our customers, and we needed to do an upgrade. We needed to transform it. So the team had been working on it for months beforehand, and when Kiro came into play, we said, take it, try it, do all the things that we didn't have time to do before, like adding the missing unit tests, adding documentation, using Kiro to find dead code, find redundant code. And through that process, we were able to shave thousands of lines off of our code, have a much more robust, rich framework of code that was more maintainable, more secure, more reliable, and it helped us to migrate it to a modern version of Python. And it was actually the first application that we moved into production after Kiro.

And if I can add one more thing, it's not just how you use it to do things like modernizations, upgrades, enhancements. It's all about thinking differently. And so when you take a Python application that's built over 25 years and has had over 250 developers touch it, that can be a very scary thing to modernize. And so the development team said, hey, Brian, we have something we need to show you. This is kind of cool. And what they did was they built an MCP server integrated to Splunk where they used Kiro to say, give me all of the logs, de-duped, for the day prior to launch. Identify all of the errors that were occurring post go-live so that way every single hour after the application went live after the upgrade, they reran that query. And since it was directly integrated and ran from within Kiro, it was already contextually aware to where within the code base the error was occurring, so they could immediately then say

write the missing unit test, make sure it works, make sure I actually fixed the defect, and let's deploy. What that meant was they were able to fix 3.3 defects that came up within 15 minutes and redeploy. With an application that is so critical and core to what we do, as a CTO I'm going to hear it if something broke. Having that be one of the biggest transformations and modernizations that we had done in years internally, I had not heard a single complaint. Incredible.

And then when you rolled out Kiro to 700 developers, what does that also mean to your end customers? So at Rackspace we try to use ourselves as customer zero, and what that means is when we eventually will use it to help you, we want to make sure we understand the ins and outs of the tool, where does it shine, where does it not. What it did in a very short period of time was show a new art of what's possible. As we grew, so did the development community, and I think we're going to talk about it in a little bit. Now we're able to start using that for data transformations for one of our customers where two different large initiatives we saw an 87.5% overall efficiency gain, which helped our customer in their transformation journey in a fraction of the time. That's great.

Enterprise Rollout Strategy: From Spark to Raging Fire Across 800 Developers

So how did you approach the rollout for your development population? How did you approach the enterprise rollout? So I like to think of this in terms of starting a fire. We wanted to start small and start controlled. First was an ignition where you strike the match. It was a little bit interesting because when we first started, this all came from an EBC in New York City where our solution architect said you guys really need to see this. Since it was pre-beta, it was a very hush hush thing, so we came back and said, hey, this is an exclusive invite only opportunity, please do not talk about it outside of this group. We had a very targeted modernization approach.

This is how we're going to do it. So we started with eight different teams, different languages from Python to Java to .NET, and said follow this pattern, you know, standard practice. Create a new branch, add, ask Kiro to add missing unit tests, ask it to evaluate your code base for a currency strategy, create that and use that as a, or create a spec file with it to go ahead and do the modernization, do the transformation, run those tests again. Did it pass? That way we had a very prescriptive playbook. But the motto throughout this whole thing that you're going to hear is talk early, talk often. Don't wait for a biweekly sync to tell me what's going on.

By having that prescriptive playbook, it gives people the way to say, hey, I tried this, it didn't work, oh here's what I did, try this. It was in that initial rollout we saw a 90% efficiency rate where we did 52 man weeks' worth of work in three weeks. At that point we said we talked to AWS and they said, you know what, go ahead and add more people into the cohort. So we went from that spark to really adding accelerant, adding the twigs to get the fire going. We wanted it to continue to be a controlled expansion where, all right, now we need to truly start figuring out how do we formalize those outcomes, how do we shy away from just doing modernizations and branch out into all of the different areas that we need to.

We started saying, look, if you're going to be a part of this program there's two requirements. One, you have to communicate, and two, you have to continue to contribute to the knowledge base. As we saw it continue to grow and grow and grow, that's where we poured gasoline on the fire and we went from 100 users to 175 where, all right, it's now not just us as internal IT, but let's branch it out to our business units, let's branch it out to the product teams and support teams. That way we can see not only what is it doing for us but what can it do for our customers.

It was during this phase where Kiro went live and we said all right, all bets are off, start talking, start building the buzz within our organization. We created something called the Kiro Community Center of Excellence where every other Friday, everyone that's in the program joins for an hour. We go through three different things. We invite three different speakers to talk about what are the innovative things that you've seen, what are the innovative things that you have done, and you start building the excitement.

It was when we started that that we truly saw the gasoline on the fire. People started thinking more differently, more creatively in ways that they never thought that they could before. That's when we started the Rackspace development community, and at that point we said, you know what, all in. Even since we updated this deck two weeks ago, we're actually up to all 800 developers within Rackspace. Right at this point we have a raging fire where Kiro was rolled out at a true enterprise scale and we held that self-sustaining innovation engine where people can talk. If you're in a different part of the organization, it doesn't matter whether you're developing things for legal compliance, HR, for our cloud customers and AWS. If I have a problem that I don't know how to solve, I can look at that library of use cases and say, wait, let me go talk to you. How did you do this? How can we do this? How can we do it better?

That's where we really saw IT, you know, raise your hand if you've never heard that IT is a bottleneck. You can't see it on the camera, but there are no hands up, no surprise. This is where we truly started seeing a shift even from our business partners where they're starting to realize IT is no longer a bottleneck. They are now a true disruptor. And I heard, and correct me if not, that you personally as a CTO have been experimenting with Kiro and developing a few things. Guilty as charged. No longer is development in PowerPoint or Excel for me. Even using it for the most small tasks, I needed to do an ELT presentation and heaven help me, I could not find the one spreadsheet that I needed that had the graph with all the data in it. So I took a screenshot of it, I threw it in Kiro and I said recreate this for me in Python.

Within seconds it did and I went from spec mode to vibe code to say all right, change the colors around, make it so now that I can pull this directly from this Excel spreadsheet. And now I have a small web application that I can run on my desktop that I can update these statistics at a moment's notice. So what's next for you in your organization with Kiro? This is where we're now going from what can it do for us to what can it do for you, what can it do for our partners. We're starting to see, like I talked about with the data transformation earlier, our customers are starting to see and understand the benefits and realize how it can truly transform them and their businesses.

Building Custom Agents for Business Applications: Why It Matters

So 85% efficiency across more than 800 now developers. So congratulations first of all and thank you so much for joining and sharing your story, Brian. Thank you. Thank you. All right. And with that, I'm going to turn it to Al, and he's going to talk about building your own custom agents for software applications. All right, thank you, Svetlana and Brian. Brian, really appreciate everything that you guys shared. Every time Brian talks about Kiro, I get more and more excited. They're doing a ton of really cool things over at Rackspace. So again, Brian, thanks again for sharing.

We're going to shift gears a little bit and we're going to talk more about building custom agents and bringing them into your business software applications. So by a quick show of hands, who has already built an agent before? Doesn't need to be on AWS, but just in general who has built their own agent. Okay, a few hands. Now keep your hand raised if that agent is in production today. Okay,

now there are zero hands raised, and that's common. So what we'll talk through today is why you should be thinking about building agents into your business applications and then how AWS is enabling customers to do that.

Surprise surprise, enterprises are building their own agents. According to Gartner, they predict that a third of enterprise applications will include Agentic AI by 2028, and that's up from 1% in 2024. And at least 15% of work decisions will be made autonomously through Agentic AI by 2028. But why should you all care about that? Why should you care about this trend that Gartner's predicting that we're going to continue to see emerging?

The first is that natural language is truly becoming the UI with these agents. Now your end customers can just tell the application exactly what they want. So let's say that I order the wrong video game for my son ahead of his birthday and I contact customer support. If that application has agents built into it, I can just explain the issue and get a resolution immediately, as opposed to waiting on hold on the phone for a few hours or maybe waiting a few days for a customer support representative to contact me via email. And this is directly impacting the customer experience.

And that's the second reason why everyone should care. As we're building these agents, we have the ability to impact the overall customer experience through these applications. And the reason that we're able to enhance that customer experience is because these agents bring in a deeper level of personalization into the fold. So what may have failed 10 years ago is made possible because the agents are so easy to set up, and the reasoning and memory capabilities that the agents and models bring into the applications are something that we've never seen before.

The other element that these agents bring into your applications is what we call context aware intelligence. And so with this newfound context aware intelligence, because of the memory and reasoning capabilities that are brought into the applications, there's information that had already existed, but maybe the systems just didn't talk to each other. And the reason for that, and I'll go through this in a demo, but the reason for that is because it would just take way too many lines of code, too many classes that you would have to come up with, too many customer scenarios that you'd have to prepare for, and it just is too much to maintain over time. But with these agents, we're able to bring in that newfound context aware intelligence and ultimately affect the customer experience.

And the last reason that everyone should care, or the last reason that everyone should be building these agents into applications, is because you have to assume that your competitor is already heading down this path. By bringing agents into either internal applications to automate workflows or bringing them into external facing applications, you are creating a newfound competitive advantage for your organization. So we've talked through a little bit about why you should be doing this, but how is AWS enabling customers to actually build agents into their applications?

Amazon Bedrock AgentCore: Enabling Production-Ready Agents at Scale

So at AWS, our vision is to provide the best place to build agents, to build the world's most useful AI agents, and we want to empower organizations to deploy reliable and secure agents at scale. So not only are we building an infrastructure that's capable of supporting millions of agents that you are all going to continue to be building, but we're also investing in making AWS the best place to build and deploy the most trusted and performing agents. So let's go a little bit deeper into exactly how we're doing that.

So we at AWS understand that there are a lot of choices today. With such a rapid pace of innovation in the world, we don't want you to miss out on trying something new, and we understand that a certain framework and certain models may perform better with specific use cases or situations. And one of the themes you may have noticed throughout the week is our laser focus on providing the ability to choose.

So a quick show of hands, how many of you would be okay with building agents using one framework and one model for the next 10 years? Nobody is interested in that, and that is exactly the point. And this means that our job is to provide you the optionality, optionality around developer tools. Give you the ability to leverage any framework while you're building these agents. Give you full discretion of model choice because we're in the business of enabling you to build, not restricting you.

But once I figure all that stuff out, how do I actually get this thing into production? Well, we have you covered because earlier this year we announced Amazon Bedrock AgentCore, which is a set of modular services that provides you everything you need for scaling these agents into production.

Now who's asking themselves, well, what are all these options that you continue to speak of and what is this magical set of modular services that's going to let me get my agents into production? Well, that is a great question.

So here we can go through what some of these options look like. When we talk about AI developer tools, we've talked extensively about Kiro. We've heard how Rackspace is using Kiro in their organization, but there are other options out there. There's Cursor, there's Claude Code. And then when we talk about frameworks, at AWS we have what we call the Strands Agents SDK, and that's intended for building agents. But there's also LangChain and LangGraph, there's LlamaIndex and Google ADK. There are a ton of different frameworks that you can use to build the agents and get them into production and scale them out quickly.

And then Amazon Bedrock. So you need a model in order to power the agent that you're building. And so with Bedrock, through a single API, you can gain access to over 100 different models. Model optionality has been the premise of Amazon Bedrock since launch. You select the model and we just provide you the inference. But once I have the framework and once I've decided which model I want to use and I've already selected which developer tool my organization's going to use to build all of that stuff, we understand that there are also other components that enterprises need in order to get that agent into production.

There's going to be identity and access management requirements. I can assure you that many of the CISOs and security and governance folks out there are going to want to know what are these agents doing, how do I actually have observability into seeing what the agent's doing, and not only seeing what it's doing but understanding why it's doing what it's doing. When we talk about bringing reasoning capabilities into an agent, it's going to be making autonomous decisions. It's important to be able to see why it's making those certain decisions. And so when we came out with Amazon Bedrock AgentCore, we knew that it was important for enterprises to have these different components built in so that they can get these agents into production.

So let's focus a little bit more though on the AWS specific options. There are plenty of other options out there, but I'll dive a little bit deeper on the AWS specific ones. So again, Strands is our open source SDK for building agents using just a few lines of code. With Strands Agents, developers can simply define a prompt and a list of tools in code to build an agent, test it locally, and deploy it to the cloud. And then in Bedrock we have our Amazon Nova family. Our frontier models in Amazon Nova, depending on what the use case is of the agent, you're able to generate an image or generate video or you're able to generate text. We can have smaller micro models and we have larger parameter premier models.

And then we get to Amazon Bedrock AgentCore. So I've talked a little bit about the observability component, but we also need to have some sort of runtime. We need to be able to deploy this thing somewhere. So you'll see here a list of primitives or services that is what creates Amazon Bedrock AgentCore. And so with runtime, what that service focuses on is a serverless deployment with full session isolation and supports long running, low latency agent workloads with any framework or model. So again, we're continuing to provide you that optionality. If you want to use Strands, that's great. If you want to use CrewAI or you want to use LangChain, you're able to leverage any framework to scale out the use of the agent.

And then we get to memory components. So we talked before about context aware intelligence. The way that these agents have that context aware intelligence is through short and long term memory. And so with our memory service in AgentCore, you're able to provide short term and long term memory capabilities into the agent. And then there's an identity component to it. So customers would come to us and they would say, you know, I want this agent to be able to access certain AWS resources, or I don't want it to access certain resources, or there are certain tools that I wanted to access and certain tools I don't want it to access. So there's an identity and access management component to building these agents, and that's necessary to actually get it into production, which is why we have the identity service in Amazon Bedrock AgentCore.

The other component that's really important with these agents is giving them the right tools to actually make actions or to pull in the necessary context to complete the task that you've given them. And so with our gateway service and our browser tool service, you're able to pull in information from MCP servers or from OpenAPI or Smithy protocols.

With our browser tool, you're able to pull in information from web pages, or say you were creating an agent that you wanted to fill out a form on a web page. Using computer use, you're able to leverage the browser tool to fill that out because the browser tool is a cloud-based browser runtime for building these agents, and it enables direct interaction with web apps.

Additionally, this week we came out with two more primitives within the AgentCore: the evaluations primitive and the policy primitive. I'll start with the evaluations one first. What that focuses on is being able to benchmark how that agent's performing. When we came out with AgentCore, customers had said, you know, this thing is going off and doing whatever I asked it to do, but how do I know if it's actually executing the tasks or what the actual performance is against some of my business metrics? And so that's where the evaluations primitive comes into play.

Live Demo: Building and Deploying a Customer Support Agent with Strands and AgentCore

So let's dive a little bit deeper into an example of a customer that is using Amazon Bedrock AgentCore today. Druva needed a solution that could automate critical security tasks and accelerate response times during high-pressure situations. Using Amazon Bedrock AgentCore, Druva built what they call DruAI, and it included a multi-agent orchestration. What's really interesting about the multi-agent orchestration is you get to a point where these agents start feeding each other information. When an agent is feeding another agent information, we start to really see the scale benefits of that.

With DruAI, they built the first agent they referred to as the data agent, and that was focusing on analyzing the telemetry of security issues. Then there was a second agent, which was the help agent, and that was focused on troubleshooting the issues that were identified by agent one. And then the third agent was the action agent, which focused on executing the tasks that were identified by agents one and two. Their outcomes are truly astounding. They resolved 63% of customer issues through direct automation, and this is a direct effect on the customer experience. They accelerated human support resolution by 58%, and that's made possible because of that context-aware intelligence that the agents brought into the fold. And then they were able to scale use across 10,000 users, showing real-world production impact.

But enough talking about all this stuff. Why don't we see a demo and see some of it in action? Okay, so back to my customer support example. So I opened up a customer support portal to help me fix the incorrect video game that I had purchased. I start filling out the category. I have a product issue, here's my email, that's my contact method, and then I describe what issue I have. I accidentally bought my son the wrong video game. He asked for the latest football game, but I actually think he meant football. What can I do to exchange?

So this is the old experience. Okay, we received your request. We'll send you an email in three days to help fix the issue. But what if that's not the only experience that we could have? What if we were able to bring an agent into this application and actually solve the customer's problem in real time? Because we have an agent built into this application, you can see that the exchange request is immediately processed. The agent knew that, according to their research, there's a popular game right now called Golazo 2026, and they're able to process an exchange immediately. And this, again, is directly impacting that customer experience.

And then it asked me some questions. Do you want to process the exchange? And then it asked me if I want to save my son's birthday, again bringing deeper personalization into the application. But why don't we see that in applications today? Because, as I mentioned before, the amount of classes that you'd have to create, the amount of customer information that you'd need to know, the levels of lines of code that you would need to create in order to bring that experience is just too much to maintain over time. We would have to know the different products that are in stock, so now let's just build an agent to be able to do that. We'll go through a quick demo showing how we would build that customer support agent.

So I'm going to open up Kiro, and I'm going to add the Strands Agent MCP. Using Strands and AgentCore, I'm going to build a customer support agent, and then I'm going to deploy it to Amazon Bedrock AgentCore. So first, as Svetlana had went through, I'm going to generate my steering documents.

And this is where I'm going to provide the guidance for the actual agent that's going to be created. I'm going to tell which frameworks I wanted to start with when it's deciding which framework to build, and then I'm going to give it guidance about deploying the actual agent to AgentCore. And then I'll flip over to spec mode and I'll give it a simple prompt explaining what I want the customer support agent to do. So I'm going to build an AI agent that is responsible for real-time handling of ingress customer support requests for the company. And you see, the first thing that Kiro does is it brings in that steering document. It brings in that guidance that I'm giving it, and then it creates my requirements document. And so in my requirements document, I go through the specific user stories and acceptance criteria that I want to make sure that the agent is bringing into the fold. And then you can see Kiro calling some MCP tools. So I have an AgentCore MCP hooked up to this, and so it goes and it searches some of the AgentCore documentation, and it makes sure that before it gets into the design phase, it's taking into account all the best practices that AWS has listed out for deploying an agent to AgentCore.

Then I get into my design document and I have my high level architecture. I have the different components of the agent. I have the key configuration of the agent, so this is where I specify what model I want to use, what the temperature is, what the max tokens are that I want the agent to have the ability to use, and then I finally get into my task list. And then I select my first task and Kiro's off and running, building my customer support agent using the Strands framework and then eventually deploying it to AgentCore. So we'll pull up the text files showing what the actual source code of the agent is going to be. And you can see at the bottom that the main entry point is going to be AgentCore Runtime, which is where we're going to deploy it.

So now we get to the deploy. So with a simple command of just agentcore configure, we're going to start configuring this agent and deploying it to AgentCore using runtime. So we see our agent, our entry point selection, and it's going to pull that down from our agent source code file. It's going to identify any of the execution roles that have been created. It's going to identify if we're going to have short or long term memory. Since I have short term memory now as we're building this, it knows to turn on the memory primitive within AgentCore. And then once that configuration is successful, we see what the next step is, and so the next step is just what our follow on command is going to be. And then our agent is off and running and built. So we have a deployment success, and then you can see what the next step is going to be, and we're just going to give a simple prompt to load just to test it to make sure that it's up and running.

And we get a response, so the agent is up and running and able to help our customers that are accessing our customer support application. And now I'll just quickly go through the observability components of this. So the observability piece is also built on OpenTelemetry. So if you use other products, if you don't use CloudWatch and use DataDog or New Relic or some other observability tool, there's no problem with that. So again, providing that optionality to customers and meeting them where they are. So here you can see the decision mapping tree, and so this part is really important because again it shows and explains what the why is of why the agents are actually making the decisions. And if they're making decisions and maybe if they're making decisions that aren't exactly what you wanted, then you're able to go and iterate and give it new commands.

So in just a few minutes we were able to build a customer support agent using the Strands framework. We then deployed it to AgentCore Runtime. We leveraged memory service within AgentCore as well, and then we were able to see what some of the decisions of the actual agent that were being made in the observability. So what should everybody think about doing next? We encourage everyone to try Kiro out if you haven't done it before. If you haven't tried it before, you can head to kiro.dev and you can download Kiro for free. And then we encourage everyone to go out and build your first agent on AWS. You can use Strands and you can use Amazon Bedrock AgentCore to deploy that agent and get it into production quickly.

We want to thank everybody for coming to the session. Please fill out the survey, and if anyone has any questions after the session we'll be up in the front and happy to talk to anyone that needs to. Thank you so much.

---

; This article is entirely auto-generated using Amazon Bedrock.