🦄 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 - From UX to AX: MCP Servers for AI Shopping Agents (IND386)

In this video, AWS Solutions Architects Aditya Pendyala and Martin Sakowski discuss the shift from user experience to agent experience in e-commerce. They highlight that 51% of Gen Z customers start product searches on AI platforms, with Gartner predicting 25-30% of e-commerce will flow through agents by 2030. The speakers explain Model Context Protocol (MCP) and introduce Amazon Bedrock Agent Gateway, which converts existing APIs into MCP-compatible tools without rebuilding infrastructure. They emphasize three best practices: designing agent-first APIs with structured data, progressive disclosure by starting with high-impact APIs, and maintaining multi-protocol support for flexibility as standards evolve.

; 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

The Seismic Shift: From User Experience to Agent Experience in E-commerce

Good afternoon, everyone. Can you all hear me all right? All right, excellent. Let’s do a show of hands first. How many of you here in the last one month have used ChatGPT or Perplexity to find a specific product that you’re looking for? Okay, quite a few hands. Keep those hands up. How many of you have actually had AI purchase it for you? None, zero. Exactly. That’s the gap, and we are going to talk about that specific gap which represents the biggest shift in e-commerce since the mobile revolution.

My name is Aditya Pendyala. This is Martin Sakowski. We are Solutions Architects from AWS, and today we are going to talk to you about the seismic shift and all the work that you’ve been doing on user experience and why that is being reimagined to agent experience. Most importantly, what you could do to navigate this shift in order to not let you rebuild the whole thing all over again just because agents are coming over.

Before we go into the thick of things, I want to quickly talk a little bit about the state of e-commerce today. The first thing that I want to highlight is 51% of Gen Z customers are starting their product search in AI platforms. They’re not on your site. They’re starting off their product searches in an AI platform. And then we are estimating about $500 billion in annual sales through 2030. It’s just four years away. Think about that.

Gartner predicts that about 25% to 30% of all e-commerce will flow through agents in the near future, and this is where it gets really interesting. OpenAI reported that their product searches on their platform have been growing 340% year over year continuously, and what’s more, the traditional channels are declining. What does that mean? That means the Google product searches, the ones driving traffic to retailer sites, are down by 23% year over year. And even more important, the click-through is down by 30% year over year.

So what does that mean? Where’s the traffic? Is the traffic disappearing? Are people not buying anymore? No, people are buying. It’s just that the traffic that used to be generated and directed to your site through these traditional channels is no longer happening. There is shopping. They’re still browsing, but they’re not doing it the same way they used to.

So what does this mean for e-commerce builders? What does it mean for us? Over the last two decades, we’ve been perfecting the art of user experience. We’ve implemented great visual design, rich colors, nice images, and so on and so forth. We built smooth navigation, and we’ve extracted every single millisecond possible out of the page load times so that our SEO is great. Guess what? Agents don’t care about any of that. So what’s happening? It’s the fundamental shift from user experience to agent experience.

So what is agent experience? What do they care about? They care about good API design. They care about structured data. What that means is your data needs to be proper, it needs to be up to date, and it needs to be reliable. And the agents must find a way to interact with your data. So what does that mean? That means you need to have some kind of protocol that is able to expose that data to the agents so that they can interact with your data. This is the shift from user experience to agent experience, and it is super important. If your website does not adapt to agent experience, your site will disappear for about one-third of all e-commerce traffic.

Understanding Agent Protocols: A Deep Dive into Model Context Protocol (MCP)

Before we get to the thick of things and talk to you about how you could actually solve this, how could you implement this, I want to give you a quick sneak peek, again, a sneak peek at some of the protocols in the agent platform. You might have heard several platforms out there, protocols out there, but I want to highlight just four of them here because these are the most popular and have the most traction right now. The top two protocols you’ll see, the ACP and AP-2, are commerce-specific protocols. ACP is from OpenAI and Stripe. They’ve released and open-sourced the protocol, and it’s specific for product searches and checkout flows.

Then you have Apple Pay, which is from Google, which helps with Google payment flows. In the bottom, you have two other protocols which are more generic. The A2A, which is again Google’s own open-source protocol, lets agents communicate with one another. And then finally, the MCP. MCP stands for Model Context Protocol, again released and open-sourced by Anthropic. I call this the Swiss knife of protocols. Why? Because it’s not built just to do one single thing like a checkout or a payment. This is set up and built to do several things, setting up your foundations, security, and so on and so forth. So this is where we’re going to double-click today and talk to you about why MCP is something that is super important for you all to understand and how you could leverage MCP to move forward and get to the point where you would be ready.

