Building AI Agents Enterprises Will Actually Trust | Mayada Gonimah, Thread AI

1 - > SPEAKER_03: A lot of the agents and workflows that we build are 2 - > mostly focused around mission critical multi-step processes 3 - > that often involve different kinds of personas. 4 - > So they're not agents for just end-to-end knowledge work that 5 - > usually starts and ends with a person. 6 - > They're usually multi-step processes. 7 - > So think of things like invoice processing, end-to-end invoice 8 - > processing and correction, or diligence reporting, or 9 - > different kinds of multi-step monitoring systems.

10 - > SPEAKER_00: Most podcasts talk to founders after the story is 11 - > already written. 12 - > When the latest trade is announced, the product has 13 - > shipped and the narrative is clean. 14 - > SPEAKER_01: We wanted to find out why they decided to take the 15 - > founder leap in the first place. 16 - > What idea captured their imagination and how they handle 17 - > the pressure to build?

18 - > Welcome to First Commit. 19 - > I'm Laura Hamilton. 20 - > SPEAKER_00: I'm Elie Lone and we're investors at Federal 21 - > Capital. 22 - > We spend a lot of time with technical founders who are on 23 - > the cutting edge.

24 - > If you're thinking about what it's like to start a company in 25 - > the AI era, this one's for you. 26 - > SPEAKER_02: This is First Commit. 27 - > Let's get into it. 28 - > Today we are chatting with Maya from Thread AI.

29 - > Maya is the co-founder and CTO working on AI native 30 - > orchestration. 31 - > Welcome, Maya. 32 - > It's great to be here. 33 - > It's great to have you.

34 - > So you came up through Goldman Sachs and built the digital 35 - > subscriptions platform at the New York Times before landing at 36 - > Palantir. 37 - > It would be great if you could touch on the thread connecting 38 - > all those experiences and when you knew that you wanted to 39 - > branch off on your own. 40 - > SPEAKER_03: Yeah, so I've spent, I want to say, the majority of 41 - > my career working in across various regulated spaces and 42 - > enterprises. 43 - > So yeah, when I started my career at Goldman Sachs, I was 44 - > primarily an infrastructure backend engineer, building 45 - > software for various business divisions and prime brokerage 46 - > and futures trading.

47 - > So there was always this emphasis on security and data 48 - > governance and understanding basically how to build software 49 - > at scale. 50 - > And that's been the theme. 51 - > So even when I went to go work at the New York Times, I spent a 52 - > good chunk of my career building out their payment systems. 53 - > And so working directly with auditors and making sure that 54 - > the infrastructure that we built is PCI compliant among other 55 - > types of compliance.

56 - > And similarly, the work that we've done at Palantir has been 57 - > working with not just large government agencies like the 58 - > defense, but also working with other large enterprises. 59 - > And that's been the theme, whether we're building AI native 60 - > software or other kinds of software. 61 - > I spent a lot of my career working in these regulated 62 - > spaces. 63 - > So understanding their needs, and that has really helped shape 64 - > the experience of how we think about building software at 65 - > ThreadAI, understanding enterprises from basic 66 - > principles and building software that fits their needs, as 67 - > opposed to building a proof of concept and then trying to 68 - > retrofit enterprise features into it.

69 - > SPEAKER_02: Yeah, that's great. 70 - > We'll definitely get into how you're focusing on AI 71 - > orchestration and what that means at Thread. 72 - > But before that, I would love to dive deeper into your work at 73 - > Palantir. 74 - > So as you mentioned, you were building infrastructure that 75 - > ended up in the hands of the DoD, but didn't get the 76 - > clearance to see your work deployed.

77 - > I would love to hear more about that story and kind of what that 78 - > did psychologically to maybe fuel the fire. 79 - > SPEAKER_03: It was definitely a very interesting experience. 80 - > So when I joined Palantir, I was not yet, like you mentioned, a 81 - > US citizen. 82 - > There were many cases where I had to build a lot of software, 83 - > and I oftentimes would not see how it would get deployed in the 84 - > field.

