Code generation gives Serval a path to replace ServiceNow

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

1. 10:00

   understand how we'd beat the other companies and why we had an advantage and 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 co-founder and my co-founder really had 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 And these drag and drop workflow builders is a painful level of abstraction because it's too complex for non-technical users and it's annoyingly abstracted for technical users.

2. 10:36

   Code is a better way of building automation. The problem, obviously, is not many people can write code and do it quickly enough for it to make sense for automation. And so as AI made this possible, that was what 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?

3. 10:59

   It's actually taking on these massive legacy software companies like ServiceNet. 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. To be very clear, like this is a brilliant idea. But in practice, when we started building this. Yeah. What was the assumption? Was it that 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?

4. 11:20

   I'm sort of curious of that transition. The bet was that coding agents would get very good. And the theory there was it's a verifiable domain 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.

5. 11:52

   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 want to build a password reset workflow. And so 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.

6. 12:16

   It became hard for you to give it a workflow that it couldn't automate if the APIs existed. 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? We're 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. So 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

7. 13:00

   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 want to 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.

8. 13:31

   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. Why is it going to happen? Because I think if you think about, you know, I might safely give you more permissions that you need because I don't actually think you're going to do all that much damage. But if you have access to all these agents, then the damage you can do with any kind of slightly elevated beyond normal permissions expands. And we're seeing this in cybersecurity risk right now. Absolutely. And so what I'm actually going to want to do if I'm a large enterprise is shrink everyone's permissions down to truly least privilege. You cannot access any document and you cannot take any action unless you absolutely need to do it for your job.

9. 14:10

   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,