I’ll let Martin double-click on MCP and take you further, and I’ll be back to summarize and talk a little bit more about best practices. So what exactly is MCP? MCP has three core capabilities. The first one is resources. Think of resources as readable data sources. That could be your product catalog, that could be your inventory or the order history, something where you can do a get request and you just get the same data without having write permissions on it.

Then there are tools. Tools are different where you can interact. The tools are actions for the MCP server, so you can, for instance, say add to cart. That is an action an agent can do, or process the payment, or update the inventory. Those would be tools that you can have in MCP. And then there are prompts. Prompts are pre-built interaction patterns that help the agent to effectively use your tools and your data sources.

There’s something important to notice, and often MCP servers are not labeled like this. There is local MCP and remote MCP. Local MCP is where the MCP server runs locally on your computer. That is actually the majority of MCP servers that you find on the internet, on GitHub, and they’re great for local automation on your computer, but they’re not helpful at all for agentic commerce use cases. Because the shopping agents like Perplexity or ChatGPT, they are running somewhere else, and they need to connect via the internet, via the network to your e-commerce site and your MCP server. So remote MCP is what you need to make this communication happen.

Solving Implementation Challenges with Amazon Bedrock Agent Gateway

Let’s say we have this remote MCP server. We put it in front of our e-commerce APIs, and now AI shopping agents can talk to our backend systems. Problem solved, right? Well, maybe not completely. There are some challenges. For instance, security. Security is important. How do you handle authentication? How do you handle authorization? Because an agent that is allowed to search for some products on your website might need completely different permissions than an agent that is allowed to buy something for a specific user.

Or observability. If an agent is buying something and it might not be exactly what the user wanted, you want to trace this from the intent that the user put into the agent, then what the agent did, the task to the MCP server, and down to your retail system. You want to understand that flow exactly. Or scalability. Those patterns will change completely, as Aditya mentioned. With agents, we’re seeing completely different patterns. Humans can click like two or three times a minute. Agents can run thousands or tens of thousands of requests in parallel, and imagine how this will affect your MCP server during peak hours, or even worse, during Black Friday weekend.

Or evolution. Protocols will evolve. We have seen that the protocols are changing quite fast, and your online shop capabilities will evolve over time, and shopping agents will evolve. And you have to make sure you’re always compatible with all of them, because if you’re not, you’re missing out on those customers. So the good news is you don’t have to solve all these problems by yourself, because Amazon Bedrock Agent Gateway comes in, and I can promise you it makes your life a lot easier. Why?

First, you don’t need to write those MCP servers by yourself. You don’t need to write them from scratch. Just take an existing API that you have already, or existing Lambda functions, and Agent Core Gateway automatically converts those APIs or those Lambda functions into MCP-compatible tools. So you have a product search API. This can easily become an MCP tool for product search, or you have a checkout API. This would be an MCP tool for checkout.

And the second one, Agent Core Gateway gives you a single secure endpoint for all the interactions that an agent can do. So we have built-in authentication for your agents, security, authorization, and so on, and all of this is managed for you. So the agent doesn’t need to figure out where to get all of this. It only talks to one interface, and you can control what the agent can do in your environment.

And then the third one I like the most is context-aware discovery. Think of all the tools you can build. There will be many tools that you have to expose. Think of all the APIs that you already have. The gateway understands what the agent is trying to do, and then it only surfaces the right tools that you need for that interaction, and it serves them with the right permissions. So if the customer asks, "Find me shoes for under $100," it offers you product search, of course, and inventory check and price filters and the checkout flow. But the agent never sees the tool for how to return the product or for order tracking, because you haven’t yet ordered a product, so you don’t need those tools and you don’t want to confuse the agent with all those tools that are not required for that particular intent.

Let me show you how that works in practice. So on the left-hand side, we have an agent with MCP. That could be Claude, ChatGPT, or your own custom agent. In the middle, we have Agent Core Gateway, and this is the magic layer where all this translation happens, and it exposes a single MCP endpoint that fluently speaks that MCP protocol. And on the right-hand side, we have our existing infrastructure, our RESTful APIs, or our Lambda functions.

So for the REST APIs, for these API endpoint targets, you have to use your OpenAPI specification, and then Agent Core Gateway automatically exposes them and translates them to MCP tools, so you don’t have to write the code for that. For the Lambda targets, you might have some serverless functions in your backend, maybe for custom business logic, price calculations, promotions, recommendation engines, and so on. Agent Core Gateway can directly invoke them and can wrap them as an MCP tool. So the beauty here is the backend that you have built in the past doesn’t see the change, so you keep all your APIs, you keep all your Lambda functions exactly as they are, and Agent Core Gateway does all of the translation. And if we’re looking at our problems—security, scalability, observability, and evolution—you’re all covered by Agent Core Gateway.