85 - > And I think the main thing that has enforced is obviously 86 - > working in a team with high trust. 87 - > So I spent a lot of time working with my now co-founder, Angela. 88 - > At the time, she had the clearance and access to the 89 - > problems at the edge, and it really helped forge this strong 90 - > work relationship. 91 - > But also the main thread here is when you're building software, 92 - > especially infrastructure, there's certain kinds of 93 - > reliability guarantees and feature sets that we have to 94 - > make sure exist so that you can have the peace of mind where 95 - > knowing regardless of where your software is deployed, it is 96 - > functioning according to whatever invariance that you've 97 - > set.

98 - > So there is a certain quality and certain bar that you have to 99 - > make sure that each feature holds. 100 - > And it's almost like building like a database. 101 - > You can't simply assume that people are going to retry 102 - > certain things or people are going to assume certain DevX or 103 - > UX because you have to make sure that the software, however way 104 - > it is used, it is always acting deterministically, or it is 105 - > always surfacing the kinds of metrics and enforcing the 106 - > certain feedback loops where it is behaving the same way whether 107 - > it is deployed in low side or deployed on the moon or deployed 108 - > wherever it is deployed.

109 - > SPEAKER_02: Okay. 110 - > So then when you were at Palantir working with Angela, 111 - > how did you know that one, she was the right person to work 112 - > with, and two, that it was time to leave? 113 - > SPEAKER_03: We spent a lot of time working together on a lot 114 - > of different projects. 115 - > So she's also very technical.

116 - > Her background is also engineering. 117 - > And the interesting part is a lot of I think our skill sets is 118 - > a nice Venn diagram. 119 - > Whereas my background has been mostly spent in distributed 120 - > systems and infrastructure. 121 - > Her background has been mostly spent in working with data and 122 - > intelligence systems.

123 - > So that kind of like gave us a nice complete skill set of the 124 - > things that you need to be able to build the kinds of software 125 - > that you want to build across working closely with data and 126 - > understanding data and working across infrastructure and 127 - > deploying that in various kinds of modalities. 128 - > And I think working at Palantir, we've learned a lot. 129 - > You get access to crazy problems that maybe other software 130 - > companies would not put engineers at the front line of.

131 - > Oftentimes, a lot of software companies have many layers of 132 - > abstractions away where there are the solutions architects and 133 - > the different operational layers and the different kinds of 134 - > testing. 135 - > Whereas Talentier, they take bets on very strong autonomous 136 - > software engineers. 137 - > And oftentimes you'll find yourself meeting people that 138 - > normally you wouldn't at any other tech company. 139 - > And to your question around when did we think it was time to 140 - > leave?

141 - > I think that was around spring of 2023. 142 - > And the market was very exciting. 143 - > There was a lot of exciting things happening across 144 - > different kinds of ML and language models. 145 - > And I think we had a lot of conviction, knowing that we've 146 - > known how to work together.

147 - > For us, that was almost more important than sometimes like 148 - > the specific idea. 149 - > Because like we knew that whatever it is that we built, we 150 - > know how to make it work. 151 - > We spent a lot of time building horizontal infrastructure. 152 - > And I think being excited about working together was almost, I 153 - > would say, like more important than what idea we had at the 154 - > time.

155 - > SPEAKER_02: Was there anything psychologically or EQ test that 156 - > you ran just to ensure the partnership would be what you 157 - > had in mind? 158 - > SPEAKER_03: I think I would say working closely together for 159 - > over four years kind of like gave that. 160 - > It's very challenging to take these large bets with someone 161 - > that you've just met, mostly because you will be put in very 162 - > difficult situations and oftentimes situations that will 163 - > test your character.

