1 00:00:00,200 --> 00:00:03,320 All right, so at the beginning of April I went to New York for 2 00:00:03,320 --> 00:00:07,400 the MCP Dev Summit, and while I was there I got the chance to 3 00:00:07,400 --> 00:00:11,080 record a few podcasts with attendees that were at the 4 00:00:11,080 --> 00:00:12,600 event. This is one of those 5 00:00:12,600 --> 00:00:14,120 conversations. Hope you enjoy. 6 00:00:14,320 --> 00:00:18,160 Developers in the last, up until very recently have had to 7 00:00:18,160 --> 00:00:21,440 understand not the physical processor, but they had to 8 00:00:21,440 --> 00:00:23,680 understand the notion of a process. 9 00:00:23,840 --> 00:00:26,520 There's the correctness side of. Well, when I write this line of 10 00:00:26,520 --> 00:00:29,320 code, it is going to translate into the right assembly language 11 00:00:29,320 --> 00:00:32,400 down under the covers. I think this big transformation 12 00:00:32,400 --> 00:00:34,840 that we have going into the AI space where we're now 13 00:00:34,840 --> 00:00:37,600 programming with the natural language, that's not a formal 14 00:00:37,600 --> 00:00:40,360 language, you get to think about the logical process. 15 00:00:40,560 --> 00:00:44,640 We will ensure that we give you durability underneath that 16 00:00:44,640 --> 00:00:47,800 abstraction, so that as the infrastructure is doing all 17 00:00:47,800 --> 00:00:51,600 sorts of chaotic weird things, we will compensate for all those 18 00:00:51,600 --> 00:00:53,880 weird things. You just get to think about this 19 00:00:53,880 --> 00:01:07,960 logical process. The idea of programming 20 00:01:07,960 --> 00:01:10,960 languages and justice programming models has evolved 21 00:01:10,960 --> 00:01:14,560 over time. You have been deep in the weeds 22 00:01:15,720 --> 00:01:18,800 studying it, being part of it, helping shape it. 23 00:01:19,280 --> 00:01:23,120 Tell me about what you see as like the evolutionary through 24 00:01:23,360 --> 00:01:26,040 through line or thread that goes through it. 25 00:01:26,440 --> 00:01:30,960 So I recently did a an internal developer conference for one of 26 00:01:30,960 --> 00:01:33,080 our our users, one of our customers. 27 00:01:34,120 --> 00:01:37,000 And the very first slide that I showed them was a slide of a 28 00:01:37,000 --> 00:01:39,960 processor. And I asked in the room, how 29 00:01:39,960 --> 00:01:42,480 many of you have programmed an assembly language? 30 00:01:42,480 --> 00:01:44,320 And there were about 50 people in the room. 31 00:01:44,640 --> 00:01:47,240 Surprisingly, half of them raised their hands. 32 00:01:47,440 --> 00:01:50,760 I was like, wow, really? I thought I was the oldest one 33 00:01:50,760 --> 00:01:52,560 in the room, right? I did. 34 00:01:52,760 --> 00:01:55,280 And when I was in school, I programmed assembly. 35 00:01:55,840 --> 00:01:59,600 And, and then the second question was, how many of you 36 00:02:00,360 --> 00:02:04,400 still program an assembly? And unsurprisingly, no one 37 00:02:04,400 --> 00:02:08,360 raised their hands. And so nobody programs an 38 00:02:08,360 --> 00:02:12,120 assembly anymore because we came up with a higher level 39 00:02:12,520 --> 00:02:15,440 abstraction. It's there's still assembly 40 00:02:15,440 --> 00:02:18,200 language running, there's still program counters and instruction 41 00:02:18,200 --> 00:02:21,920 registers and memory, you know, registers and all of those types 42 00:02:21,920 --> 00:02:24,040 of things. Those, those physical components 43 00:02:24,040 --> 00:02:27,520 are still there, but we have a different abstraction. 44 00:02:27,520 --> 00:02:31,080 And so that's the through line is that we're always moving up 45 00:02:31,080 --> 00:02:35,000 the level of abstraction. But I'll tell you honestly that 46 00:02:35,600 --> 00:02:40,200 for the most part, the last, I would say certainly the time 47 00:02:40,200 --> 00:02:42,520 that I've been doing this, which is more than three decades, 48 00:02:43,320 --> 00:02:46,360 sure, we moved from assembly language and our languages got 49 00:02:46,360 --> 00:02:50,120 incrementally better and a little bit higher level. 50 00:02:50,120 --> 00:02:54,080 And in terms of abstraction, so C used to you have to had to do 51 00:02:54,080 --> 00:02:56,520 your own memory management. Then we had an abstraction that 52 00:02:56,520 --> 00:02:58,600 allowed you to not have to do your memory management. 53 00:02:58,600 --> 00:03:01,880 So you Java did did the memory management for you. 54 00:03:03,040 --> 00:03:05,960 And then where I work now, Temporal kind of raises that 55 00:03:05,960 --> 00:03:11,480 abstraction as well. But in the AI space, we are 56 00:03:11,560 --> 00:03:14,840 radically changing the programming model because now 57 00:03:14,840 --> 00:03:18,400 we're programming with natural language and eventually that 58 00:03:18,400 --> 00:03:21,240 turns into code that eventually gets all the way down to 59 00:03:21,240 --> 00:03:23,800 assembly language and is running on a processor. 60 00:03:25,080 --> 00:03:30,080 One of the interesting things though, is that in those those 61 00:03:30,080 --> 00:03:33,280 other abstractions where we had a formal programming language, 62 00:03:34,080 --> 00:03:36,480 we had ways. And I studied programming 63 00:03:36,480 --> 00:03:38,080 languages in grad school for a while. 64 00:03:38,080 --> 00:03:41,920 And to a large extent that's hardcore math because you're 65 00:03:41,920 --> 00:03:44,920 proving these programming languages and the compiler's 66 00:03:44,920 --> 00:03:48,440 correct and complete, so you can express everything you want to 67 00:03:48,440 --> 00:03:50,520 express. That's the completeness side. 68 00:03:50,520 --> 00:03:53,080 And then there's the correctness side of, well, when I write this 69 00:03:53,080 --> 00:03:55,400 line of code, it is going to translate into the right 70 00:03:55,400 --> 00:03:57,360 assembly language down under the covers. 71 00:03:58,560 --> 00:04:01,920 I think this big transformation that we have going into the AI 72 00:04:01,920 --> 00:04:04,000 space where we're now programming with the natural 73 00:04:04,000 --> 00:04:07,160 language, that's not a formal language, it's not 74 00:04:07,160 --> 00:04:09,440 deterministic. It's not an abstraction that is 75 00:04:09,440 --> 00:04:13,080 deterministic down to the next level of granularity, you know, 76 00:04:13,080 --> 00:04:16,560 the next level of abstraction. And so that changes everything. 77 00:04:16,760 --> 00:04:19,160 So we have to figure out what the programming model is for 78 00:04:19,160 --> 00:04:22,040 this. Well, I remember when we were 79 00:04:22,040 --> 00:04:26,360 first starting to do like text to SQL and I had a little bit of 80 00:04:26,360 --> 00:04:29,760 a gripe with it because it was like, but why would you want to 81 00:04:29,760 --> 00:04:32,560 do that be? It's so fuzzy. 82 00:04:32,560 --> 00:04:38,080 Language itself is really hard to interpret, and if I want 83 00:04:38,080 --> 00:04:41,440 something to happen, there's so many different words that I can 84 00:04:41,440 --> 00:04:46,000 use to express just a fairly simple idea. 85 00:04:47,400 --> 00:04:53,560 It feels like it's going to be easier if you just use the bound 86 00:04:53,960 --> 00:04:56,080 language that we've already created. 87 00:04:56,560 --> 00:05:00,880 But I was proven wildly wrong. That is not correct. 88 00:05:00,880 --> 00:05:04,240 I do not feel that same way now. I've changed my mind completely 89 00:05:04,240 --> 00:05:08,440 because anybody who has Vibe coded or just tried to use 90 00:05:08,440 --> 00:05:11,560 coding agents, they go, well, this is very good, right? 91 00:05:11,560 --> 00:05:15,480 So it's different now we don't have that. 92 00:05:15,520 --> 00:05:19,000 It is different, but and we also know about hallucinations, 93 00:05:19,000 --> 00:05:21,600 right? So it is different. 94 00:05:22,240 --> 00:05:24,280 You're right. It does a pretty good job 95 00:05:24,280 --> 00:05:26,240 interpreting that. The the models have gotten 96 00:05:26,240 --> 00:05:27,760 really good at interpreting that. 97 00:05:28,000 --> 00:05:30,640 And then of course, depending on the way that you use them, you 98 00:05:30,640 --> 00:05:33,400 use them iteratively and you converge on something and 99 00:05:33,400 --> 00:05:36,040 hopefully you're paying attention to what it's doing and 100 00:05:36,040 --> 00:05:37,840 that it isn't totally hallucinating something 101 00:05:37,840 --> 00:05:40,920 completely wacky. But we're seeing plenty of cases 102 00:05:40,920 --> 00:05:43,520 where it is. And so that's my concern as 103 00:05:43,520 --> 00:05:46,040 somebody who studied formal languages. 104 00:05:46,560 --> 00:05:48,520 English is not a formal language. 105 00:05:48,600 --> 00:05:51,720 And So what are we going to do as an industry to show that? 106 00:05:51,720 --> 00:05:54,440 And I think we have to find other ways of compensating for 107 00:05:54,440 --> 00:05:56,120 that. I don't think that we're going 108 00:05:56,120 --> 00:05:59,520 to get it to the point where it is as rigorous as the math that 109 00:05:59,520 --> 00:06:02,320 we did under the covers with programming languages before. 110 00:06:02,720 --> 00:06:04,400 So now we have to be. I guess that's the. 111 00:06:04,440 --> 00:06:07,240 Big question. I don't think so that the 112 00:06:07,240 --> 00:06:11,280 mathematician in me is like that, that that was the kind of 113 00:06:11,280 --> 00:06:15,760 initial like AI skeptic, like, Oh my gosh, like I am so used to 114 00:06:15,760 --> 00:06:18,520 deterministic code. I'm happy in that space. 115 00:06:18,800 --> 00:06:22,080 I'm happy with the fact that 1 + 1 is always equal to two, you 116 00:06:22,080 --> 00:06:25,360 know, that type of thing. And now it's probabilistic 1 + 1 117 00:06:25,360 --> 00:06:28,360 might be 3. And so I think what we're going 118 00:06:28,360 --> 00:06:30,800 to figure out is we're going to find figure out different ways 119 00:06:30,800 --> 00:06:35,640 of compensating for it. And so we will, we have to build 120 00:06:35,640 --> 00:06:38,240 safety Nets. So this is the way things are 121 00:06:38,240 --> 00:06:40,000 working. There is a certain level of non 122 00:06:40,000 --> 00:06:43,040 determinism, so how do you deal with that nondeterminism? 123 00:06:43,040 --> 00:06:46,560 How, how what, what type of safety net do you have when the 124 00:06:46,560 --> 00:06:49,440 translation from this higher level abstraction down to the 125 00:06:49,440 --> 00:06:53,800 concrete thing goes haywire? How do you compensate for that? 126 00:06:53,920 --> 00:06:58,400 Well, in one way you could look at the idea of durable execution 127 00:06:58,400 --> 00:07:00,000 as one of those safety Nets, right? 128 00:07:00,680 --> 00:07:03,680 Absolutely. And so it's and that's why so, 129 00:07:03,840 --> 00:07:07,040 so durable execution. As you know, durable execution 130 00:07:07,040 --> 00:07:09,080 is pre Gen. AI craze. 131 00:07:09,400 --> 00:07:14,480 So the company that I work for Temporal Temporal, the open 132 00:07:14,480 --> 00:07:17,920 source project has been around for 6 1/2 years or something 133 00:07:17,920 --> 00:07:20,640 like that. And it definitely represents 134 00:07:20,640 --> 00:07:24,440 this higher level abstraction. Now it still falls into that 135 00:07:24,440 --> 00:07:27,360 category until you start using it in the AI space. 136 00:07:27,560 --> 00:07:30,640 It falls in that category of it's deterministic. 137 00:07:30,920 --> 00:07:34,360 It is we we know exactly how this is going to map from the 138 00:07:34,360 --> 00:07:36,440 way that you write and the programming model. 139 00:07:36,440 --> 00:07:39,760 So just to very quickly describe the programming model, the 140 00:07:39,760 --> 00:07:45,000 programming model there is that as developers for the last 30, 141 00:07:45,000 --> 00:07:48,320 more than 30 years, remember we talked about the physical 142 00:07:48,320 --> 00:07:52,520 processor before, right? Developers in the last, up until 143 00:07:52,520 --> 00:07:55,840 very recently have had to understand not the physical 144 00:07:55,840 --> 00:07:58,680 processor, but they had to understand the notion of a 145 00:07:58,680 --> 00:08:02,640 process, Yeah, like my code is running in a process. 146 00:08:02,960 --> 00:08:05,960 As we went into the cloud, in cloud native, we had multiple 147 00:08:05,960 --> 00:08:08,840 processes. So we had to start figuring out 148 00:08:09,120 --> 00:08:12,120 how multiple processes would communicate and what happens 149 00:08:12,120 --> 00:08:14,680 when the network goes down and all of those types of things. 150 00:08:14,920 --> 00:08:18,040 But we as developers had to think about those infrastructure 151 00:08:18,040 --> 00:08:20,640 abstractions. I had to think about a process. 152 00:08:21,040 --> 00:08:22,520 I had to think about the network. 153 00:08:23,000 --> 00:08:26,120 And what Temporal does is it moves that level of abstraction 154 00:08:26,120 --> 00:08:29,640 higher and it says, no, you as a developer, you get to think 155 00:08:29,640 --> 00:08:31,920 about a process as a logical process. 156 00:08:32,440 --> 00:08:34,760 We'll map it down to physical processes for you. 157 00:08:35,400 --> 00:08:37,240 That's what durable execution does. 158 00:08:37,240 --> 00:08:40,440 And So what it says is you get to think about the logical 159 00:08:40,440 --> 00:08:43,520 process. We will ensure that we give you 160 00:08:43,679 --> 00:08:47,160 durability underneath that abstraction so that as the 161 00:08:47,160 --> 00:08:50,400 infrastructure is doing all sorts of chaotic weird things, 162 00:08:50,600 --> 00:08:53,080 we will compensate for all those weird things. 163 00:08:53,240 --> 00:08:55,800 You just get to think about this logical process. 164 00:08:56,000 --> 00:08:58,360 That's fundamentally what durable execution is. 165 00:08:58,560 --> 00:09:02,160 So it is that level. And now we're layering AI on top 166 00:09:02,160 --> 00:09:05,160 of it. So it is kind of a deterministic 167 00:09:05,160 --> 00:09:09,520 tier that we can leverage your right as kind of a safety part 168 00:09:09,520 --> 00:09:12,560 of the safety net that's going to allow us to compensate for 169 00:09:12,560 --> 00:09:15,920 that. I'm sure you've heard a lot of 170 00:09:15,920 --> 00:09:20,160 the like the chaos monkey or chaos engineering this in a way 171 00:09:20,160 --> 00:09:24,440 is that, but having folks not even worry about chaos 172 00:09:24,440 --> 00:09:27,320 engineering because you're going to be doing the chaos on your 173 00:09:27,320 --> 00:09:29,840 side and make we. Compensate for the chaos? 174 00:09:29,840 --> 00:09:32,200 Yeah, exactly. I didn't think about that 175 00:09:32,200 --> 00:09:34,400 before, but it makes a lot of sense. 176 00:09:34,400 --> 00:09:38,000 Yeah, it's really interesting. So I spent a lot of time, I was 177 00:09:38,000 --> 00:09:40,720 around when we moved over into container architectures. 178 00:09:40,720 --> 00:09:43,640 So I worked on Cloud Foundry, and Cloud Foundry was the 179 00:09:43,640 --> 00:09:47,440 technology that was self healing before Kubernetes came along. 180 00:09:48,560 --> 00:09:50,400 And it had containers under the covers. 181 00:09:50,400 --> 00:09:53,320 And so you could deploy multiple instances of an app. 182 00:09:53,320 --> 00:09:56,000 And if the container went away, we just brought it back. 183 00:09:56,800 --> 00:10:00,600 And I worked with sometimes users and customers who said, 184 00:10:00,920 --> 00:10:05,240 yeah, my developers would come in and say, I saw a dashboard 185 00:10:05,240 --> 00:10:06,760 that said the container went away. 186 00:10:06,760 --> 00:10:08,320 What are we going to do about that? 187 00:10:08,800 --> 00:10:11,680 And the people who understood that technology were like, does 188 00:10:11,680 --> 00:10:13,520 it matter? Is your app still running? 189 00:10:13,840 --> 00:10:16,480 And they're like, yeah, I guess it is. 190 00:10:16,760 --> 00:10:19,280 So maybe it doesn't matter anymore that the container went 191 00:10:19,280 --> 00:10:21,080 away. It's that same concept. 192 00:10:21,280 --> 00:10:23,520 OK. So then going back to the 193 00:10:23,560 --> 00:10:28,880 original idea of, hey, durable execution is a way to make 194 00:10:30,120 --> 00:10:34,280 almost make up for the fact that we're now communicating with our 195 00:10:34,360 --> 00:10:38,240 machines in natural language. There feels like there's other 196 00:10:38,240 --> 00:10:40,560 ways that we're making up for it too. 197 00:10:40,960 --> 00:10:47,680 I guess one way is MCP and then other ways are I I'm sure like 198 00:10:48,200 --> 00:10:50,560 if I really think about it right now, there's, there's probably 199 00:10:50,560 --> 00:10:56,240 plenty of ways that guardrails putting those into place, other 200 00:10:56,240 --> 00:10:59,160 ones that maybe I'm not able to think about. 201 00:10:59,520 --> 00:11:02,040 Yeah, I mean, I'd love that you bring up MCP because when we 202 00:11:02,040 --> 00:11:04,480 start thinking about the way that applications are being 203 00:11:04,480 --> 00:11:07,880 written, these AI applications, we've got the agents, right? 204 00:11:07,880 --> 00:11:09,400 They're running their agentic loop. 205 00:11:09,960 --> 00:11:12,720 And so part of the programming model there is we've got these 206 00:11:12,720 --> 00:11:15,520 agents running an agentic loop and they're going to use tools. 207 00:11:15,520 --> 00:11:18,880 Tools is one of the first class abstractions in the AI space, 208 00:11:18,880 --> 00:11:20,640 right. Even LLMS, even if you're not 209 00:11:20,640 --> 00:11:24,920 running an agent and LLM has tools as an abstraction, you, 210 00:11:25,080 --> 00:11:27,760 you also pulled, you know, called out guardrails, those 211 00:11:27,760 --> 00:11:31,600 types of things. And so now we've got these 212 00:11:31,600 --> 00:11:35,160 tools, there's an abstraction and durable execution plays 213 00:11:35,160 --> 00:11:39,040 across that entire gambit. And so for example, if you have 214 00:11:39,040 --> 00:11:42,200 a long running agent that might be running for 5 minutes or 10 215 00:11:42,200 --> 00:11:46,240 minutes or five hours or five days, you want some durability 216 00:11:46,240 --> 00:11:48,000 around that. Remember we talked about how 217 00:11:48,000 --> 00:11:50,840 durable execution says, well, you could think about a logical 218 00:11:50,840 --> 00:11:52,720 process. So in that case, my logical 219 00:11:52,720 --> 00:11:56,480 process is my agent and the fact that it's going to run for five 220 00:11:56,480 --> 00:12:00,080 days, it's a logical process. I don't have to worry about what 221 00:12:00,080 --> 00:12:02,880 happens with the infrastructure over those five days because 222 00:12:02,880 --> 00:12:07,880 temporal will compensate for it. Well, that same durability is 223 00:12:07,960 --> 00:12:10,240 valuable when you think about the tools. 224 00:12:10,480 --> 00:12:12,840 So are the tools going to be long running? 225 00:12:12,840 --> 00:12:15,360 And increasingly they are, because increasingly tools are 226 00:12:15,360 --> 00:12:17,960 themselves agents, so they're going to be long running. 227 00:12:18,160 --> 00:12:21,760 So we want to apply durability in the agents, we want to apply 228 00:12:21,760 --> 00:12:26,160 durability in MCP, which is why we refer to it as the concept as 229 00:12:26,160 --> 00:12:28,760 durable MCP. Yeah, let's talk more about 230 00:12:28,760 --> 00:12:32,080 durable MCP because you mentioned that it's now almost 231 00:12:32,640 --> 00:12:38,680 becoming first class citizen. It is so prior to November. 232 00:12:38,760 --> 00:12:42,240 So the first kind of early versions of the MCP spec didn't 233 00:12:42,240 --> 00:12:45,360 say anything about durability and in fact they were mostly 234 00:12:45,360 --> 00:12:48,400 request response. So their whole and that's pretty 235 00:12:48,400 --> 00:12:50,680 natural. Like I grew up in like the micro 236 00:12:50,680 --> 00:12:53,800 services era as well. And initially our micro services 237 00:12:53,800 --> 00:12:56,560 were all request response. And I like to say that the 238 00:12:56,560 --> 00:12:59,720 poster children of micro services in that era was Netflix 239 00:13:00,120 --> 00:13:03,680 and they built a whole bunch of services around the request 240 00:13:03,680 --> 00:13:07,400 response protocol. So they had things like retries, 241 00:13:07,400 --> 00:13:09,720 retry libraries and service discovery. 242 00:13:09,720 --> 00:13:12,520 They had circuit Breakers to keep you from D Dosing things. 243 00:13:12,720 --> 00:13:15,560 So it's completely natural to start with request response 244 00:13:15,560 --> 00:13:18,800 because it's kind of a natural way of us programming and like 245 00:13:19,120 --> 00:13:20,920 our mental model around these things. 246 00:13:21,320 --> 00:13:27,120 But in November, they released something called The Task, which 247 00:13:27,440 --> 00:13:31,520 doesn't change. It's not a new concept. 248 00:13:31,520 --> 00:13:34,960 It's still the core thing with MCP is of course, you've got 249 00:13:35,400 --> 00:13:38,400 resources and prompts, but those aren't used a whole lot. 250 00:13:38,400 --> 00:13:40,840 It's mainly the tools, right? That's the main thing that's 251 00:13:40,840 --> 00:13:45,480 used out of Temple. I'm sorry, out of MCP tasks 252 00:13:45,480 --> 00:13:49,200 don't add a new type of it doesn't add a new resource. 253 00:13:49,200 --> 00:13:55,520 It says a tool can be request response or it can be async. 254 00:13:55,920 --> 00:13:59,400 So it can be long running. You fire off a tool, you make a 255 00:13:59,400 --> 00:14:02,520 tool call and you don't expect a response right away. 256 00:14:02,640 --> 00:14:06,480 It's not request response, you just you're waiting and you're 257 00:14:06,480 --> 00:14:08,400 maybe never. Maybe it's fire or forget. 258 00:14:09,200 --> 00:14:13,960 And the cool thing about SO on the one hand, they could have 259 00:14:13,960 --> 00:14:18,040 just defined that protocol and said instead of doing a request 260 00:14:18,320 --> 00:14:21,760 and getting back a result, you do a request, you get back a 261 00:14:21,760 --> 00:14:24,200 handle. Now you can interact with that 262 00:14:24,200 --> 00:14:28,440 handle by asking for status, getting a result. 263 00:14:28,440 --> 00:14:31,560 When the when you get back a status that says, OK, you're 264 00:14:31,560 --> 00:14:33,400 done. Now you can get back a result. 265 00:14:34,040 --> 00:14:38,040 That's kind of OK, that's great. But the first line in the 266 00:14:38,040 --> 00:14:42,480 specification says tasks are durable, which is wicked cool 267 00:14:42,480 --> 00:14:46,680 because it's this recognition that tools run for a long time 268 00:14:46,720 --> 00:14:49,640 and that if something goes wrong, you don't want to have to 269 00:14:49,640 --> 00:14:51,800 start all over again you. Don't want to send the request 270 00:14:51,800 --> 00:14:53,320 again. You don't want to have to start 271 00:14:53,440 --> 00:14:56,920 exactly send the request again. Imagine that you've burned 272 00:14:57,000 --> 00:15:01,280 through millions or billions of tokens and then something goes 273 00:15:01,280 --> 00:15:04,240 wrong when you're 90% complete. You don't want to have to start 274 00:15:04,240 --> 00:15:07,800 that over again. And so the tasks, them being 275 00:15:07,800 --> 00:15:10,880 durable, the requirement is that they're durable. 276 00:15:12,080 --> 00:15:15,200 That change, that's the thing that changes a lot. 277 00:15:15,680 --> 00:15:18,960 Because you can guarantee that it's going to come back. 278 00:15:19,680 --> 00:15:23,000 Yeah, exactly, Exactly. So by being durable, what that 279 00:15:23,000 --> 00:15:27,440 means is that the client that just it connected with the MCP 280 00:15:27,440 --> 00:15:30,520 server to invoke that tool, the client could go away, the 281 00:15:30,520 --> 00:15:34,560 network could go away, and in fact the tool itself could go 282 00:15:34,560 --> 00:15:35,800 down. And remember, we were talking 283 00:15:35,800 --> 00:15:39,080 about durable execution says think of your process as 284 00:15:39,080 --> 00:15:41,560 logical. It's always once you start it, 285 00:15:41,800 --> 00:15:43,880 it lives. It just lives. 286 00:15:44,120 --> 00:15:47,080 Infrastructure can come and go. All sorts of things can happen. 287 00:15:47,360 --> 00:15:51,560 So the MCP server itself can go down, but the specification says 288 00:15:52,320 --> 00:15:54,280 tasks are required to be durable. 289 00:15:54,280 --> 00:15:57,360 So that means that not everything is lost. 290 00:15:57,800 --> 00:16:01,560 So you keep, you mentioned before these long running agents 291 00:16:01,640 --> 00:16:04,760 and you're also talking about tasks. 292 00:16:04,760 --> 00:16:08,600 It feels like that is very much long running Tye of. 293 00:16:09,040 --> 00:16:13,640 Exactly. What are the what are being done 294 00:16:13,640 --> 00:16:17,200 with these long running agents? Like what are you seeing out 295 00:16:17,200 --> 00:16:20,440 there that needs such long running agents? 296 00:16:20,440 --> 00:16:23,280 Yeah. So there's quite a number of 297 00:16:23,280 --> 00:16:26,000 different use cases. There's some of this same batch 298 00:16:26,000 --> 00:16:28,360 type of use cases that we've done all along. 299 00:16:28,360 --> 00:16:31,720 So you know, tools don't have to be themselves be AI 300 00:16:31,720 --> 00:16:33,560 applications. It could be. 301 00:16:33,800 --> 00:16:35,960 I'm going to go off and do an analysis. 302 00:16:35,960 --> 00:16:40,600 I was in a session earlier today that was given by a couple of 303 00:16:40,600 --> 00:16:44,120 folks in Amazon and they were with Prime Video and they had a 304 00:16:44,120 --> 00:16:46,760 just a fantastic use case that they talked about where they 305 00:16:46,760 --> 00:16:51,400 said it used to be that we did analysis on the streaming, the 306 00:16:51,400 --> 00:16:55,560 quality of the streaming only for the premier events, only the 307 00:16:55,560 --> 00:16:59,600 for the events where there were millions or 10s of millions of 308 00:16:59,600 --> 00:17:04,200 viewers because humans were involved in that analysis. 309 00:17:04,280 --> 00:17:09,000 Well, they've now created agents that can do that analysis. 310 00:17:09,000 --> 00:17:11,640 And so they're, they're not constrained by human, human 311 00:17:11,640 --> 00:17:14,319 bandwidth anymore. So the created agents, and so 312 00:17:14,319 --> 00:17:17,920 now they're doing that same kind of streaming analysis on tiny 313 00:17:17,920 --> 00:17:20,119 little niche things. All the videos. 314 00:17:20,160 --> 00:17:23,280 But that's all long running because what they're doing is 315 00:17:23,280 --> 00:17:25,079 they're crunching through a lot of data. 316 00:17:25,079 --> 00:17:27,400 So a lot of. So you were asking about use 317 00:17:27,400 --> 00:17:30,320 cases, data analytics, data analysis. 318 00:17:30,320 --> 00:17:33,120 Now in that particular case, they are using an agent to do 319 00:17:33,120 --> 00:17:36,280 that, but there's a lot of use cases even that are pre agent 320 00:17:37,360 --> 00:17:41,080 that are just long running. Another thing that makes things 321 00:17:41,080 --> 00:17:44,600 long running is as soon as you have some type of human in the 322 00:17:44,600 --> 00:17:47,840 loop, humans are bottlenecks, right? 323 00:17:48,080 --> 00:17:52,200 So you could be part of the way through processing some tool and 324 00:17:52,200 --> 00:17:56,440 now all of a sudden the tool, the MCP server, the tool says, 325 00:17:56,560 --> 00:18:01,160 oh, I need some human input. And now you've got to wait for 326 00:18:01,160 --> 00:18:05,000 the human to come back. Well, that might be days and but 327 00:18:05,000 --> 00:18:08,640 the process, let's say it's 50% of the way through and now it's 328 00:18:08,640 --> 00:18:11,240 waiting for the human. The, you want that process to be 329 00:18:11,240 --> 00:18:15,520 durable and so that when the human finally does and you don't 330 00:18:15,520 --> 00:18:17,920 not only want it to be durable, you want it to be efficient. 331 00:18:18,000 --> 00:18:21,040 You don't want to like hold that in memory for five days while 332 00:18:21,040 --> 00:18:24,640 you're waiting for the human. So you want to make sure that 333 00:18:24,640 --> 00:18:27,680 your infrastructure is being used efficiently as well and 334 00:18:27,880 --> 00:18:31,080 that that's not a requirement of durability, but it is a 335 00:18:31,080 --> 00:18:34,040 requirement of a really good durable execution platform. 336 00:18:34,040 --> 00:18:36,720 Yeah, and just resource management. 337 00:18:36,880 --> 00:18:40,360 Exactly. So can we go back to this 338 00:18:40,360 --> 00:18:45,000 Netflix or sorry, the Amazon Prime example, Amazon's not 339 00:18:45,000 --> 00:18:48,240 going to be happy. I mean same same streaming 340 00:18:48,240 --> 00:18:49,960 example. Streaming example. 341 00:18:51,360 --> 00:18:55,640 It's long running because the whole time that they are 342 00:18:55,640 --> 00:18:59,240 streaming it, they're, I assume they're constantly streaming it 343 00:19:00,240 --> 00:19:02,840 and so they're just taking snippets of time. 344 00:19:03,960 --> 00:19:06,640 Yeah, I I don't actually know the details of the 345 00:19:06,640 --> 00:19:09,480 implementation. I think it could be a continual 346 00:19:09,480 --> 00:19:12,280 process, which I think is a super interesting use case, 347 00:19:12,560 --> 00:19:17,200 which is just it that it's like an ambient agent. 348 00:19:17,280 --> 00:19:20,400 It's always watching and it's always responding. 349 00:19:20,560 --> 00:19:23,200 I don't know for sure whether that's what they were referring 350 00:19:23,200 --> 00:19:27,040 to or whether they were saying we're always collecting data for 351 00:19:27,040 --> 00:19:29,840 that from the number of times that it has streamed and then 352 00:19:29,840 --> 00:19:33,200 they do it in a batch situation. I don't know for sure. 353 00:19:33,640 --> 00:19:36,040 We were asking about use cases for tasks. 354 00:19:36,040 --> 00:19:39,520 One of the interesting things about the MCP tasks is that it 355 00:19:39,520 --> 00:19:44,360 is largely about batch, so it is not. 356 00:19:44,600 --> 00:19:48,640 It does support a human in the loop, but the human in the loop 357 00:19:49,040 --> 00:19:52,440 is triggered by the MCP tool itself. 358 00:19:53,040 --> 00:19:56,760 It is not one of those things where the MCP tool is doing its 359 00:19:56,760 --> 00:19:59,800 thing. It gives you some interim result 360 00:19:59,800 --> 00:20:03,680 and then the external agent is making the decision on the human 361 00:20:03,680 --> 00:20:07,640 in the loop and progressing it. It is pretty much a, hey, we've 362 00:20:07,640 --> 00:20:10,640 defined this long running process again, it could be an 363 00:20:10,640 --> 00:20:13,920 agent, but now it's the tool that's in charge. 364 00:20:14,560 --> 00:20:18,560 It the the tool is, is the the main player there, which 365 00:20:18,560 --> 00:20:22,000 surprises me because I come from a world where long running 366 00:20:22,000 --> 00:20:25,720 processes can be interacted with from the outside. 367 00:20:25,720 --> 00:20:29,440 Yeah, but there is no. Without getting into all of the 368 00:20:29,440 --> 00:20:33,520 details of the protocol, the the task protocol allows you to 369 00:20:33,520 --> 00:20:36,280 create a task. It allows you to get status on 370 00:20:36,280 --> 00:20:39,000 the task, it allows you to cancel the task, and it allows 371 00:20:39,000 --> 00:20:42,000 you to get the result. It does not allow you to 372 00:20:42,160 --> 00:20:46,120 essentially put into there like you can't from the outside say, 373 00:20:46,280 --> 00:20:48,120 hey, here's some more information. 374 00:20:49,520 --> 00:20:54,640 The tool can say, hey, I need more information and it'll come 375 00:20:54,640 --> 00:20:58,320 out to the client and say, hey, I need this more information, 376 00:20:58,320 --> 00:21:01,360 but the client can't offer additional information. 377 00:21:01,760 --> 00:21:04,640 Oi was actually quite surprised about that because I thought, 378 00:21:04,640 --> 00:21:06,240 oh, tasks. I thought they were going to be 379 00:21:06,240 --> 00:21:10,840 like, we do that in temporal, but it's actually, it's a little 380 00:21:10,840 --> 00:21:13,560 bit more constrained. There's lots of use cases where 381 00:21:13,720 --> 00:21:16,840 you send it over the tool and now the tool is in control like 382 00:21:16,840 --> 00:21:19,920 these batch processes that we talked about, but it's it 383 00:21:19,960 --> 00:21:22,000 doesn't have a protocol. These are some of the things 384 00:21:22,000 --> 00:21:24,320 that I'm definitely going to be trying to influence. 385 00:21:24,320 --> 00:21:27,000 The protocol's only experimental right now, so there's an 386 00:21:27,040 --> 00:21:29,200 opportunity to influence that. I. 387 00:21:29,200 --> 00:21:34,560 Would want the ability, yeah. Yeah, there are ways of doing 388 00:21:34,560 --> 00:21:38,600 it, but it it's a little bit odd you have to define other tools 389 00:21:38,600 --> 00:21:42,960 with the same server and that might be a best practice. 390 00:21:42,960 --> 00:21:44,720 I haven't quite gotten that far yet. 391 00:21:44,720 --> 00:21:47,520 We'll see. Can you break down? 392 00:21:47,520 --> 00:21:50,640 I'm still trying to wrap my head around the tasks and the 393 00:21:50,640 --> 00:21:53,880 different use cases, so different batch processes that 394 00:21:53,880 --> 00:21:56,560 you've seen being done with tasks. 395 00:21:56,800 --> 00:21:58,000 Yes. So there might be. 396 00:21:58,000 --> 00:22:03,880 For example, it could be like in invoice processing example, 397 00:22:03,880 --> 00:22:06,720 which is exactly what I did it in my talk, was invoice 398 00:22:06,720 --> 00:22:08,440 processing. So you're going to submit an 399 00:22:08,440 --> 00:22:10,760 invoice. You've got a tool that is an 400 00:22:10,760 --> 00:22:13,080 invoice processor for the most part. 401 00:22:13,080 --> 00:22:15,400 You submit the invoice and what does it need to do? 402 00:22:15,400 --> 00:22:19,320 It needs to do some validation. Then maybe it needs to ask the 403 00:22:19,320 --> 00:22:22,320 human for approval. You know, you've got some policy 404 00:22:22,320 --> 00:22:26,280 there that says anything under 500 bucks, just go ahead and 405 00:22:26,280 --> 00:22:28,880 process it. Anything above that, or if 406 00:22:28,880 --> 00:22:31,920 there's some other policy, some weirdness about the invoice, 407 00:22:32,240 --> 00:22:33,800 then you have to have human in the loop. 408 00:22:34,080 --> 00:22:37,440 The tool would be the thing that decides that's where the policy 409 00:22:37,440 --> 00:22:39,160 is running. The tool can come out and say, 410 00:22:39,160 --> 00:22:44,200 hey client, I need approval. And then you could be paying 411 00:22:44,520 --> 00:22:47,280 parts of that and maybe the entire invoice doesn't need to 412 00:22:47,280 --> 00:22:49,440 be paid at once. Maybe you've got a complex 413 00:22:49,440 --> 00:22:52,400 invoice where you say I'm going to, I'm going to pay this in 414 00:22:52,400 --> 00:22:55,680 increments. So that is a long running tool 415 00:22:55,680 --> 00:22:57,680 where let's say you're going to pay it quarterly. 416 00:22:58,560 --> 00:23:02,240 You can model that as a single tool, a single invoice that 417 00:23:02,240 --> 00:23:05,440 you're processing. You pay this quarter's and then 418 00:23:05,440 --> 00:23:08,680 the thing goes to sleep and next quarter it wakes up and it pays 419 00:23:08,680 --> 00:23:10,000 the next installment. Wow. 420 00:23:10,960 --> 00:23:14,920 So that is what I mean by a long running thing that you can 421 00:23:14,920 --> 00:23:17,840 imagine an agent saying, hey, go ahead and process this batch of 422 00:23:17,840 --> 00:23:21,960 invoices for me and that's the the process that's going on in 423 00:23:21,960 --> 00:23:23,760 the background. And that's where you talk about 424 00:23:23,760 --> 00:23:26,480 the resource management is important because you don't want 425 00:23:26,480 --> 00:23:29,360 it for a whole month to be there thinking about that. 426 00:23:29,360 --> 00:23:31,200 You want it to go to sleep. Exactly. 427 00:23:32,600 --> 00:23:36,920 Exactly. And so, yeah, scale to 0 is 428 00:23:36,920 --> 00:23:39,360 important here on these tasks. That's right. 429 00:23:39,880 --> 00:23:46,760 And so and then you're thinking, wow, wouldn't it be great if I 430 00:23:46,760 --> 00:23:50,440 could add more invoices to that while it's happening instead of 431 00:23:50,440 --> 00:23:54,960 having to kick off a new task with new extra invoices? 432 00:23:55,800 --> 00:23:57,240 Is that kind of the idea with the I? 433 00:23:57,800 --> 00:23:59,840 Think there's a number of different ways to do it. 434 00:23:59,840 --> 00:24:03,040 The way that I did it very, very naively in the beginning is that 435 00:24:03,040 --> 00:24:05,800 each task was, each invoice was its own task. 436 00:24:07,240 --> 00:24:10,680 You can also imagine batching those things and saying actually 437 00:24:10,680 --> 00:24:15,560 a batch of invoices is a task. And within that you can break 438 00:24:15,560 --> 00:24:20,200 it, break it down into, you know, subtasks or because each 439 00:24:20,200 --> 00:24:23,560 one might have its own schedule. So there might be an invoice 440 00:24:23,560 --> 00:24:26,560 that is paid quarterly and another one that's paid weekly 441 00:24:26,560 --> 00:24:29,560 and those types of things. And so going back to the 442 00:24:29,560 --> 00:24:32,360 durability conversation that we've had been having all along, 443 00:24:32,480 --> 00:24:34,560 you're right, it needs to scale to 0. 444 00:24:35,640 --> 00:24:38,040 And remember I said the infrastructure can go away. 445 00:24:38,280 --> 00:24:42,760 So where does that timer live? The timer has to survive that 446 00:24:42,760 --> 00:24:44,760 that infrastructure failure as well. 447 00:24:45,160 --> 00:24:47,520 And so we like to call those things durable timers. 448 00:24:47,520 --> 00:24:50,760 And so we have this notion of like timers need to be durable, 449 00:24:50,880 --> 00:24:53,920 human in the loop needs to be durable, the compute needs to be 450 00:24:53,920 --> 00:24:57,840 durable, all of those things. So durability isn't just retries 451 00:24:57,840 --> 00:25:01,040 or state management. It's a whole complex set of 452 00:25:01,040 --> 00:25:02,640 things. And that's what I mean by 453 00:25:02,640 --> 00:25:05,200 programming language, right? It's like, here's this new 454 00:25:05,200 --> 00:25:08,200 abstract fraction of durability that you can alley across a 455 00:25:08,200 --> 00:25:11,400 bunch of different programming elements, and as soon as you 456 00:25:11,400 --> 00:25:14,640 have the notion of a durable timer, then you no longer have 457 00:25:14,640 --> 00:25:17,240 to program that. Yeah, so. 458 00:25:17,640 --> 00:25:19,360 Yeah, you. You have to keep the time 459 00:25:19,360 --> 00:25:22,720 though, because otherwise when is it going to know when to wake 460 00:25:22,720 --> 00:25:25,840 up? That's what it, that's what, for 461 00:25:25,840 --> 00:25:29,280 example, Temporal has durable timers and they live in the 462 00:25:29,280 --> 00:25:32,000 Temporal server so it knows when to wake up. 463 00:25:32,000 --> 00:25:35,160 Your process can go away. That's what allows us to be 464 00:25:35,400 --> 00:25:38,680 efficient with that is the processes go away, the timer 465 00:25:38,680 --> 00:25:43,640 fires, and now a worker process that's always checking to see is 466 00:25:43,640 --> 00:25:47,480 there anything new is like, oh, I see this timer fired. 467 00:25:47,560 --> 00:25:50,480 Oh, that timer corresponds to this thing that's asleep over 468 00:25:50,480 --> 00:25:51,600 here. I'll wake it up now. 469 00:25:51,640 --> 00:25:54,360 Yeah. And so I'm starting to get a 470 00:25:54,400 --> 00:25:56,560 better picture. And in my head, I'm kind of 471 00:25:56,560 --> 00:26:01,280 envisioning it as like different things happening that are 472 00:26:01,280 --> 00:26:04,680 creating chain reactions. And you have to make sure that 473 00:26:04,960 --> 00:26:09,320 each one of those things is working because if you have some 474 00:26:09,320 --> 00:26:12,800 kind of a problem, then the domino is not going to go to the 475 00:26:12,800 --> 00:26:17,840 next domino. And so everything has to be 476 00:26:17,840 --> 00:26:19,760 durable. Yes, that's that's why I'm 477 00:26:19,760 --> 00:26:22,720 understanding the the idea of, OK, durable execution doesn't 478 00:26:22,720 --> 00:26:26,280 mean just durable execution. It means durable timers, durable 479 00:26:26,280 --> 00:26:28,360 compute all of that. Exactly. 480 00:26:28,520 --> 00:26:29,800 Exactly. Yep. 481 00:26:30,480 --> 00:26:34,160 OK. So, so that's tasks and a little 482 00:26:34,160 --> 00:26:39,840 bit of like MCP being more durable and bringing that to its 483 00:26:40,760 --> 00:26:45,120 own DNA in a way. Hopefully we see more of it. 484 00:26:45,120 --> 00:26:47,120 And so that most things are durable. 485 00:26:47,240 --> 00:26:50,800 Is there ever times where you wouldn't necessarily need like 486 00:26:50,800 --> 00:26:53,760 durable execution is overkill? Oh definitely. 487 00:26:54,520 --> 00:26:58,160 I think that there are some places where the cost of 488 00:26:58,160 --> 00:27:03,400 recomputing something is so small that you don't necessarily 489 00:27:03,400 --> 00:27:06,520 need to to take on that burden because what we're essentially 490 00:27:06,520 --> 00:27:09,240 doing is we're pushing some concerns that used to be 491 00:27:09,240 --> 00:27:11,800 application concerns down into the infrastructure. 492 00:27:11,800 --> 00:27:13,280 That's what we're effectively doing. 493 00:27:13,520 --> 00:27:15,400 Of course, that means your infrastructure is a little bit 494 00:27:15,400 --> 00:27:19,080 more complex. So like I said, short running 495 00:27:19,240 --> 00:27:23,560 things where the the cost to recompute that over again is, 496 00:27:23,600 --> 00:27:27,320 is, you know, very, very small. Other things are things like 497 00:27:27,320 --> 00:27:31,280 embedded systems. So if you aren't necessarily 498 00:27:31,280 --> 00:27:35,120 running a distributed system, so you're not deploying your 499 00:27:35,120 --> 00:27:38,280 application out into the cloud and have multiple instances 500 00:27:39,080 --> 00:27:44,360 embedded on like let's say a car for example, probably not needed 501 00:27:44,360 --> 00:27:47,560 there in part because everything's different there. 502 00:27:47,560 --> 00:27:51,280 You're doing embedded systems, you're probably programming in C 503 00:27:51,280 --> 00:27:53,160 and C++ and those types of things. 504 00:27:53,160 --> 00:27:55,320 You're still doing your own memory management because things 505 00:27:55,320 --> 00:27:59,080 need to happen really quickly. You're, you're operating in a 506 00:27:59,080 --> 00:28:01,920 level where you're still operating at that low, lower 507 00:28:01,920 --> 00:28:04,880 level of abstraction. So there's, there's a number of 508 00:28:04,880 --> 00:28:07,840 those things. But one of the things with 509 00:28:07,840 --> 00:28:11,080 durable execution is we've seen this with some of our, you know, 510 00:28:11,080 --> 00:28:16,080 the early adopters of durable execution is that they come in 511 00:28:16,080 --> 00:28:17,960 and they adopt it for a use case. 512 00:28:17,960 --> 00:28:21,200 And once they understand this new programming model, all of a 513 00:28:21,200 --> 00:28:23,680 sudden they're like, they can't. They can't. 514 00:28:23,840 --> 00:28:25,880 Unsee it they. Can't Unsee it now. 515 00:28:25,880 --> 00:28:29,080 They want everything to be built that way and we hear stories. 516 00:28:29,800 --> 00:28:33,640 One of one of our most vocal champions is from Yum Brands, 517 00:28:33,960 --> 00:28:37,800 Matt McDowell, and he tells this great story of product manager 518 00:28:37,800 --> 00:28:39,960 came to them. They had been talking about a 519 00:28:39,960 --> 00:28:44,880 feature for a while and they had estimated that it would take 520 00:28:45,200 --> 00:28:49,560 weeks or months to implement. And the reason that it was going 521 00:28:49,560 --> 00:28:52,360 to take that long was because it was this highly distributed 522 00:28:52,440 --> 00:28:56,040 application where like we talked about earlier, the the 523 00:28:56,040 --> 00:28:59,200 developers were going to have to worry about all these like, OK, 524 00:28:59,360 --> 00:29:01,800 I've got this process over here, this process over here that 525 00:29:01,800 --> 00:29:04,560 might go away. So I have to make sure to store 526 00:29:04,560 --> 00:29:08,200 some state over here and I need a message bus over here. 527 00:29:08,480 --> 00:29:12,880 And it was just a complicated topology and a complicated like 528 00:29:12,880 --> 00:29:16,600 workflow that they needed to wire together themselves, little 529 00:29:16,600 --> 00:29:18,880 bit of a Rube Goldberg machine that they had to build. 530 00:29:18,880 --> 00:29:22,120 And Rube Goldberg machines metaphorically are really hard. 531 00:29:22,120 --> 00:29:25,480 They're hard to operate. And when they rethought about it 532 00:29:25,480 --> 00:29:27,800 in this model where they're like, well, if I think about it 533 00:29:27,800 --> 00:29:30,440 in terms of a process that doesn't go away, something else 534 00:29:30,440 --> 00:29:33,520 is taking care of that resilience they were able to 535 00:29:33,520 --> 00:29:36,960 implement in a couple of days. Like that's the power of a 536 00:29:36,960 --> 00:29:40,920 different programming model. Like we couldn't build the, we 537 00:29:40,920 --> 00:29:43,120 couldn't build AI systems and assembly anymore. 538 00:29:43,120 --> 00:29:45,680 We just couldn't do it. So this developer couldn't Unsee 539 00:29:45,680 --> 00:29:49,400 it because there was such this and there was such complex 540 00:29:49,400 --> 00:29:55,280 topology, but he was able to say, let's imagine that these 541 00:29:55,280 --> 00:29:57,960 are always there, like we can take them for granted. 542 00:29:58,440 --> 00:30:01,920 And so now if we are able to take this for granted that it's 543 00:30:01,920 --> 00:30:08,120 going to be there, we don't have to make it as complex as we 544 00:30:08,120 --> 00:30:09,480 thought we did. Exactly. 545 00:30:09,760 --> 00:30:13,360 But I, I guess I where's that parallel or where's the? 546 00:30:13,560 --> 00:30:18,040 I'm not drawing the conclusion of OK, if it's always there then 547 00:30:18,080 --> 00:30:22,160 it's less complexity. Because the complexity is moved 548 00:30:22,160 --> 00:30:26,360 down the the higher level abstraction is, they get to deal 549 00:30:26,360 --> 00:30:28,640 with this abstraction. That makes it less complex for 550 00:30:28,640 --> 00:30:31,520 them. And what we do in temporals, we 551 00:30:31,520 --> 00:30:33,000 map it down. It's complex. 552 00:30:33,000 --> 00:30:36,400 The runtime topology is just as complex. 553 00:30:36,800 --> 00:30:40,440 It's that the developer doesn't have to wire all that up 554 00:30:40,440 --> 00:30:43,440 themselves and create all of those components themselves. 555 00:30:44,240 --> 00:30:48,000 Temporal does that. So one of the things that I like 556 00:30:48,000 --> 00:30:52,800 to say is that event driven systems and event source 557 00:30:52,800 --> 00:30:56,400 systems, which is an added complexity on top of event 558 00:30:56,400 --> 00:31:01,880 driven systems, they are it's an incredibly powerful paradigm 559 00:31:01,880 --> 00:31:04,440 that we need for runtime resilience. 560 00:31:05,000 --> 00:31:11,920 But it's so hard for humans and non humid coders to understand 561 00:31:12,200 --> 00:31:15,840 because there's so many moving parts and it is each one of 562 00:31:15,840 --> 00:31:18,720 those is a little bit different. It is truly a Rube Goldberg 563 00:31:18,720 --> 00:31:20,320 machine. They're all a little bit 564 00:31:20,320 --> 00:31:22,320 different. And like you said, Domino's 565 00:31:22,320 --> 00:31:26,000 falling on Domino's. And so that's another one of the 566 00:31:26,000 --> 00:31:31,840 things I've not done any like tests of it, but I am being 567 00:31:31,840 --> 00:31:35,760 somebody who uses coding agents. If you give a coding agent a 568 00:31:35,760 --> 00:31:38,000 simpler programming model, they're going to do a better job 569 00:31:38,200 --> 00:31:40,760 writing the code in that simpler programming model as well. 570 00:31:41,160 --> 00:31:44,920 So the simpler programming model up until recently was a huge 571 00:31:44,920 --> 00:31:48,960 benefit for our early adopters. And we have a few 100,000 people 572 00:31:48,960 --> 00:31:52,720 are using Temporal. It's it just, which is still 573 00:31:52,720 --> 00:31:55,080 small compared to I think it should be in everybody, every 574 00:31:55,080 --> 00:32:00,040 developer's toolbox and will be in a few years, but it is now. 575 00:32:00,240 --> 00:32:04,920 I think the even bigger thing is like coding agents wouldn't do a 576 00:32:04,920 --> 00:32:09,680 very good job writing, you know, some complex thing in assembly. 577 00:32:09,920 --> 00:32:12,520 You give them higher level abstractions so that they the 578 00:32:12,680 --> 00:32:16,800 LLMS can reason through that. And so that's another thing with 579 00:32:16,800 --> 00:32:19,320 durable execution and that change in programming model is 580 00:32:19,320 --> 00:32:21,720 that that we give that programming model the 581 00:32:21,720 --> 00:32:24,440 understanding of that programming model to the agents 582 00:32:24,440 --> 00:32:26,680 and then they can write that code better as well. 583 00:32:27,000 --> 00:32:32,000 And how does it work if I now have all of this very complex 584 00:32:32,000 --> 00:32:37,760 topology and I install temporal, I have to have temporal map 585 00:32:37,760 --> 00:32:40,960 everything and then almost give a guarantee that all right, 586 00:32:40,960 --> 00:32:44,280 we're going to secure this or we're going to durable fi this? 587 00:32:44,640 --> 00:32:49,360 Ah, so it's actually that temporal brings that complex 588 00:32:49,360 --> 00:32:54,120 topology. So Temporal brings the messaging 589 00:32:54,120 --> 00:32:58,920 substrate, Temporal brings things like durable timers and 590 00:32:58,920 --> 00:33:02,040 stuff. So it is that the developer gets 591 00:33:02,040 --> 00:33:05,960 to write in this abstraction and when they deploy it, when they 592 00:33:05,960 --> 00:33:09,360 deploy those applications, Temporal takes what looks like a 593 00:33:09,360 --> 00:33:12,960 single process application because it is logically a single 594 00:33:12,960 --> 00:33:16,600 process and it maps it down to that complex topology. 595 00:33:17,560 --> 00:33:22,040 So it's not that the developer has to think about the complex 596 00:33:22,040 --> 00:33:24,440 topology. Temporal basically does that for 597 00:33:24,640 --> 00:33:26,440 for them. So that developer that you were 598 00:33:26,440 --> 00:33:29,360 saying Matt was his name? Matt McDowell, Yeah. 599 00:33:29,800 --> 00:33:36,400 He had to worry about everything in his former life where he's 600 00:33:36,400 --> 00:33:39,400 looking at it and he's trying to map out story points and saying 601 00:33:39,400 --> 00:33:40,520 this is going to take six months. 602 00:33:41,400 --> 00:33:45,600 And then he says, oh, no, well, maybe we'll just hit Temporal 603 00:33:45,600 --> 00:33:48,280 instead. And then you are in the 604 00:33:48,280 --> 00:33:52,320 background bringing the all of that that he thought he was 605 00:33:52,320 --> 00:33:54,640 having to wire up. Exactly. 606 00:33:55,560 --> 00:34:04,600 And so in a way, you're sitting in between his system and that 607 00:34:04,600 --> 00:34:08,320 complexity in the system, and he's just interfacing with you. 608 00:34:08,960 --> 00:34:11,000 And now everything's making sense. 609 00:34:11,000 --> 00:34:13,719 It took me a minute, but yeah, I'm getting it. 610 00:34:13,719 --> 00:34:16,040 While you're like, yeah, that's a higher level of abstraction. 611 00:34:16,040 --> 00:34:18,280 That's where we're what we've been talking about. 612 00:34:18,400 --> 00:34:22,400 Yeah, in, in, in Demetrius. That is that aha moment. 613 00:34:22,760 --> 00:34:26,480 I'm brilliant that you had it. It takes a while because we have 614 00:34:26,480 --> 00:34:30,960 spent, like I said, decades thinking about building systems 615 00:34:31,120 --> 00:34:33,239 with these lower level abstractions. 616 00:34:33,239 --> 00:34:35,679 Even as our programming languages gave us higher level 617 00:34:35,679 --> 00:34:38,679 abstractions, we still fundamentally still had to 618 00:34:38,679 --> 00:34:42,280 understand the architecture of the computer and the 619 00:34:42,280 --> 00:34:44,320 architecture of the network and things like that. 620 00:34:44,639 --> 00:34:46,600 What I'm saying is you don't have to anymore. 621 00:34:46,600 --> 00:34:48,639 Yeah. Yeah, just like you don't have 622 00:34:48,639 --> 00:34:51,320 to learn TypeScript or Python anymore. 623 00:34:52,120 --> 00:34:55,719 Yep, Yep, absolutely. If you know it and you can debug 624 00:34:55,719 --> 00:34:58,840 through it, but it's all, you can also create a lot of stuff 625 00:34:58,840 --> 00:35:00,600 without knowing it. Yep, that's right. 626 00:35:00,600 --> 00:35:04,680 So, yeah, all right. Well, yeah, that kind of drives 627 00:35:04,680 --> 00:35:08,120 it home and brings me full circle to, OK, we started this 628 00:35:08,120 --> 00:35:12,200 conversation with the evolution and the thread that has been 629 00:35:12,200 --> 00:35:15,920 going on these abstractions and programming models and 630 00:35:16,200 --> 00:35:19,160 recognizing how we're just continuously moving up and up 631 00:35:19,160 --> 00:35:24,880 and up and how durable execution is bringing a new level of 632 00:35:24,880 --> 00:35:29,320 abstraction to this, just like we have natural language 633 00:35:29,320 --> 00:35:31,880 bringing a new level of abstraction to the way that 634 00:35:31,880 --> 00:35:33,640 we're interacting. Yes, exactly. 635 00:35:33,640 --> 00:35:36,240 And I think that the probably the way of layering it is that 636 00:35:36,240 --> 00:35:39,160 we've had these traditional programming languages temporal 637 00:35:39,160 --> 00:35:43,120 layers and abstraction on top of that which is durable execution. 638 00:35:43,360 --> 00:35:48,720 That's what allows temporal to like figure out the abstract 639 00:35:48,720 --> 00:35:52,320 away the the physical processes and though, you know, network 640 00:35:52,320 --> 00:35:54,440 connections and all of that stuff, we handle that for you 641 00:35:54,840 --> 00:35:59,000 and then AI that the natural language programming sits over 642 00:35:59,000 --> 00:36:02,160 the top of that. So because Temporal isn't a 643 00:36:02,160 --> 00:36:06,040 language per SE, it's more of just like a helper. 644 00:36:06,360 --> 00:36:09,760 It's yeah, it's AII refer to it as a programming model. 645 00:36:10,480 --> 00:36:14,280 It's we, we, our SDKS are in a bunch of different languages. 646 00:36:14,280 --> 00:36:16,400 We're not giving you new programming language, but what 647 00:36:16,400 --> 00:36:19,080 we are doing is we're giving you a new set of abstractions. 648 00:36:19,080 --> 00:36:22,840 So a new programming model where instead of you deciding, oh, 649 00:36:22,840 --> 00:36:27,240 here's a process boundary, you basically break up your code 650 00:36:27,240 --> 00:36:31,640 into the, the things that where things could go wrong. 651 00:36:31,640 --> 00:36:33,960 Like I'm going to make a network call here or I'm going to go 652 00:36:33,960 --> 00:36:37,560 down to a database, or maybe it's a long running thing where 653 00:36:37,560 --> 00:36:42,480 you you don't want to have to re recompute it if something goes 654 00:36:42,480 --> 00:36:44,840 wrong. You put those things into 655 00:36:44,840 --> 00:36:46,720 activities. That's one of our primary 656 00:36:46,720 --> 00:36:49,160 abstractions. And then you wire the activities 657 00:36:49,160 --> 00:36:50,920 together in what we call workflows. 658 00:36:51,360 --> 00:36:54,240 And so that's the new programming model and it takes a 659 00:36:54,240 --> 00:36:58,440 while to like, it's so fundamentally different that it 660 00:36:58,440 --> 00:37:01,320 takes a while to kind of do that minds mindset shift. 661 00:37:01,400 --> 00:37:05,560 So I had something similar where I, I did my undergraduate in the 662 00:37:05,560 --> 00:37:09,640 greater LA area state school, learned all sorts of programming 663 00:37:09,640 --> 00:37:11,120 languages. They were really focused on 664 00:37:11,120 --> 00:37:14,360 getting you ready for industry. So it was learned half a dozen 665 00:37:14,360 --> 00:37:17,200 different programming languages. And then I worked for a few 666 00:37:17,200 --> 00:37:19,520 years and then I decided to go back to grad school and I went 667 00:37:19,520 --> 00:37:23,280 to Indiana University, which is a research university in 668 00:37:23,280 --> 00:37:25,920 southern Indiana. Programming languages is their 669 00:37:25,920 --> 00:37:27,520 thing. So that's really where I got 670 00:37:27,800 --> 00:37:29,320 hardcore into programming models. 671 00:37:29,560 --> 00:37:31,720 Well, because they're more research oriented, the first 672 00:37:31,720 --> 00:37:35,760 language that they teach their students as undergraduates is 673 00:37:35,760 --> 00:37:38,840 Scheme. And you could always tell the 674 00:37:38,840 --> 00:37:42,160 students who came in as freshmen who had already programmed in 675 00:37:42,160 --> 00:37:46,200 iterative programming languages like Pascal and Fortran and C 676 00:37:46,200 --> 00:37:47,840 and those types of things, because they had a hard time 677 00:37:47,840 --> 00:37:50,640 shifting their mindset over to a functional model. 678 00:37:51,040 --> 00:37:53,600 Very similar with Temporal is that. 679 00:37:53,920 --> 00:37:58,000 But once you make that shift, then you're like, oh, that's a 680 00:37:58,000 --> 00:38:00,240 different programming model. I can do totally different 681 00:38:00,240 --> 00:38:02,440 things with that now. It enables you. 682 00:38:02,560 --> 00:38:04,920 Yeah, That's a perfect place to finish it. 683 00:38:04,920 --> 00:38:06,400 Thank you for doing this with me. 684 00:38:06,640 --> 00:38:08,360 Thank you, it's been so fun.