No Priors: Artificial Intelligence | Technology | Startups
00:09:53 · Elad Gil, Jake Stauch
[00:09:53] S1: How'd you choose this versus Salesforce server? You know, [00:09:55] S0: there's a few other sort of canonical giant companies in different categories. I think we didn't really understand how we'd beat the other companies, and why we had an advantage, and what what AI unlocked that they couldn't catch up to. And what we understood about ServiceNow because of our experience with IT is that fundamentally, it is a workflow automation platform. And our belief, me and my cofounder, and my cofounder really had this this idea early on that code was the right way to express automation in the enterprise, that you should just build all automations in code, and these drag and drop workflow builders is a painful level of abstraction because it's too complex for nontechnical users, and it's annoyingly abstracted for technical users. Code is a better way of building automations. The problem, obviously, is not many people can write code and and do it quickly enough for it to make sense for automation. And so as AI made this possible, that was what it clicked for both of us, that actually, if code is the right way to build automation and now anyone can write code, we can build a better automation platform. And what is an automation platform is actually... What is the best market for an automation platform? It's actually taking on these massive legacy software companies like ServiceNow. [00:11:02] S1: I guess two and a half years ago when you got started, though, most of the coding stuff was sort of tab complete. It did not work. Yeah. And so To
00:11:02 · Elad Gil, Jake Stauch
[00:11:02] S1: I guess two and a half years ago when you got started, though, most of the coding stuff was sort of tab complete. It did not work. Yeah. And so To [00:11:08] S0: be very clear, like, this is a this is a brilliant idea. Yeah. But in practice, when we started building this [00:11:13] S1: Yeah. What was the assumption? Was it that the the coding would get much better? Was it that you'd build tooling and that you didn't need to because things got so good? I'm sort of curious of that transition.
00:11:13 · Elad Gil, Jake Stauch
[00:11:13] S1: Yeah. What was the assumption? Was it that the the coding would get much better? Was it that you'd build tooling and that you didn't need to because things got so good? I'm sort of curious of that transition. [00:11:22] S0: The bet was that coding agents would be... Would get very good. And the theory there was it's a verifiable domain, and and it should actually hill climb fairly well. And so we believed fundamentally that coding agents would get good, at least for these very... I didn't expect them to get as good as they are for just general purpose software development, but for deterministic procedural scripts of reset password, get approval, like, all of these things are just so defined and verifiable that we felt like it would get good at those things. And so from a workflow automation perspective, we thought it would get there. In the early days, it did not. So what we ended up doing in all our early demos, we would prompt the LLM and say, hey. Here's a suggested way you might wanna build a password reset workflow. And so we'd we'd we'd seed it with, like, a lot of examples, and then over time, we'd make that library bigger and bigger. But then the models just got so good that eventually, it became hard to break. It became hard for you to give it a workflow workflow that it couldn't automate if the APIs existed. Yeah.
00:11:22 · Jake Stauch, Sarah Guo
[00:11:22] S0: The bet was that coding agents would be... Would get very good. And the theory there was it's a verifiable domain, and and it should actually hill climb fairly well. And so we believed fundamentally that coding agents would get good, at least for these very... I didn't expect them to get as good as they are for just general purpose software development, but for deterministic procedural scripts of reset password, get approval, like, all of these things are just so defined and verifiable that we felt like it would get good at those things. And so from a workflow automation perspective, we thought it would get there. In the early days, it did not. So what we ended up doing in all our early demos, we would prompt the LLM and say, hey. Here's a suggested way you might wanna build a password reset workflow. And so we'd we'd we'd seed it with, like, a lot of examples, and then over time, we'd make that library bigger and bigger. But then the models just got so good that eventually, it became hard to break. It became hard for you to give it a workflow workflow that it couldn't automate if the APIs existed. Yeah. [00:12:21] S2: When you think about where coding agents are today and what your customers want, like, what are you... Are you and Alex excited about them getting better from here? Are you nervous? Like, what do you think it looks like in terms of impact on your own product?
00:12:21 · Sarah Guo, Jake Stauch
[00:12:21] S2: When you think about where coding agents are today and what your customers want, like, what are you... Are you and Alex excited about them getting better from here? Are you nervous? Like, what do you think it looks like in terms of impact on your own product? [00:12:36] S0: We are so excited for them to get better because I think it unlocks a lot of the things that we'd love to do around, you know, better browser use and computer use and more of a approach to background agents and personal agents that can be really useful in the enterprise. We're excited for the evolution of the category. We've always believed fundamentally that we are not building the LLMs ourselves. We are building the guardrails. We are building the the boundaries. And the boundaries are the product for us, Because we are the way that a large enterprise, with a lot of rules and approvals and process and politics, can adopt these tools safely and comfortably at scale. And so Serval is the boundary. Serval is the guardrails. The intelligence getting better just makes our product more powerful, and also makes our customers wanna actually clamp down even further on those boundaries, on those guardrails. And I actually think access is going to get more and more controlled for individuals in the enterprise. And as access becomes stricter, and you let people do less and less and your permissions get more and more narrow, which I think is going to happen [00:13:39] S2: Why is it gonna happen?
00:13:39 · Sarah Guo, Jake Stauch
[00:13:39] S2: Why is it gonna happen? [00:13:40] S0: Because I think if if you think about... You know, I might safely give you more permissions than you need because I don't actually think you're gonna do all that much damage. [00:13:47] S2: Uh-huh. [00:13:47] S0: But if you have access to all these agents, then the damage you can do with any kind of, like, slightly elevated beyond normal permissions expands. And and we're seeing this in cybersecurity risk right now. [00:13:58] S2: Absolutely. [00:13:59] S0: And and so what I'm actually gonna wanna do if I'm a large enterprise is shrink everyone's permissions down to truly least privilege. Like, you cannot access any document, and you cannot take any action unless you absolutely need to do it for your job. But then you're going to have exceptions all the time. We are the layer that grants those exceptions and makes it possible for you to set up approval procedures around that, have an audit trail and a ticket associated with that. So by owning how privileges get escalated in the enterprise, we actually become more powerful and more essential the more you clamp down on end user permissions. [00:14:31] S2: Is there, like, a story or a win you can share as to... You know, people would be taking a big risk going with you to replace a very embedded incumbent. Right? It's a investment of their own time. I assume it's, like, personal risk. Like, why do that, or is there is there an experience where people have already gone through to the other side?