164 - > So knowing how you work very intimately with someone and 165 - > making sure that your communication skills line up, 166 - > whether it is how you how you surface disagreement or how you 167 - > resolve conflicts or how knowing which problems and which hills 168 - > to die on. 169 - > And uh, and as long as I guess like uh co-founders know how to 170 - > work that out, I think that is the most important thing. 171 - > But I think, yeah, a lot of it uh came, I guess like for us, we 172 - > were lucky because we were tried and tested already in previous 173 - > kind of like lives, and that gave us kind of like the data 174 - > points.

175 - > But again, that's not to say that starting a company isn't a 176 - > completely different beast, but at least you'll have kind of 177 - > like a lot of the data points already if you've worked with 178 - > someone that closely and within that capacity, which is 179 - > different also from in some cases folks will think that they 180 - > if they start a company with their friends, they know their 181 - > friends and nothing really that's a very For sure. 182 - > SPEAKER_02: And it I mean it's very daunting to leave a safe 183 - > job that you're enjoying and you're still learning a ton, and 184 - > to start a company with someone but you don't know what you're 185 - > starting yet.

186 - > When you're thinking about brainstorming, how did you seek 187 - > validation about early proof points that thread would be what 188 - > it is today? 189 - > Or maybe you started with a different idea. 190 - > SPEAKER_03: We were fortunate in that I would say we haven't 191 - > pivoted from when we started. 192 - > So a lot of the time that we spent at Pound Tier was mostly 193 - > building ML ops, to building model training, model inference, 194 - > model evaluation systems.

195 - > And we knew that we did not want or could not even build whatever 196 - > it is that we build at Pound Tier for various different 197 - > reasons, but also that was not the space that we wanted to be 198 - > in. 199 - > We were very interested in everything that happened 200 - > downstream of that. 201 - > So everything downstream of ML ops because we knew that models 202 - > will continue to be more ubiquitous, more available. 203 - > There will be a lot of interesting things, the model 204 - > will continue to improve, there will always be like model drops 205 - > every week.

206 - > But the hypothesis was that enterprises will still have very 207 - > unique challenges operationalizing these models 208 - > for different kinds of reasons. 209 - > And the models cut across infrastructure and application 210 - > layer. 211 - > They they now are mixing and matching multimodality, which, 212 - > like in previous worlds, that was that was almost like 213 - > completely separate infrastructures. 214 - > And we've really admired what some of the orchestration 215 - > companies have done.

216 - > So around 2023, we knew that companies like Temporal and 217 - > Conductor have solved for a lot of the durability and core 218 - > orchestration problems. 219 - > But at the time, we noticed that they haven't solved for the 220 - > non-determinism that comes with AI models. 221 - > So we thought there's a lot of market for in that space. 222 - > And we were also really inspired by that tool former paper that 223 - > came out of Meta, I think early 2023.

224 - > And that but that paper was mostly focused around language 225 - > models and giving them access to tools. 226 - > We knew that enterprises were not going to train specific on 227 - > specific APIs, but we thought a lot of the ideas behind that 228 - > paper were very interesting, almost interesting enough for 229 - > someone to quit their job. 230 - > And I think that paper was almost like the inception of a 231 - > lot of what we see right now: things like function calling, 232 - > tool calling, MCP and agent.

233 - > And that's been kind of like that space that's now getting a 234 - > lot of traction. 235 - > But we knew basically to be able to do that for a large 236 - > enterprise. 237 - > And not understanding like the enterprise ecosystem, which 238 - > oftentimes has a lot of legacy systems, has a combination of 239 - > vertical software, has different kinds of like data problems. 240 - > Being able to build these kinds of agents that meet enterprise 241 - > guarantees is a very hard problem.

242 - > But and usually hard problems have like decent markets. 243 - > SPEAKER_02: And I would love to touch on what types of agents 244 - > you're building for the enterprise. 245 - > Because I can imagine there's some use cases where you're 246 - > seeing parallelism between one enterprise and another and more 247 - > software, but I can imagine a lot of use cases could be more 248 - > services heavy. 249 - > So I'm curious how you balance the services versus software 250 - > approach at thread.

