Clip transcript
takeaways at the end. So, the use case that we're going to talk about here is a simple purchase order use case. So, the use case is you're going to get in a purchase order and then it's going to go through a number of steps. It's going to record the fact that the goods were received and then it's going to do in parallel, it's going to do some back office stuff updating inventory, sending out notifications and then in parallel to that it's going to pay some invoices. Now, the invoicing is going to happen via an MCP tool. Now, that MCP tool is has itself a number of steps. So, it's going to validate against an ERP, then it's going to have a little human in the loop to request approval, maybe. Um then it's going to reconcile against the ERP again, do a little bit more human in the loop and so on. So, you can see that on the right hand side that MCP server that's going to be it's a tool that's going to be doing the invoice processing for us. It is long running. It's not going to work in a request response style and that's what MCP tasks are all about. And what we're going to do and I'm today's talk is not about temporal, but really what I did here was just showed you a couple of snippets of the code and yes, I will be sharing all the code for what I'm showing today. Couple of snippets here and the real point that I want you to look at is that reject or approve. That is showing you that there is a mechanism for signaling into a long-running process. And that's really the point. And that's what we need is that this is all about asynchronous. So, you understand what MCP tasks are now? MCP tasks are allowing you to have an MCP tool that you can invoke and then it is long-running in the background, and then eventually you can get back some response. So, let's talk about that MCP tasks overview. This is a very simple sequence diagram. It's exactly what you all would expect when I tell you that MCP tasks are long-running tasks. You're going to invoke a tool, and instead of getting back a response, you're going to get a handle. And you can interact with that handle, right? Obvious, right? This is This isn't rocket science. Looks easy enough, right? Well, it turns out that if you actually want this to work over long horizons, it gets a little bit more complicated than that. So, what are some of those complications? Well, you can have all sorts of the longer something runs, the more likely there's going to be some kind of infrastructure blip that's going to cause a problem in that long-running task. So, you could have network blips, you could have network challenges, you could have humans that you're waiting for their in-a-loop part, and they go away on vacation like I'm about to, yay, um day after tomorrow. Um or processes can crash. So, your agent can go down. The agent that's processing the purchase order can go down, or your MCP server can go down as well. So, all of those problems you need to deal with, and those are the things that makes it a little bit more difficult. Now, in addition to what I've told you about MCP tasks so far that you're going to get back a handle that you can interact with by the specification those MCP tasks can't disappear. This is verbage from the spec itself that says once you've locked launched a task it has to be durable. What that means is all of these things that I just showed you on the previous screen clients humans going away on vacation servers going down clients going down connections disconnecting the task needs to survive that and you need to be able to interact with that task when the infrastructure comes back. And I'm going to show you how all of that is done. Now on there's elements there's server side