V2 goes stateless with a core-plus-extensions structure

involved with V2, but it gets better. So, let me tell you about that. So, in May, Angie Jones, who's responsible for developer experience at the Agoric AI Foundation, which is where MCP now lives, posted this blog. And one of the things that made me jump up and celebrate a little bit is that the protocol is going stateless. So, as somebody who's been working in the microservices world for a long time, stateful protocols are the absolute worst thing in large-scale distributed systems. So, the protocol is going stateless. It's also doing a number of other things. So, the first bullet is a stateless core. The second bullet is interesting cuz it's they also have structured MCP so that there's a core and there's extensions. If some of you were in the room for the previous two talks, they talked about MCPUI two talks ago, they mentioned extension. Well, that's what's happening here in the V2 MCP protocol is that they have extensions and tasks have become an extension. So, let me tell you a little bit about how tasks changed from V1 to V2 and I do want to give you one more demo. So, on the left-hand side, you can see what the protocol was before. These are the RPC requests that you were doing over the wire. On the right-hand side, you can see a couple of things. Task list has gone away. Good. Wasn't particularly useful anyway, especially at large scale. And instead of having this input required going over a long-running session, you now have an endpoint that allows you from the client side to say, "Here's an update." So, if you remember a while ago, I showed you that screenshot that said Temporal has this notion of a signal. That's effectively what this is. It's a way of signaling into this long-running task. The task result stays, but it changes because it no longer has this long session-based protocol. But, I put the picture on the right-hand side here to emphasize the fact that the life cycle management of these tasks is unchanged. That's actually sound. Now, I go into this a lot into more detail in the talk that I keep referring to. Um on the server side, in invoice processing, I have my own state machine that the invoice is going through. And so, part of what you're doing when you implement these server-side these tasks is you're mapping from the life cycle states of the task over to the domain state machine that's running the the application that the the MCP server in the back end or the tool. So, list again goes away. Now, remember I said that the MCP tasks specification has durability all over it? With this change, given that lists are gone, you now are required on the client side, well, kind of required. There's a little an a little uh parenthetical remark here. The The spec right now says that clients should persist task IDs, but it also points out that if you don't persist task IDs, there is no way to get it back. So, I'm not quite sure why this doesn't have a an all caps must.