251 - > SPEAKER_03: We've learned a lot and again, how what works well 252 - > with the forward deployed, what doesn't work well with the 253 - > forward deployed model. 254 - > And for us, when we started, it was always we knew we always 255 - > wanted to build a product and a platform. 256 - > But obviously, there is always kind of like some customization 257 - > that has to happen. 258 - > But oftentimes, enterprises are also, if you teach them and 259 - > they're they are willing to work on these specific 260 - > customizations.

261 - > So you can always kind of like sometimes push back on some of 262 - > these specific bespoke customizations and have the 263 - > customer own a lot of that. 264 - > A lot of the agents and workflows that we build are 265 - > mostly focused around mission critical multi-step processes 266 - > that often involve different kinds of personas. 267 - > So they're not agents for just end-to-end knowledge work that 268 - > usually starts and ends with a person. 269 - > They're usually multi-step processes.

270 - > So think of things like invoice processing, end-to-end invoice 271 - > processing and correction, or diligence reporting, or 272 - > different kinds of multi-step monitoring systems, or triaging 273 - > workflows that involve mechanics in the field. 274 - > And oftentimes you these workflows have data capture, so 275 - > things from physical systems, and they often will require you 276 - > to run large workloads asynchronously, and then they'll 277 - > sometimes require an investment in a human of the loop.

278 - > So usually a person who has domain expertise. 279 - > So they're not necessarily the person, the builder, the person 280 - > who created the workflow. 281 - > They're not necessarily like that kind of persona, but they 282 - > oftentimes are the domain experts. 283 - > So let's say you're it is an insurance claim processing 284 - > workflow, they would be the ones who have go or no go and around 285 - > the outputs of the models.

286 - > So they basically would stop when the workflow stopped and 287 - > their feedback is solicited, they would know whether to 288 - > correct it or deposit or to reroute it. 289 - > And then basically a lot of these workflows oftentimes will 290 - > push out data to the customers' things, whether it's their own 291 - > data lake or like some kind of notification system. 292 - > And our infrastructure makes it very easy to swap in and out 293 - > models to create. 294 - > We've invested a lot in the separation of data and compute, 295 - > so creating a very interesting context layer.

296 - > So we handle a lot of the data movement that comes with that 297 - > data entry and eviction and help enterprises basically connect 298 - > that to their systems. 299 - > So oftentimes these workflows are long-running, multi-step, 300 - > and involve different kinds of personas interacting with them. 301 - > SPEAKER_02: Got it. 302 - > And how do you gain the enterprise's trust?

303 - > You know, you're now a series A startup, but previously you were 304 - > a C stage startup and you're selling to massive 305 - > organizations. 306 - > So what did that take? 307 - > SPEAKER_03: It is challenging selling to enterprise. 308 - > The contracting cycles are very long.

309 - > We've had cases where some contracts were closed within a 310 - > week, other cases where it's taken us over two years to 311 - > redline a particular contract. 312 - > And I think some of it again is since we've spent over decades 313 - > in the space working with enterprises. 314 - > So building upon kind of like trust that we've demonstrated in 315 - > these areas in the field. 316 - > And some of it is also from the beginning, we've really invested 317 - > in a lot of the security and data governance and like a 318 - > platform layer investments when some might argue, oh, you've 319 - > done that before product market fit.

320 - > So a lot of kind of like every startup, I guess, journey is 321 - > unique, but in some cases, folks will think you have to follow 322 - > the specific playbook of you put out an MVP, like that doesn't 323 - > work anymore. 324 - > Or what is an MVP is very different for us versus other 325 - > companies. 326 - > So for us, we had to be on multi-cloud. 327 - > So like for some companies, they never even deploy more than one 328 - > cloud.

329 - > So we're deployed on all three clouds. 330 - > We've had to chase a lot of the different compliances, whether 331 - > the GDPRs, the HIPAA, and like we had to implement regional 332 - > support, which for a lot of companies that is a big lift. 333 - > But if you're an infrastructure company, that is table six. 334 - > So I think some of these early investments have paid out.

