As Agentic AI Explodes, Amazon Doubles Down on MCP  🔗 **Source:** [As Agentic AI Explodes, Amazon Doubles Down on MCP](https://share.snipd.com/episode/8513fbee-072e-428b-9e56-b59b2a543338) ## Highlights - **Core Maintainers Shape MCP's Direction** - MCP core maintainers approve spec proposals and guide extensions through working groups. - Clare Liguori became one of 10 core maintainers and leads events/triggers work to add webhooks and notifications into MCP. Transcript: Clare Liguori So the MCP governance structure is a bit of a ladder. So core maintainers are the ones who approve or reject official proposals to the spec. And then there's a set of maintainers who maintain things about the spec, the SDKs themselves, things like that, with guidance from the core maintainers. Alex Williams So how many core maintainers are there? Is it like nights at the round table? Is it like 12 or is it like 500? I think it's 10 now. 10. So you're one of 10 people who are deciding the future of how agents get information. That's right. Do you wake up in the morning and just like stand very, very tall and think to yourself, yes, I am helping accelerate the future. I'm thinking big thoughts all the time. No, but really, congratulations. And what's the time commit from you to the Agenda K.I. Foundation and MCP in general? Like how much of your work life does that consume? Clare Liguori A bunch of it is leading things like interest groups and working groups. So all the ideas start in working groups, interest groups, extensions to MCP while we figure out, is this something that we actually want to add to the spec itself? Is it something that's going to stand the test of time as part of the spec? ([Time 0:00:56](https://share.snipd.com/snip/66ab89d7-c13f-4e4d-ab94-74bd5ccdd3f5)) - **Agents Are Becoming Always On** - Agents are evolving from tight request-response loops to always-on, event-driven processes that wait for triggers. - Clare highlights OpenClaw and other runtimes enabling agents to receive messages from Telegram, iMessage, cronjobs, and webhooks. Transcript: Alex Williams And that would maybe help me, for example, wake up a dormant agent, perhaps? Clare Liguori That's right. So really what we're seeing now is this new style of agent. It used to be that agents were entirely a very tight while loop. And we're starting to see, especially with things like OpenClaw and some other agent run times that are coming about, agents that are always on, agents that are waiting for events to Come in and they will start acting on them. Kerser Automations is another one where you can stand up a set of events. Alex Williams In OpenClaw, this is a heartbeat and what are they called? Cronjobs in OpenClaw? There's also Cronjobs, but there's also messages that can come in. Clare Liguori So you can connect it to Telegram, you can connect it to iMessage, all of these different things. And so you can actually communicate with your agent and wake it up yourself. Alex Williams And just to be clear, you think that should be part of MCP in the future as It's you're helping to make sure that makes it into the spec. Clare Liguori That's right. I think that is a big future of agents is these always on, but often idle agents. ([Time 0:02:17](https://share.snipd.com/snip/80defbb3-2521-4513-b7c9-0441bc801399)) - **Persist Context Before Putting Agents Dormant** - Preserve and reload agent context to avoid losing continuity when agents go dormant. - Saving conversation history lets an agent resume work immediately when triggered, improving efficiency beyond token savings. Transcript: Clare Liguori I think the biggest thing is that it continues context that it already has. So if you're able to save the state, effectively the context, the conversation history, and really easily load it up again as an event comes in, then you're never really missing a beat In terms of it continuing on work because new information has come in. Alex Williams Oh, well, ([Time 0:03:48](https://share.snipd.com/snip/fc955e6e-bf3d-49af-886e-3e0b197ebd25)) - **Stateful MCP Causes Scaling Challenges** - MCP's current spec expects servers to hold a lot of in-memory state, which complicates scaling and sticky routing. - AWS is working on multi-round trip requests (MRTR) to enable more stateless, scalable interactions. Transcript: Clare Liguori I work a lot on Kiro. Kiro is an MCP client. I also think we talk to a lot of the server implementers. I work a lot with Bedrock Agent Core Gateway, which is an MCP gateway. And so some of the work that's being done in the MCP community right now is based on working with server providers. The MCP spec, as written today, is actually very difficult to out as a server provider because it requires a lot of state to be held on a particular machine today in memory. That's really hard to scale out without things like sticky routing to a particular server. So we're working on something called multi-round trip requests, MRTR, to be able for MCP to do more stateless interactions over a time period. Alex Williams Stateless interactions, apart from making it easier to not have to carry information around between different servers, wouldn't that also make it just faster? Clare Liguori Yes, it comes with a trade-off that the client has to maintain more state. So similar to how we talk to models and the client is responsible for, you know, building up that conversation and sending it back every time. It's going to be similar in MCP. ([Time 0:06:48](https://share.snipd.com/snip/7387677d-9041-442e-be5e-80c3af6ce815)) - **Prototype New MCP Features With Real Implementations** - Build MCP features driven by customer needs and validate with reference implementations. - AWS implemented tasks and elicitations and uses Strand's Agents SDK to prototype draft spec features for developer feedback. Transcript: Alex Williams Even before the foundation, you guys did tasks and elicitations. So how did you choose those two as the things to bring to the project? And is there a third one coming from the AWS team that I should have my eyes out for in the near future? Clare Liguori A lot of the things that we choose to focus on come from our customers. We, again, like we have Bedrock Agent Core Gateway. We have a lot of customers who are creating MCP gateways to their enterprise APIs internally. But we also hear from our customers a lot that they want to build multi-agent architectures. And tasks is one way to do that in the MCP protocol, where you can fire off an agent, it's a long running task, and keep, you know, continuing to pull for the result until it's done. Alex Williams And how popular has that proved with developers in the field? Because it sounds lovely. Clare Liguori But is it as popular as you hoped with people out there that are building? Yeah, one of the challenges with some of these new features is, again, working with client implementers and server implementers to make sure that they support these things. Strand's Agents SDK, which is maintained by AWS, is actually one of the first clients to implement tasks. So we're using that as kind of an experimental playing ground for some of these new and upcoming concepts in MCP that are still in the draft spec, that we're still tuning and working on With feedback. ([Time 0:08:18](https://share.snipd.com/snip/52328daa-3031-4461-ab32-9cecb7e4c5b0)) - **Multiple Transports Can Coexist During Maturation** - Different ecosystems show divergent transport usage: some favor standard I/O, others remote HTTP, and both signals are valid. - Core maintainers weigh client and server feedback before making protocol-level decisions. Transcript: Clare Liguori How are people using standard IO versus remote HTP in our clients like Kiro? So we're able to bring some real world data to the decisions that are being made. So they're not being made in a vacuum. Alex Williams So hear me out. You're there. And let's just say another hyperscaler that may have an opinion about NZP is there. Your data says X, their data says Y. How would you figure out who's closer to ground truth if you have competing signals at the top? Clare Liguori Well, we're both ground truth with our own customers, right? So we actually had a core maintainer meetup, and this happened yesterday, that some people are seeing more standard IO use, and others are seeing more HTTP use, for example. And it really tells us that both are true, right? That both are still important for investment. Alex Williams But to stand the test of time, to quote you from earlier, it's going to be one of those is probably going to win eventually. So, okay. Then when do you decide when it's the right time to make that call as a core maintainer versus letting the debate in the market continue? Clare Liguori Again, a lot of it comes down to what are the clients saying? What are the servers saying? I think that there's still relatively few remote HTTP servers, but the ones that there are, they're very popular. And internally, what I see at Amazon, for example, not even just out in our customers, but as a large, very large enterprise with tens of thousands of developers, we still have a heavy Dependency on standard IO. ([Time 0:10:50](https://share.snipd.com/snip/52252f86-6fae-497d-a4ad-068d05917acd)) - **Gateways Provide Policy Controls For Agents** - MCP gateways act as control points that connect agents to enterprise APIs while enforcing policy and access limits. - AWS's Bedrock Agent Core Policy can restrict actions, e.g., limit mortgage approvals to a set amount via gateway policy. Transcript: Clare Liguori Anyone who is starting on their journey of building agents, regardless of industry, starts looking at MCP because they have existing data sources. They have existing APIs internally that they need to connect to agents. That's what makes the agents useful, right? Is that data, that API access. Otherwise they're dumb as hell. But how do you lock that down? How do you control? How do you have a control point for agents? And that's what MCP is and an MCP gateway is. So as an example, we released late last year, Bedrock Agent Core Policy, which lets you set a bunch of policy, limit the parameters of MCP tool calls. You can say, you know, if I'm a mortgage company, I can say agents cannot approve a mortgage of more than, I don't know, a million dollars, whatever it might be. And they set that in the policy. But you have to have that control point. You can't just give a direct API access and implement a control point, a policy like that. ([Time 0:14:12](https://share.snipd.com/snip/8eb88201-8807-408a-be5c-d119aefd7deb)) - **Non Engineers Rapidly Adopt Kiro Internally** - Amazon opened Kiro internally to all employees and non-engineers embraced coding assistance. - Clare said marketing and non-technical teams quickly used Kiro, showing broad cross-functional interest. Transcript: Clare Liguori We just, a couple of weeks ago, opened up Kiro internally at Amazon to all employees, all job families, because we had expected that only engineers would want access, and it turns out That's not true. No, no, no, no. Especially people on the marketing team who have been waiting for engineers. Exactly. They're going to just dive straight in. Yeah. But we also have products that are less technical to use, maybe like Amazon Quick, where you can easily connect a data source. Maybe you have an existing MCP gateway. And again, connect up all of those APIs, all those data sources to an agent that you can create with just a prompt. ([Time 0:16:04](https://share.snipd.com/snip/e4ea274c-aa8f-4e1d-9e93-4099357310ee)) - **Spec Driven Development Speeds Agent Coding** - Kiro emphasizes spec-driven development: agents generate a spec and design before coding, improving alignment and speed. - Clare shared an internal team that delivered a feature two months faster using Kiro's workflow. Transcript: Clare Liguori IDE and a CLI. And our big thing is spec-driven development. We were one of the first companies to create a workflow around spec-driven development. And internally, we've seen amazing results from it. We had a team who was building the add to delivery button on amazon.com. So if you go through a checkout process and you have an order that's coming soon, you can just say add to that delivery. Alex Williams Which saves on boxes, which is on delivery. Yeah, and gets it to you fast. Clare Liguori Oh, yeah, that too. But that team was actually using Kuro Spectrum and Development and was able to pull in that feature by two months. So we've seen some amazing results. And really what I value about it is that when you create a spec before telling the agent to go generate the code, you get a chance to think through what it is you want. That's the most important thing for me is kind of pulling that intent out of your head, right? So Kiro makes a guess at what you, you write a short prompt. Kiro makes a guess at what are the requirements for this piece of software? What is the architectural design for this piece of software? And then you get to go critique it. You're kind of the senior engineer to the junior engineer. Ah, so this is a bit like, to pick a different example, deep research on ChatGPD. Alex Williams It says, hey, I'm going to do this, this, this, this, and this. Cool, approve. Is that the right spec for this query you want? It's like that, but probably to the nth degree, but I have a comp, if you want. Clare Liguori Yeah, so it goes a little bit beyond that planning mode that a lot of coding assistants do have already. It goes to, what are the requirements? What is the tech design? Not just, here's the list of things I'm going to do. And that's what I find the most valuable. I probably spend the most time reviewing the design, making sure that we're on the same page, me and the agent, and then go and let it generate a task list of things it's going to go do. ([Time 0:17:20](https://share.snipd.com/snip/c7301d37-022a-4a12-899a-5867f88c18fa)) - **Open Weight Models Offer Low-Cost Tool Calling** - Open-weight models can be fast and cheap for tool calling and MCP tool integrations. - Clare recommends models like gpt-oss 120B for speed and cost efficiency when performing tool calls. Transcript: Clare Liguori I like Quinn personally. An Alibaba fan. Yeah, I found that to be the most valuable for coding um i for agents like building agents i'm really excited about gpt oss 120b i found it to be actually really good for tool calling with Mcp it's famously fast it is fast really quick and cheap well those are two of my favorite things exactly exactly and if we're doing tool calling, then why not? So you get a lot of bang for your buck with open weight models. ([Time 0:20:10](https://share.snipd.com/snip/639ef5d8-d7cf-4a1d-a40c-62d72b7f6f81)) - **Design MCP Servers For Agents Not Developers** - Treat MCP servers as products built specifically for agents, not as one-to-one mappings of developer APIs. - Clare warns against context bloat from mapping hundreds of developer API endpoints to agent tools and recommends better server design and guidance. Transcript: Clare Liguori I think of MCP as the integration layer. So it's connecting things to your agents, whether they be your personal agents, coding agents, custom agents that you've built. I think that what I hope for the future is that we start to treat MCP servers as products. I think the most used MCP servers out there have been really well designed. They've been designed for agents. What we see right now is a lot of folks making kind of a one-to mapping between existing APIs that are meant for developers and their code versus whether they're meant for agents. So we have this context bloat problem because there's hundreds of APIs behind a single endpoint and those just get mapped one-to to MCP servers. And so even, you know, internally within a company, thinking that as an internal product that you're designing for agents, I think that the challenge that folks have today is, number One, there's not great guidance for them on building MCP servers. But then you also have to think of yourself, maybe not as an endpoint or an API builder, but almost an agent builder because you're building part of the prompt for the agent. You're building those tool descriptions, the set of tools. And so you almost have to start doing your own evals. You have to be a little bit of a scientist now. ([Time 0:21:51](https://share.snipd.com/snip/eaff6af0-064c-4cfb-b048-c6d3681aec07))