Getting Started: Best Practices and Key Takeaways for Agent-Ready E-commerce

So how to get started if you want to build this for your e-commerce environment? The first step is to think of your APIs. What are the capabilities you want to expose? What are the APIs that you already have that you can expose? And then find the OpenAPI specification for that, for your product catalog, for your inventory, for your checkout, for order tracking, and so on. You most likely have those specifications already. If not, you have an API, and generating that specification is straightforward.

Second step, think of authentication, and we have two layers here. So the first one is the inbound authentication. So you have to find out how the agent authenticates to your gateway. Agent Core Gateway can auto-provision Cognito or the OAuth flow, so you can, or you bring your own providers. So that’s how the agent interacts with the Agent Core Gateway. And then the outbound authentication is how the gateway authenticates towards your backend APIs. You can use API keys, you can use OAuth, or whatever you’re using today.

And then the third step, you have to set up Agent Core. So get those API specifications, point it towards the Lambda functions, then use the console, CLI, or SDK for testing. But in production, please use infrastructure as code like CDK to set it up. And then Agent Core Gateway automatically parses whatever you gave to the Agent Core Gateway and exposes those tools to that endpoint.

And then the last step is you get an MCP endpoint URL. Use that URL and connect it to Claude, to ChatGPT, and so on, or your own agent framework, and then test how good your APIs are performing with an agent. And maybe you find out they’re performing very well, or you might find out they’re not yet built for agents, so maybe improve the API because the API itself doesn’t change. It’s

just a tool for how you communicate with that. So that’s what you can test. It’s not that difficult to start with an MCP server and expose your e-commerce capabilities to an agent.

Well, we have built a lot of MCP servers in the past, and Adi will share some of the learnings we have done. Yes, so we’ve built several MCP servers internally within AWS, and we’ve tried what works, what doesn’t work, and so on and so forth. So what I want to quickly talk a little bit about are some of the best practices that we have seen really help us, and I’m sure these will help you too.

The first one is design agent-first APIs. What that means is you typically would need structured data, data semantics, and rich metadata. What does that mean? That means, let’s say you have a schema and you have price as one of the fields. You do not want your data sometimes to come as a text, as a string, and sometimes as a number. Agents are literal. What that means is they can’t understand what your intent is at this point in time, so you would have to make sure your data is proper and is accurate. If you have your data as a number but it represents as a string, you’re going to have problems. So ensure your data is structured and rich.

Next, progressive disclosure. What does that mean? Crazy term, right? What that means is, do not just expose your entire API ecosystem through the MCP yet. Start small. Identify those specific APIs that you think will create the biggest impact: product metadata, product details, maybe pricing, maybe checkout. Just pick four or five ones and let the end user agents interact with these APIs. See how they work, see the error rate, see the success criteria, measure the success, and see how they perform. You will be surprised how different these agents interact with your data as compared to a human.

So ultimately you expose these APIs, try out a few things, learn from those, and then add those APIs that you think are most relevant. That gives you the best approach because you’re not handling several hundred APIs at one time, but managing those things that actually create an impact.

Next is multi-protocol support. You’ve seen the four protocols that we talked about before. There are quite a few out there already. There will be more. So there will be consolidation down the line. Now we are not in a state at this point in time to say, oh, this protocol is a clear winner. Absolutely not. So we’re not recommending our customers to choose one protocol over the other. However, be flexible, be ready for those protocols that might come tomorrow that might become the de facto standard. So what you would need to do is make sure your foundation is set right. You abstract away all the complexity through Agent Core and set your foundation right so that way tomorrow another protocol comes in and that becomes a de facto standard, it’s plug and play for you and not something where you would have to reinvent the whole thing again.

So just to summarize the session, key takeaways. User experience to agent experience is real. It’s inevitable. It’s happening right now. MCP gives you the ability to provide that strong foundation so that you don’t have to reinvent the whole wheel, but MCP comes with those challenges. That’s where you can leverage Bedrock Agent Core to remove that complexity, have all the ability to offload all the complex tasks to Agent Core gateway, and just focus on that piece which is your business logic which drives you forward. And finally, it’s not about whether you will build agents or build e-commerce for agents. It’s about when.

Now, twenty minutes doesn’t do justice for agent e-commerce. There’s so much to deep dive on it. We just barely scratched the surface. We understand that. So Martin and I actually wrote a blog, co-authored a blog on the same topic. It goes into a little bit more detail. So you scan the QR code, it’ll take you straight to the blog post where we talk about implementation, the things that you need to consider, and so on and so forth. So please take a read. Let us know if you have any questions, comments right there in the blog. And we’ll stick around for a few more minutes if you have any questions. So thank you for your time and good luck with your implementations.

---

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