335 - > And as opposed to trying to build everything in like one 336 - > microservice and trying to prove what a simple MVP is, I think 337 - > people are that no longer holds water. 338 - > SPEAKER_02: And you mentioned the FDE model, something that 339 - > you're leveraging. 340 - > FDE seems to be the new AI engineer title in the sense of 341 - > everyone's hiring FDEs right now. 342 - > What is your definition of an FDE?

343 - > And have there been any learnings of like what's worked 344 - > or what hasn't worked? 345 - > SPEAKER_03: So we call them, like you said, applied AI. 346 - > So we have various kinds of there's applied AI data science, 347 - > applied AI engineers, and applied AI strategists. 348 - > And the idea is these folks are engineers or come from strong 349 - > backgrounds, either either across different sciences or 350 - > other kind of like fields where they've demonstrated a strong 351 - > track record.

352 - > But these folks are basically at the edge of the problem. 353 - > They're not necessarily building the engine that is behind Lemma, 354 - > but they are building with Lemma and they they have the intimate 355 - > understanding of the enterprises' APIs and data 356 - > problems, and they can basically go from very raw customer 357 - > requirements and draw them onto the platform in a way that still 358 - > kind of like holds attention of making sure the customer is set 359 - > up for success, but also in a way that optimizes for how our 360 - > platform is built.

361 - > So they understand basically how the data movement should go or 362 - > push for which particular kind of like workflow or component or 363 - > template, or they also understand which models to use 364 - > when. 365 - > But parts of the stack where understanding the messy data, 366 - > messy customer requirements, or like operating on imperfect 367 - > information, that is not a solved problem yet. 368 - > But we'll see kind of like how that shakes out. 369 - > SPEAKER_02: How long are the engagements when you typically 370 - > send like an FDEN to work with a customer?

371 - > SPEAKER_03: Again, it depends on the customer readiness. 372 - > So if you're working with a customer and they are quote 373 - > unquote AI or data ready, they have their data cleaned and 374 - > their processes mapped out, that should be very quick. 375 - > Our platform is self-service, so you can get a tenant set up and 376 - > running in like a matter of minutes. 377 - > But if you're working with cases where the landscape kind of like 378 - > you're helping kind of like shape and organize how the data 379 - > should be organized, or cases where the customer, maybe some 380 - > of the existing workflows or legacy systems don't actually 381 - > have APIs or don't have, or for sometimes for political reasons, 382 - > like they're working with a number of different vendors and 383 - > they don't want to give you access to some data, obviously, 384 - > some of that is challenging.

385 - > And like for that, there's different kinds of ways of 386 - > building out these workflows. 387 - > So in cases where everything's great, data's ready, APIs are 388 - > there, it should be like self-service. 389 - > But cases where you have to work with understanding if like that 390 - > problem is actually the right problem to solve and there's a 391 - > lot of iteration on the data, or for whatever reason, you are not 392 - > getting access to all the data that you thought you were going 393 - > to get access to, then it becomes a little bit more 394 - > challenging and could take up some time.

395 - > SPEAKER_02: How have you learned what customers to say no to in 396 - > the sense of you're working with pretty risk-averse buyers and 397 - > financial services, public safety, healthcare? 398 - > And I can't imagine everyone's a good fit for Lemma, but 399 - > obviously you want to try to service these potential large 400 - > ACVs. 401 - > SPEAKER_03: So yeah, a lot of the customers that we we're 402 - > mostly prioritizing enterprise use cases, and these tend to 403 - > have different kind of like a shape of a of a contract in 404 - > cases where a lot of the problems can be solved with you 405 - > know simple knowledge work or kind of like the latest and 406 - > greatest tooling, like or where it doesn't make sense to deploy 407 - > this kind of infrastructure, or it could be like an overkill 408 - > kind of solution, and those cases where we would basically, 409 - > yeah, like either direct the customer to like even if it's a 410 - > competitor, be like this problem can actually be solved um this 411 - > way.

