1 02:46:35,200 --> 02:46:38,469 All right. Uh well, super excited to be 2 02:46:38,479 --> 02:46:40,469 here. My name is Ankit. I'm from Data 3 02:46:40,479 --> 02:46:42,469 Bricks. Uh I work on AI infrastructure 4 02:46:42,479 --> 02:46:44,575 there. And today I'm going to talk about 5 02:46:44,585 --> 02:46:44,710 >> [music] 6 02:46:44,720 --> 02:46:46,630 >> uh the rise of the agent workforce and 7 02:46:46,640 --> 02:46:48,389 how we're building our agent 8 02:46:48,399 --> 02:46:50,230 infrastructure to support what we think 9 02:46:50,240 --> 02:46:52,790 is the next generation of agents. 10 02:46:52,800 --> 02:46:54,870 I wanted to start by taking a step back 11 02:46:54,880 --> 02:46:57,269 and and thinking about how we help 12 02:46:57,279 --> 02:47:00,070 computers become good at other things uh 13 02:47:00,080 --> 02:47:02,469 better even than humans. And one of the 14 02:47:02,479 --> 02:47:04,550 games I grew up playing a lot was chess. 15 02:47:04,560 --> 02:47:06,150 Uh it's one of the great examples of 16 02:47:06,160 --> 02:47:07,830 something where computers became way 17 02:47:07,840 --> 02:47:10,309 better than humans a long time ago. But 18 02:47:10,319 --> 02:47:12,150 I think it's important to think about 19 02:47:12,160 --> 02:47:14,070 why that happened and how we can apply 20 02:47:14,080 --> 02:47:16,630 those lessons today. One of the biggest, 21 02:47:16,640 --> 02:47:18,389 you know, to summarize at a high level, 22 02:47:18,399 --> 02:47:20,630 a lot of work went into it. The biggest 23 02:47:20,640 --> 02:47:22,230 thing that agents were able to do, that 24 02:47:22,240 --> 02:47:24,150 computers were able to do was explore 25 02:47:24,160 --> 02:47:26,630 the space of decisions much more 26 02:47:26,640 --> 02:47:29,190 effectively than humans. For most 27 02:47:29,200 --> 02:47:30,790 complex problems, there's actually a 28 02:47:30,800 --> 02:47:32,230 bunch of different ways you can solve 29 02:47:32,240 --> 02:47:34,630 the problem. And at each turn, you can 30 02:47:34,640 --> 02:47:37,030 kind of think of three more decisions 31 02:47:37,040 --> 02:47:38,870 that you can make. And really, it's the 32 02:47:38,880 --> 02:47:40,710 exploration of that space that all of us 33 02:47:40,720 --> 02:47:42,389 are engaged in. All of us who solve hard 34 02:47:42,399 --> 02:47:44,389 problems are engaged in the search space 35 02:47:44,399 --> 02:47:46,389 for what's an amazing product, what's 36 02:47:46,399 --> 02:47:48,070 the right solution to this math problem, 37 02:47:48,080 --> 02:47:50,710 and etc., right? uh and I think we've 38 02:47:50,720 --> 02:47:53,030 seen some really exciting progress from 39 02:47:53,040 --> 02:47:54,950 the labs like Enthropic, OpenAI and 40 02:47:54,960 --> 02:47:57,349 Google on solving problems that are 41 02:47:57,359 --> 02:47:59,190 wellformed. So, you know, if you think 42 02:47:59,200 --> 02:48:00,710 about chess, it can be modeled 43 02:48:00,720 --> 02:48:02,630 effectively. You can evaluate your 44 02:48:02,640 --> 02:48:05,190 position. Uh you can actually play 45 02:48:05,200 --> 02:48:07,110 simulate it. You can try different moves 46 02:48:07,120 --> 02:48:09,190 and safely think about all the different 47 02:48:09,200 --> 02:48:11,349 alternatives. Similarly, with math 48 02:48:11,359 --> 02:48:13,269 problems, often the ones that agents are 49 02:48:13,279 --> 02:48:15,510 really good at solving, they you can 50 02:48:15,520 --> 02:48:17,030 actually verify if you got the result 51 02:48:17,040 --> 02:48:20,550 right. uh and how do we then take that 52 02:48:20,560 --> 02:48:22,389 mindset and apply it to the problems 53 02:48:22,399 --> 02:48:25,190 that we actually face day-to-day. 54 02:48:25,200 --> 02:48:27,429 I think like let's a lot everyone here 55 02:48:27,439 --> 02:48:29,510 is an engineer. So let's take it to 56 02:48:29,520 --> 02:48:31,910 engineering for a bit. Uh I think you 57 02:48:31,920 --> 02:48:34,710 know if you take it to the preai days uh 58 02:48:34,720 --> 02:48:37,030 most people think about solving a single 59 02:48:37,040 --> 02:48:37,990 problem and they're kind of 60 02:48:38,000 --> 02:48:39,670 singlethreaded on that problem for the 61 02:48:39,680 --> 02:48:41,670 time that they're writing code on it. uh 62 02:48:41,680 --> 02:48:43,429 and you know as a company if or a 63 02:48:43,439 --> 02:48:44,710 product if you wanted to solve more 64 02:48:44,720 --> 02:48:46,950 problems you brought in more people and 65 02:48:46,960 --> 02:48:49,830 the very basic version of agents just 66 02:48:49,840 --> 02:48:51,830 helps create leverage for that engineer. 67 02:48:51,840 --> 02:48:53,750 Now you can be singlethreaded on three 68 02:48:53,760 --> 02:48:55,670 things at the same time and ultimately 69 02:48:55,680 --> 02:48:57,190 that helps you explore new product 70 02:48:57,200 --> 02:49:00,150 ideas, ship faster, iterate faster and 71 02:49:00,160 --> 02:49:02,230 that's obviously very exciting. But it's 72 02:49:02,240 --> 02:49:04,150 it's not actually close to what we 73 02:49:04,160 --> 02:49:06,710 needed to do to win at chess or any of 74 02:49:06,720 --> 02:49:08,710 these other problems. What we're seeing 75 02:49:08,720 --> 02:49:11,030 at the absolute frontier are these teams 76 02:49:11,040 --> 02:49:12,389 of agents that are able to make 77 02:49:12,399 --> 02:49:14,389 significant progress by exploring the 78 02:49:14,399 --> 02:49:16,469 decision space more effectively. So how 79 02:49:16,479 --> 02:49:18,870 do we move towards that world where we 80 02:49:18,880 --> 02:49:20,550 actually have these teams of agents that 81 02:49:20,560 --> 02:49:22,070 are coherently attempting to solve 82 02:49:22,080 --> 02:49:24,070 problems? It's actually quite complex 83 02:49:24,080 --> 02:49:25,990 and we think it requires a little bit 84 02:49:26,000 --> 02:49:28,389 different type of infrastructure. 85 02:49:28,399 --> 02:49:30,790 Specifically, I think an important 86 02:49:30,800 --> 02:49:32,950 question to ask is how do we give agents 87 02:49:32,960 --> 02:49:36,150 a realistic world to explore? Because in 88 02:49:36,160 --> 02:49:37,750 other problems, we're able to help 89 02:49:37,760 --> 02:49:39,910 define that world very effectively. But 90 02:49:39,920 --> 02:49:41,429 even in software engineering, we 91 02:49:41,439 --> 02:49:43,190 actually really struggle to do that. 92 02:49:43,200 --> 02:49:45,510 Like just consider this movement towards 93 02:49:45,520 --> 02:49:47,429 software factories, right? Where you're 94 02:49:47,439 --> 02:49:49,110 away from the from the agents and you're 95 02:49:49,120 --> 02:49:50,469 actually operating a bunch of agents 96 02:49:50,479 --> 02:49:53,110 that are working on a problem. How do 97 02:49:53,120 --> 02:49:54,710 you validate that those agents are 98 02:49:54,720 --> 02:49:58,469 effective? Like before you had a branch 99 02:49:58,479 --> 02:50:00,309 uh you had main, you branched your PR 100 02:50:00,319 --> 02:50:01,670 off of that. Maybe you have an agent 101 02:50:01,680 --> 02:50:04,710 working on that PR and you have some 102 02:50:04,720 --> 02:50:06,790 reasonable assertion that this is kind 103 02:50:06,800 --> 02:50:08,550 of a sim, you know, you have some ass 104 02:50:08,560 --> 02:50:09,990 like some tests or something like that 105 02:50:10,000 --> 02:50:12,790 that help you guide your development. 106 02:50:12,800 --> 02:50:15,190 But if you're actually merging tens of 107 02:50:15,200 --> 02:50:17,750 PRs a minute or even more, right? Like 108 02:50:17,760 --> 02:50:20,389 if you play out the future of factories 109 02:50:20,399 --> 02:50:23,110 of agents building code and software, 110 02:50:23,120 --> 02:50:24,870 your PR is just out of date the moment 111 02:50:24,880 --> 02:50:26,710 you branched. The the moment you 112 02:50:26,720 --> 02:50:28,710 started, you're already out of date. So 113 02:50:28,720 --> 02:50:30,710 it demands a different mindset of 114 02:50:30,720 --> 02:50:32,150 thinking of how do we verify these 115 02:50:32,160 --> 02:50:33,510 things? You actually might want to move 116 02:50:33,520 --> 02:50:36,309 most of your verification to postmerge. 117 02:50:36,319 --> 02:50:38,870 And so that kind of brings me to this a 118 02:50:38,880 --> 02:50:41,030 little bit radical idea. I I don't think 119 02:50:41,040 --> 02:50:43,269 we should try to write hundreds or 120 02:50:43,279 --> 02:50:45,910 thousands of unit tests. Instead, I want 121 02:50:45,920 --> 02:50:48,070 to explore this idea of simulating 122 02:50:48,080 --> 02:50:51,510 reality. Can I give my agent a faithful 123 02:50:51,520 --> 02:50:53,670 reproduction of what's actually there in 124 02:50:53,680 --> 02:50:55,590 the real world in my production code in 125 02:50:55,600 --> 02:50:58,150 my production agent and let it work on 126 02:50:58,160 --> 02:51:01,269 that? And with when you can do that, you 127 02:51:01,279 --> 02:51:03,349 can actually do that at scale. If you 128 02:51:03,359 --> 02:51:05,429 find a way to simulate reality, then you 129 02:51:05,439 --> 02:51:07,349 can actually do that across lots of 130 02:51:07,359 --> 02:51:09,349 different explorations. 131 02:51:09,359 --> 02:51:10,790 At data bricks, one of the big things 132 02:51:10,800 --> 02:51:12,630 that people do on our platform is build 133 02:51:12,640 --> 02:51:14,550 data pipelines. We've got tens of 134 02:51:14,560 --> 02:51:16,150 thousands of data pipelines on data 135 02:51:16,160 --> 02:51:19,269 bricks. Uh and the biggest problem that 136 02:51:19,279 --> 02:51:20,630 happens with pipelines is that they 137 02:51:20,640 --> 02:51:23,510 break. Um and in this era of agents, 138 02:51:23,520 --> 02:51:25,030 what people want is they want to fix 139 02:51:25,040 --> 02:51:27,990 those broken pipelines with agents 140 02:51:28,000 --> 02:51:29,670 because these are serious business 141 02:51:29,680 --> 02:51:31,429 problems that they that are, you know, 142 02:51:31,439 --> 02:51:33,750 uh caused by a broken pipeline. If a 143 02:51:33,760 --> 02:51:35,269 pipeline breaks, that business can't 144 02:51:35,279 --> 02:51:37,830 operate that day. Uh and so this becomes 145 02:51:37,840 --> 02:51:39,990 a major emergency. 146 02:51:40,000 --> 02:51:41,910 But like how do you actually validate 147 02:51:41,920 --> 02:51:43,510 this with an agent? Do you trust it on 148 02:51:43,520 --> 02:51:45,590 your production data pipeline? It's 149 02:51:45,600 --> 02:51:47,910 pretty risky because writes might not be 150 02:51:47,920 --> 02:51:54,070 identy 151 02:51:54,080 --> 02:51:56,790 broken. It's just partially broken. One 152 02:51:56,800 --> 02:51:58,469 of the things we started doing was 153 02:51:58,479 --> 02:51:59,830 building on top of branchable 154 02:51:59,840 --> 02:52:02,070 infrastructure. And so what we did was 155 02:52:02,080 --> 02:52:05,030 we branched the entire data platform. We 156 02:52:05,040 --> 02:52:07,590 branched the tables, the compute, the 157 02:52:07,600 --> 02:52:10,309 governance and we gave the agents a 158 02:52:10,319 --> 02:52:12,150 place where they can actually play with 159 02:52:12,160 --> 02:52:14,389 the data platform and explore different 160 02:52:14,399 --> 02:52:16,950 hypotheses. And these hypotheses can be 161 02:52:16,960 --> 02:52:19,190 ambitious like can I investigate that 162 02:52:19,200 --> 02:52:21,030 the upstream pipeline is healthy? Maybe 163 02:52:21,040 --> 02:52:22,790 I can do that by changing the pipeline 164 02:52:22,800 --> 02:52:24,950 code and running it again. In any 165 02:52:24,960 --> 02:52:27,269 reasonable data platform, you wouldn't 166 02:52:27,279 --> 02:52:28,870 do that with an upstream pipeline unless 167 02:52:28,880 --> 02:52:30,230 you had a bunch of engineers take a look 168 02:52:30,240 --> 02:52:32,309 at it and make sure it was super safe. 169 02:52:32,319 --> 02:52:34,070 with our branched data platform. You can 170 02:52:34,080 --> 02:52:35,349 actually do that now. So it can 171 02:52:35,359 --> 02:52:37,110 investigate a bunch of different things. 172 02:52:37,120 --> 02:52:38,950 So we can investigate 10 ideas in 173 02:52:38,960 --> 02:52:41,910 parallel with our agents actually get to 174 02:52:41,920 --> 02:52:43,670 a faithful conclusion about whether it 175 02:52:43,680 --> 02:52:46,230 fixed the real data pipeline and then 176 02:52:46,240 --> 02:52:48,150 make that assumption made that assertion 177 02:52:48,160 --> 02:52:49,990 back either to a main agent or to a 178 02:52:50,000 --> 02:52:51,990 human. And what we saw before was 179 02:52:52,000 --> 02:52:53,110 happening was that people would just 180 02:52:53,120 --> 02:52:55,910 like LLM would give us text back some 181 02:52:55,920 --> 02:52:57,190 human would take a look at it and be 182 02:52:57,200 --> 02:52:58,469 like okay this might be an interesting 183 02:52:58,479 --> 02:53:00,550 theory. then they would go apply that 184 02:53:00,560 --> 02:53:02,870 theory in some way. And ultimately that 185 02:53:02,880 --> 02:53:05,269 became more of this like AI assisted 186 02:53:05,279 --> 02:53:07,750 version of fixing the data pipeline. But 187 02:53:07,760 --> 02:53:09,510 really where we want to go is is is 188 02:53:09,520 --> 02:53:13,110 hands-off full auto for this kind of 189 02:53:13,120 --> 02:53:15,429 problem. And we were we were struggling 190 02:53:15,439 --> 02:53:16,630 to do it without this branchable 191 02:53:16,640 --> 02:53:19,110 infrastructure. So how do we do it? I'm 192 02:53:19,120 --> 02:53:20,150 going to talk a little bit about that in 193 02:53:20,160 --> 02:53:23,190 this talk. Uh we built this on top of 194 02:53:23,200 --> 02:53:25,429 our Postgress native agent platform 195 02:53:25,439 --> 02:53:27,349 which started with the Neon database 196 02:53:27,359 --> 02:53:29,349 which is a branchable database that 197 02:53:29,359 --> 02:53:31,110 gives us a single place that we can 198 02:53:31,120 --> 02:53:32,710 actually use for our services and for 199 02:53:32,720 --> 02:53:35,429 our agents. And then we added in a bunch 200 02:53:35,439 --> 02:53:37,429 of really core agent primitives that 201 02:53:37,439 --> 02:53:38,950 allow us to build sophisticated 202 02:53:38,960 --> 02:53:40,870 different types of agents. Uh and those 203 02:53:40,880 --> 02:53:42,309 are ones that are probably familiar to 204 02:53:42,319 --> 02:53:43,830 all of you. Things like memory, things 205 02:53:43,840 --> 02:53:46,309 like sandboxes, file systems, and ways 206 02:53:46,319 --> 02:53:48,309 to host those agents. And these 207 02:53:48,319 --> 02:53:50,230 low-level primitives we can build we can 208 02:53:50,240 --> 02:53:51,910 build with them. But the key is that we 209 02:53:51,920 --> 02:53:53,670 made just all of them branchable. So you 210 02:53:53,680 --> 02:53:55,990 can branch the entire reality of stuff 211 02:53:56,000 --> 02:53:57,590 that's built on this platform for us for 212 02:53:57,600 --> 02:54:00,230 ourselves. Uh so how do we actually do 213 02:54:00,240 --> 02:54:02,309 that? Well, let me walk it through like 214 02:54:02,319 --> 02:54:05,269 kind of case by case. The first thing is 215 02:54:05,279 --> 02:54:06,790 just the database, right? And you know 216 02:54:06,800 --> 02:54:08,469 we can take an example of application 217 02:54:08,479 --> 02:54:09,750 services. But here I'm going to talk 218 02:54:09,760 --> 02:54:11,590 about just even storing the conversation 219 02:54:11,600 --> 02:54:14,790 state for for an agent. When you fork or 220 02:54:14,800 --> 02:54:16,790 branch an agent, you actually might want 221 02:54:16,800 --> 02:54:18,389 to inherit the history. And you might 222 02:54:18,399 --> 02:54:19,990 even if you have a team of agents give 223 02:54:20,000 --> 02:54:22,309 access to a given member of that team to 224 02:54:22,319 --> 02:54:23,830 what the other members of the team are 225 02:54:23,840 --> 02:54:25,750 doing. Uh and we found the database to 226 02:54:25,760 --> 02:54:28,389 be a convenient abstraction for this. Uh 227 02:54:28,399 --> 02:54:30,309 the key was that hey like when a new 228 02:54:30,319 --> 02:54:32,389 reply comes in on the on the branched 229 02:54:32,399 --> 02:54:33,990 agent it shouldn't necessarily change 230 02:54:34,000 --> 02:54:36,070 anything about the other one. Uh and 231 02:54:36,080 --> 02:54:38,389 this is possible because Neon has a 232 02:54:38,399 --> 02:54:40,710 branched database. But then we actually 233 02:54:40,720 --> 02:54:42,630 found that agents need more than just 234 02:54:42,640 --> 02:54:44,150 structured databases. Of course they 235 02:54:44,160 --> 02:54:46,230 need structured databases but they also 236 02:54:46,240 --> 02:54:47,990 like to do this you know write these 237 02:54:48,000 --> 02:54:50,469 things called memories and memories are 238 02:54:50,479 --> 02:54:52,230 you know at a very high level they 239 02:54:52,240 --> 02:54:53,990 compile down to an unstructured database 240 02:54:54,000 --> 02:54:56,230 for agents. There are two ways that 241 02:54:56,240 --> 02:54:58,309 memories get generated. The first is 242 02:54:58,319 --> 02:55:00,710 just by synthesizing the context and the 243 02:55:00,720 --> 02:55:01,990 conversations that someone's already had 244 02:55:02,000 --> 02:55:04,950 with them and the second by agents 245 02:55:04,960 --> 02:55:07,670 actually explicitly saving content to an 246 02:55:07,680 --> 02:55:10,309 unstructured place. The key thing here 247 02:55:10,319 --> 02:55:12,070 is that you actually want to consolidate 248 02:55:12,080 --> 02:55:13,670 and distill that information. there's a 249 02:55:13,680 --> 02:55:15,030 ton of information coming in through 250 02:55:15,040 --> 02:55:17,110 there and if you just give that you know 251 02:55:17,120 --> 02:55:19,349 if you just let it kind of go on its own 252 02:55:19,359 --> 02:55:22,150 you have problems of staleness you have 253 02:55:22,160 --> 02:55:24,230 conflicts in the information and all of 254 02:55:24,240 --> 02:55:26,630 those can be extremely damaging to teams 255 02:55:26,640 --> 02:55:28,710 so we have this thing that basically 256 02:55:28,720 --> 02:55:32,230 dreams overnight we use offline compute 257 02:55:32,240 --> 02:55:34,150 uh and it takes the conversations a 258 02:55:34,160 --> 02:55:35,910 different agent essentially highlights 259 02:55:35,920 --> 02:55:38,389 things that are conflicts and 260 02:55:38,399 --> 02:55:40,550 consolidates the ad hoc notes that were 261 02:55:40,560 --> 02:55:42,309 written by various members of the team 262 02:55:42,319 --> 02:55:44,150 and then all members of the team can 263 02:55:44,160 --> 02:55:45,670 actually recall from that memory 264 02:55:45,680 --> 02:55:47,910 database. And you can use this in a 265 02:55:47,920 --> 02:55:49,190 bunch of different ways. We use this 266 02:55:49,200 --> 02:55:51,349 within our Slack agents, but we also use 267 02:55:51,359 --> 02:55:53,830 this when we're launching a parallel set 268 02:55:53,840 --> 02:55:56,070 of agents to investigate a deep issue, 269 02:55:56,080 --> 02:55:58,309 for example, in the data platform. Now, 270 02:55:58,319 --> 02:56:01,269 how does branching come into this? Well, 271 02:56:01,279 --> 02:56:02,950 some of the agents like in many of the 272 02:56:02,960 --> 02:56:05,349 use cases, they propose memories and 273 02:56:05,359 --> 02:56:06,870 it's not clear whether those memories 274 02:56:06,880 --> 02:56:09,670 generalize to the actual broader set of 275 02:56:09,680 --> 02:56:11,429 agents or if that's a specific thing for 276 02:56:11,439 --> 02:56:13,510 just that agent. And so with the 277 02:56:13,520 --> 02:56:15,190 branchable database for memory which is 278 02:56:15,200 --> 02:56:17,349 built on top of this neon database, we 279 02:56:17,359 --> 02:56:18,870 can actually just propose that memory 280 02:56:18,880 --> 02:56:21,269 somewhere in there and that branch can 281 02:56:21,279 --> 02:56:23,269 continue to iterate and at some point we 282 02:56:23,279 --> 02:56:24,710 can find a way to merge it back in if 283 02:56:24,720 --> 02:56:27,510 it's necessary. uh we found this to be a 284 02:56:27,520 --> 02:56:29,670 flex an important layer of flexibility 285 02:56:29,680 --> 02:56:31,190 because without the ability to 286 02:56:31,200 --> 02:56:33,269 completely branch the memory we found it 287 02:56:33,279 --> 02:56:35,670 was very hard to maintain the memory for 288 02:56:35,680 --> 02:56:37,990 a team of agents especially as we 289 02:56:38,000 --> 02:56:39,670 increase parallelism you can actually 290 02:56:39,680 --> 02:56:41,190 experience like significantly reduced 291 02:56:41,200 --> 02:56:43,510 quality if all the agents are pursuing 292 02:56:43,520 --> 02:56:46,469 different goals uh I I I like to think a 293 02:56:46,479 --> 02:56:47,990 little bit of it as as like kind of 294 02:56:48,000 --> 02:56:49,670 similar to dynamic programming right if 295 02:56:49,680 --> 02:56:51,910 you've explored a branch of exploration 296 02:56:51,920 --> 02:56:53,670 and then you have a different agent that 297 02:56:53,680 --> 02:56:55,990 happens upon that same pathway It's very 298 02:56:56,000 --> 02:56:58,469 damaging to like always revisit that but 299 02:56:58,479 --> 02:57:00,469 sometimes you want to and so the ability 300 02:57:00,479 --> 02:57:02,230 to propose a memory is extremely 301 02:57:02,240 --> 02:57:04,550 important to us. 302 02:57:04,560 --> 02:57:06,230 How is all of this kind of branchable 303 02:57:06,240 --> 02:57:08,309 database possible? Well, the way that 304 02:57:08,319 --> 02:57:10,309 Neon does is it is it separates compute 305 02:57:10,319 --> 02:57:13,670 from storage. Compute uh for Postgress 306 02:57:13,680 --> 02:57:15,670 is running in some separate place and 307 02:57:15,680 --> 02:57:17,750 then we actually have the shared history 308 02:57:17,760 --> 02:57:19,830 and the storage in a different layer and 309 02:57:19,840 --> 02:57:21,910 what that lets us do is copy on write 310 02:57:21,920 --> 02:57:23,830 for branching. So when we have a 311 02:57:23,840 --> 02:57:25,269 branched version of the database, you 312 02:57:25,279 --> 02:57:26,870 can actually have A's uh you know 313 02:57:26,880 --> 02:57:28,469 compute A's rights separated from 314 02:57:28,479 --> 02:57:30,469 compute B and that's the kind of the 315 02:57:30,479 --> 02:57:32,150 core layer of infrastructure that allows 316 02:57:32,160 --> 02:57:34,469 us to build these applications on top of 317 02:57:34,479 --> 02:57:37,190 that database. 318 02:57:37,200 --> 02:57:38,870 But then we found you know obviously 319 02:57:38,880 --> 02:57:41,269 agents are far more than storage and and 320 02:57:41,279 --> 02:57:43,750 branching storage wasn't enough. 321 02:57:43,760 --> 02:57:45,510 We also found that as they were running 322 02:57:45,520 --> 02:57:47,590 in sandboxes, agents like to take notes 323 02:57:47,600 --> 02:57:50,469 on stuff and write down scripts and use 324 02:57:50,479 --> 02:57:52,710 those to actually iterate on various 325 02:57:52,720 --> 02:57:54,710 kinds of problems. It it it's one of the 326 02:57:54,720 --> 02:57:56,550 most exciting things about agents that 327 02:57:56,560 --> 02:57:58,469 I've found that they are able to 328 02:57:58,479 --> 02:58:00,230 generalize this capability that's needed 329 02:58:00,240 --> 02:58:02,389 maybe for testing code and and things 330 02:58:02,399 --> 02:58:04,469 like that and solve other more broader 331 02:58:04,479 --> 02:58:06,630 general problems using that same con 332 02:58:06,640 --> 02:58:08,469 construct. 333 02:58:08,479 --> 02:58:10,150 But then when you branch it, you 334 02:58:10,160 --> 02:58:12,070 actually need to give the future agent a 335 02:58:12,080 --> 02:58:13,670 similar context. If you we found that 336 02:58:13,680 --> 02:58:15,190 when we started the branched agents 337 02:58:15,200 --> 02:58:17,110 without the same files that that agent 338 02:58:17,120 --> 02:58:19,429 had to begin with it just wasn't as 339 02:58:19,439 --> 02:58:21,110 effective. So when you're investigating 340 02:58:21,120 --> 02:58:23,750 an outage for example with an agent you 341 02:58:23,760 --> 02:58:26,150 might have notes and plans and a future 342 02:58:26,160 --> 02:58:27,510 branch of that agent might update those 343 02:58:27,520 --> 02:58:30,469 notes. It might find new things but we 344 02:58:30,479 --> 02:58:32,389 don't want that to go back because we're 345 02:58:32,399 --> 02:58:34,150 actually exploring 10 different pathways 346 02:58:34,160 --> 02:58:36,309 at the same time. Uh so building a 347 02:58:36,319 --> 02:58:37,830 branchable file system was extremely 348 02:58:37,840 --> 02:58:39,590 important and allowed us to build what 349 02:58:39,600 --> 02:58:42,150 we call a branchable sandbox because 350 02:58:42,160 --> 02:58:44,230 then what we can do is we can launch 351 02:58:44,240 --> 02:58:46,150 that sandbox compute and and that's a 352 02:58:46,160 --> 02:58:47,590 hard problem in and of itself. It's not 353 02:58:47,600 --> 02:58:49,990 one we're going to talk about today but 354 02:58:50,000 --> 02:58:52,389 that compute can be attached to storage 355 02:58:52,399 --> 02:58:54,950 and critically the agents actually 356 02:58:54,960 --> 02:58:57,110 really aggressively leverage files very 357 02:58:57,120 --> 02:58:59,190 often. Uh and so it can be very painful 358 02:58:59,200 --> 02:59:01,590 to make all your storage fully remote. 359 02:59:01,600 --> 02:59:03,510 Uh and so the really core piece of what 360 02:59:03,520 --> 02:59:05,590 we've been building here is a syncing 361 02:59:05,600 --> 02:59:07,830 process between what we call a local 362 02:59:07,840 --> 02:59:10,710 cache and the remote cache. Uh and then 363 02:59:10,720 --> 02:59:12,389 what that allows us to do is as we're 364 02:59:12,399 --> 02:59:14,630 able to make progress on that when we 365 02:59:14,640 --> 02:59:16,630 want to branch we can actually branch a 366 02:59:16,640 --> 02:59:19,030 second sandbox use that similar file 367 02:59:19,040 --> 02:59:21,269 system and it reduces our latency for 368 02:59:21,279 --> 02:59:23,190 for branching while also keeping 369 02:59:23,200 --> 02:59:25,030 performance of the regular agent 370 02:59:25,040 --> 02:59:27,190 reasonable. 371 02:59:27,200 --> 02:59:29,830 So what this allows us to do at a high 372 02:59:29,840 --> 02:59:31,910 level is branch the entire working 373 02:59:31,920 --> 02:59:33,590 state. 374 02:59:33,600 --> 02:59:35,910 And this gives us the platform layer to 375 02:59:35,920 --> 02:59:38,150 actually go do that. Now this isn't 376 02:59:38,160 --> 02:59:39,429 obviously sufficient. You're going to 377 02:59:39,439 --> 02:59:41,110 want to branch even more. If you're 378 02:59:41,120 --> 02:59:42,630 building on top of software, you want to 379 02:59:42,640 --> 02:59:44,790 find a way to branch that too. And so 380 02:59:44,800 --> 02:59:46,469 this is along the lines of how we're 381 02:59:46,479 --> 02:59:47,750 thinking, right? Like we the data 382 02:59:47,760 --> 02:59:49,750 platform was built on top of some of 383 02:59:49,760 --> 02:59:50,950 these things, but there's a lot more 384 02:59:50,960 --> 02:59:52,469 that we've been able to branch there as 385 02:59:52,479 --> 02:59:54,870 well. Uh but we're really excited about 386 02:59:54,880 --> 02:59:56,389 this layer for just even building 387 02:59:56,399 --> 02:59:58,870 agents. And just to like kind of 388 02:59:58,880 --> 03:00:00,389 separate a little bit even from software 389 03:00:00,399 --> 03:00:02,389 development like another thing a lot of 390 03:00:02,399 --> 03:00:03,990 us are spending a lot of time thinking 391 03:00:04,000 --> 03:00:06,870 about is security. 392 03:00:06,880 --> 03:00:09,590 Uh, I mean just taking a step back, I 393 03:00:09,600 --> 03:00:11,190 think this is probably the single most 394 03:00:11,200 --> 03:00:12,630 important thing for any product that 395 03:00:12,640 --> 03:00:15,349 anyone sells at this point because trust 396 03:00:15,359 --> 03:00:16,870 is kind of the most important thing that 397 03:00:16,880 --> 03:00:18,230 we're selling when we work with other 398 03:00:18,240 --> 03:00:21,269 people. And uh, with agents being the 399 03:00:21,279 --> 03:00:24,070 ones who generate the vulnerabilities, 400 03:00:24,080 --> 03:00:27,110 uh, it's kind of impossible to find a 401 03:00:27,120 --> 03:00:28,790 different solution than having agents be 402 03:00:28,800 --> 03:00:30,389 the ones who are monitoring for those 403 03:00:30,399 --> 03:00:33,030 exact vulnerabilities in your code. So 404 03:00:33,040 --> 03:00:34,389 you should be thinking about how you can 405 03:00:34,399 --> 03:00:36,230 build an agent factory that's detecting 406 03:00:36,240 --> 03:00:39,030 security issues in your codebase. Um and 407 03:00:39,040 --> 03:00:40,389 so this is something we spending a lot 408 03:00:40,399 --> 03:00:43,190 of time out spending a lot of time on. 409 03:00:43,200 --> 03:00:44,950 So typically what happens in a security 410 03:00:44,960 --> 03:00:47,190 incident? Well, let's say you suspect 411 03:00:47,200 --> 03:00:48,469 something. An agent might be always 412 03:00:48,479 --> 03:00:50,550 looking for it. Why why is there this 413 03:00:50,560 --> 03:00:52,230 like network traffic that's erressing 414 03:00:52,240 --> 03:00:54,870 all of a sudden from my control plane? 415 03:00:54,880 --> 03:00:56,230 Well, I can assemble an incident 416 03:00:56,240 --> 03:00:57,670 timeline and that's obviously the first 417 03:00:57,680 --> 03:00:59,510 step in an investigation. But anyone 418 03:00:59,520 --> 03:01:01,030 who's been a part of a serious security 419 03:01:01,040 --> 03:01:03,269 investig investigation knows that time 420 03:01:03,279 --> 03:01:05,190 is of the essence. It's a perfect 421 03:01:05,200 --> 03:01:06,870 problem for parallelism. And that's 422 03:01:06,880 --> 03:01:08,150 exactly what you do when a security 423 03:01:08,160 --> 03:01:09,510 incident happens. You bring everyone 424 03:01:09,520 --> 03:01:12,710 online so you can explore 10, 15, 20 425 03:01:12,720 --> 03:01:14,870 different theories at once because an 426 03:01:14,880 --> 03:01:16,870 hour earlier that you can you can detect 427 03:01:16,880 --> 03:01:18,950 the real issue is an hour that you're 428 03:01:18,960 --> 03:01:22,150 actually more safe. So okay, what if we 429 03:01:22,160 --> 03:01:24,550 did that with a branchable agent? Let's 430 03:01:24,560 --> 03:01:27,110 say there's two paths to investigate. Uh 431 03:01:27,120 --> 03:01:28,710 so you know the agents assembled the 432 03:01:28,720 --> 03:01:31,190 incident timeline and now you can ask 433 03:01:31,200 --> 03:01:32,630 two questions. Hey did a recent 434 03:01:32,640 --> 03:01:34,710 deployment in introduce some kind of new 435 03:01:34,720 --> 03:01:36,630 integration like maybe I can go look at 436 03:01:36,640 --> 03:01:39,269 the code or I can explore a totally 437 03:01:39,279 --> 03:01:40,790 different theory. Is a compromised 438 03:01:40,800 --> 03:01:43,110 identity accessing this data and the 439 03:01:43,120 --> 03:01:44,469 core thing that we are able to do here 440 03:01:44,479 --> 03:01:46,870 is we branch that whole original agent 441 03:01:46,880 --> 03:01:50,070 that was starting the investigation 442 03:01:50,080 --> 03:01:51,830 and then the new one is able to work in 443 03:01:51,840 --> 03:01:54,230 a completely isolated copy of the world. 444 03:01:54,240 --> 03:01:56,070 And in some cases when we're able to, we 445 03:01:56,080 --> 03:01:57,670 can even branch the actual service that 446 03:01:57,680 --> 03:02:00,150 we're investigating. Uh, and so when you 447 03:02:00,160 --> 03:02:02,070 have this isolated copy of conversation, 448 03:02:02,080 --> 03:02:04,309 memory, and storage, you can fully 449 03:02:04,319 --> 03:02:06,309 explore that security risk and and let 450 03:02:06,319 --> 03:02:08,070 the agent loop on its own. And that's 451 03:02:08,080 --> 03:02:10,150 kind of the key thing here. The way that 452 03:02:10,160 --> 03:02:12,309 these agents are good is that they're 453 03:02:12,319 --> 03:02:15,670 able to loop, verify, try new theories. 454 03:02:15,680 --> 03:02:17,510 I think Andre Karpathy said it really 455 03:02:17,520 --> 03:02:20,389 well. They're far more tenacious than 456 03:02:20,399 --> 03:02:23,030 any human probably in the history of 457 03:02:23,040 --> 03:02:25,429 software. And so they're able to just 458 03:02:25,439 --> 03:02:27,429 but like we keep getting in the way by 459 03:02:27,439 --> 03:02:29,269 inserting ourselves as an approval 460 03:02:29,279 --> 03:02:31,830 layer. Uh and so this is a solution that 461 03:02:31,840 --> 03:02:33,670 we think helps with that. Just like take 462 03:02:33,680 --> 03:02:35,190 away the consequences of making a 463 03:02:35,200 --> 03:02:37,830 mistake a little bit. Branch the entire 464 03:02:37,840 --> 03:02:40,630 state so that you're not actually you 465 03:02:40,640 --> 03:02:43,670 know worrying about that same risk. And 466 03:02:43,680 --> 03:02:45,190 then you we you we've been able to find 467 03:02:45,200 --> 03:02:47,750 this to actually uh come to a reasonable 468 03:02:47,760 --> 03:02:50,309 conclusion as well. So what does this 469 03:02:50,319 --> 03:02:53,590 all add up to for us? We think that your 470 03:02:53,600 --> 03:02:55,269 infrastructure needs to be branchable 471 03:02:55,279 --> 03:02:57,750 and that's what we're building with Neon 472 03:02:57,760 --> 03:02:59,670 with data bricks. Uh and we're super 473 03:02:59,680 --> 03:03:01,190 excited about that branchable future 474 03:03:01,200 --> 03:03:02,710 because we think that teams are going to 475 03:03:02,720 --> 03:03:05,269 be the next generation of agents both 476 03:03:05,279 --> 03:03:07,110 for software and the way that we 477 03:03:07,120 --> 03:03:11,000 actually build products. Thank you.