412 - > But cases where you actually need the different auditability 413 - > and data governance and reliability and and the control, 414 - > those are the ones that are best suited for our platform. 415 - > SPEAKER_02: And are they typically comparing you all to 416 - > something they have internally? 417 - > Then if you look ahead five, 10 years, what does agent 418 - > orchestration look like? 419 - > SPEAKER_03: So I think it's it's a very exciting and interesting 420 - > space.

421 - > And I think we're seeing kind of like a lot of entrants, which 422 - > usually is good market validation, the only person 423 - > building a particular kind of a problem. 424 - > But but I think what's very exciting for us is being able to 425 - > cut across systems that are legacy and put some of these 426 - > like very powerful building blocks in the hands of a lot of 427 - > these users. 428 - > And I think a lot of interesting things are happening now, 429 - > cutting across the application and the infrastructure layer, 430 - > and how you seamlessly bring that surface that up all the way 431 - > to the apply to the end user experience is going to be very 432 - > interesting.

433 - > So, like things where there's certain things that are 434 - > completely like you're dealing with like ingress and egress and 435 - > VPNs and like peering and like a lot of these like networking 436 - > constraints, but at the same time, your end user is might not 437 - > be as familiar with these. 438 - > So, how do you intentionally surface some of these nouns in a 439 - > way that empowers that end builder without having them know 440 - > and spend years basically like understanding distributed 441 - > systems or like networking?

442 - > And yeah, I think it's gonna be a lot of fun also combining kind 443 - > of like seeing how some of the coding tools has disrupted kind 444 - > of like the software development lifecycle. 445 - > And how do we bring some of these tools across these 446 - > different kinds of systems in a way that is still gives you the 447 - > control and without completely like giving up autonomy? 448 - > So that's been kind of like a very interesting theme for us. 449 - > This idea of controlled autonomy.

450 - > How do we have these workflows, these long-running self-haling 451 - > workflows that still you still have control, you still see what 452 - > is happening and you still maintain the kill switches and 453 - > the guardrails and potentially the cost constraints across 454 - > them, but still have them run and do work for you without 455 - > basically destroying your system. 456 - > SPEAKER_02: Have you seen anything gone wrong yet when 457 - > you've been deploying using these autonomous systems, or is 458 - > it too early?

459 - > SPEAKER_03: Basically, the way we've built our infrastructure, 460 - > our platform, Lemma is making sure that we continue to 461 - > maintain these controls around execution and plan generation. 462 - > Because, like oftentimes, there are these checks and balances 463 - > with the kinds of workflows that we build. 464 - > There's cases where you Want your agents to run completely 465 - > autonomously, or if you've defined kind of like either a 466 - > cost constraint for them or like certain system boundaries, you 467 - > could do that.

468 - > But in many cases, we take a very strong stance around 469 - > separating the execution from the generation. 470 - > And I guess like a little bit of implementation detail. 471 - > So often, so even when so our platform also supports like 472 - > importing MCP servers, for example, but we take a very 473 - > glass box approach where you know exactly which tools could 474 - > be invoked or will be invoked, and you can select and remove 475 - > like certain tools versus kind of like pulling in an entire 476 - > server and giving it full control with natural language.

477 - > You could do that, but oftentimes we will surface what 478 - > is actually happening because we want to push our users to know 479 - > what is happening in their system. 480 - > That makes sense. 481 - > SPEAKER_02: I would love to switch gears slightly and chat 482 - > about hiring and how you've thought about building a team. 483 - > The AI talent war is real and it's extremely competitive.

484 - > And you guys have scaled from single to double-digit folks in 485 - > a very short amount of time. 486 - > And so I'm curious how you've thought about hiring, 487 - > specifically building in New York. 488 - > SPEAKER_03: So we're very much New York-based company. 489 - > We've actually made a lot of folks relocate.

490 - > It's very bullish on the New York market and talent. 491 - > But obviously, as we grow, some of these strong beliefs might 492 - > change. 493 - > And we'll think about kind of like what growing across other 494 - > regions look like. 495 - > But for us, from the get-go, we try to focus on folks who are 496 - > very strong at fundamentals, distributed systems, 497 - > fundamentals.

498 - > There's often cases where we're happy to teach people quote 499 - > unquote the AI or a lot of like the new, the latest and greatest 500 - > tooling, as long as they have a deep bench in a particular area. 501 - > Obviously, with different roles. 502 - > If you're a data scientist, there's specific things for, and 503 - > if you're a back-end or infrastructure engineer, there's 504 - > other things. 505 - > But generally look for folks who take pride in strong ownership.

506 - > They're very hungry, very excited about the space, and 507 - > have very strong fundamentals. 508 - > Our process isn't very different, but there's some 509 - > cases where we've borrowed from some of the best like tech 510 - > companies, and some some cases where we borrowed from very 511 - > unique, forward-deployed kind of like types of thinking and how 512 - > we evaluate people. 513 - > So folks need to be able to build things for planet scale, 514 - > but still be able to hold that tension.

515 - > If you need to deliver something within a week, you understand 516 - > what assumptions you're making and you know how to unwind them 517 - > and turn it into a real product. 518 - > So folks who are comfortable delivering under very different 519 - > kinds of circumstances, but they know the depth of what that 520 - > looks like. 521 - > And a lot of tech companies now are also fundamentally changing 522 - > their interview process to account for how software is 523 - > changing.

524 - > But again, like a lot of that is you're still looking for folks 525 - > who want to dig into the details, want to take systems 526 - > apart, are very strong communicators, and are not 527 - > scared of owning end-to-end outcomes, even if it touches 528 - > systems that maybe that is not kind of like their main area of 529 - > expertise. 530 - > SPEAKER_02: This profile seems popular right now amongst a lot 531 - > of your competitors and some of the big tech companies.

532 - > So how do you think about winning candidates? 533 - > SPEAKER_03: It is, yeah, it is kind of like a fun talent war. 534 - > But a lot of cases where we've won is we have access to a lot 535 - > of problems that oftentimes it takes an enterprise years to get 536 - > access to. 537 - > Whether it's working across the US government or some of the 538 - > largest companies in the world, oftentimes startups will not 539 - > have access to these problems.

540 - > And I think many cases where we've seen kind of like we've 541 - > won candidates over others, folks have been motivated by 542 - > these hard problems that cut across systems and working with 543 - > like folks who have a very strong track record. 544 - > So, like on the team, we have folks who worked at some of the 545 - > best and some of the largest companies in the world and built 546 - > systems like App Engine or Twilio's workflow studio engine, 547 - > and as well as some of the other folks we worked with at 548 - > Palentier.

549 - > SPEAKER_02: How have you thought about stepping into a new 550 - > managerial like leadership role? 551 - > How have you learned to lead teams and to rally folks around 552 - > you? 553 - > And maybe if you've made any mistakes or have any stories to 554 - > share? 555 - > SPEAKER_03: So both Angela and I from Palantir days have all have 556 - > had more people leads in addition to being ICs.

557 - > And I think that is a strong kind of like tenet that we hold, 558 - > not we we always we don't believe in just having middle 559 - > management. 560 - > Everyone in the company is a builder, so it doesn't matter 561 - > that your level of seniority or tenure. 562 - > Um yes, you might be people lead and in charge of helping growing 563 - > others, but at the heart of it, you're still a builder, you're 564 - > still tinkering with systems, whether it's if you're still 565 - > writing code or prototyping or writing RFCs, we push for folks 566 - > who continue to have that muscle as opposed to just managing 567 - > folks.

568 - > And I think that's kind of like been the model in which we lead 569 - > people because people often want to see that you are leading by 570 - > example, you can step in and they can trust you as a leader. 571 - > And it's and it's exciting now. 572 - > We're seeing a lot of people return back to writing and 573 - > building code with basically a lot of the tooling that's 574 - > available right now, where some problems may have been now too 575 - > abstracted away, or like we're seeing like a lot of leadership 576 - > return to basically building.

577 - > SPEAKER_02: What is your role distribution of a building 578 - > versus a managing at this point? 579 - > And the what point in a company's growth does it tend to 580 - > shift? 581 - > SPEAKER_03: I guess right now, since we're a very flat 582 - > organization, and would say the majority of the company reports 583 - > to me and Angela, lopsided, but it'll be kind of like 584 - > interesting to see how we scale and grow the team that we've 585 - > built with us. 586 - > I would say, yeah, we try to still pretty much active.

587 - > So we had a hackathon last Friday, and basically a lot of 588 - > us, yeah, participated, which is kind of like exciting. 589 - > And I think being intentional around the time split, I think 590 - > will be important as we grow. 591 - > And probably at some point we will not have everyone reporting 592 - > to us. 593 - > SPEAKER_02: Yeah.

594 - > SPEAKER_03: But no, that makes a ton of sense. 595 - > SPEAKER_02: So the agentic wave, as you know, is moving 596 - > incredibly fast. 597 - > I'm curious, where do you think the enterprise infrastructure 598 - > layer settles? 599 - > Do you think it's winner take all, or do you think it's a bit 600 - > more fragmented than that?

601 - > SPEAKER_03: I guess there will continue to be room for a lot of 602 - > different fragmentation. 603 - > Obviously, there's a lot of folks who have made investments 604 - > in their different hyperscalers and the tooling within that 605 - > because the economics kind of like makes sense. 606 - > But there are very much a lot of systems now that are being 607 - > rebuilt from the ground up. 608 - > For us, the the nice part about our infrastructure is 609 - > oftentimes, like with enterprises, you don't have to 610 - > blast your stack in order to use or start building safely with 611 - > AI, which has been kind of like the main nice entry point for us 612 - > because telling an enterprise you have to redo your whole 613 - > stack is sometimes like a non-starter.

614 - > But there's gonna be like an interesting wave right now where 615 - > there's a lot of folks who think with the coding tools that they 616 - > can build everything. 617 - > So there's a little bit of an overcorrection of a lot of folks 618 - > building in-house, and then there's gonna be like market 619 - > correction. 620 - > It's like almost like the reinvention of SAS. 621 - > There are some things people realize actually, no.

622 - > I mean, because writing code wasn't that really the hard 623 - > problem, but like the last 10% is the hardest problem. 624 - > Putting it in production and knowing that it's gonna scale or 625 - > it's not gonna fail at 3 a.m. 626 - > or under these certain constraints it's gonna recover.

627 - > That is always kind of like has been the annoying problem. 628 - > But I think right now there's like a lot of hype and buzz 629 - > where everyone thinks they can build everything, which is which 630 - > is great and exciting. 631 - > But there's gonna be kind of like I think Q three or four big 632 - > kind of like collapses or big large security kind of like 633 - > problems. 634 - > I'm already seeing it.

635 - > Yeah. 636 - > And then the market will naturally correct itself. 637 - > And I think like, yeah, companies that have demonstrated 638 - > that they've earned the right to be in this space will continue 639 - > to be in this space. 640 - > And then there's gonna be a lot of companies like will shut 641 - > down.

642 - > SPEAKER_02: What are the like roles that you're hiring for 643 - > right now? 644 - > Any ending thoughts that you have? 645 - > SPEAKER_03: We're very excited. 646 - > I think we've put up now a couple new exciting roles across 647 - > the business operations side of the house and also the federal 648 - > side of the house.

649 - > We've done the hard work of going from zero to one across 650 - > federal, and now we're looking for folks who are experts and 651 - > can scale the machine with us. 652 - > And of course, always looking for strong engineers and across 653 - > Apply. 654 - > Awesome. 655 - > Well, thank you so much for coming on, Maya.

656 - > Awesome. 657 - > Thank you for having me. 658 - > This was great.