Skip to content
No PriorsNo Priors

Taking on ServiceNow: Coding Agents for the Rest of Us with Serval Co-Founder and CEO Jake Stauch

What happens when you put code-generation agents in the hands of enterprise IT teams? With Serval, you get a system where it's easy for everyone to be a builder. Sarah Guo and Elad Gil sit down with Serval co-founder and CEO Jake Stauch to analyze his company’s direct challenge to ServiceNow as the enterprise automation and service management system of record. Jake explains that by building an AI platform for enterprise IT departments with Serval, users can safely build while still safeguarding permissions by strict deterministic approvals and an audit trail. He also talks about ProServal, the company’s team that embeds automation engineers directly with customers in order to provide ongoing support and service. Jake also discusses how AI was the big unlock to taking on ServiceNow, why he’s betting on coding agents getting even better, why consumer is a window into what will happen next in enterprise and why the SaaS-pocalypse might look more like a consolidation, why background agents are still a moonshot in enterprise software, and the importance of hiring product-oriented engineers. Sign up for new podcasts every week. Email feedback to show@no-priors.com Follow us on Twitter: @NoPriorsPod | @Saranormous | @EladGil | @jakeserval | @getserval Chapters: 00:47 – Jake Stauch Introduction and Serval’s Background 03:00 – Expanding Coding Agents Beyond Engineers 04:40 – Limitations with Personal Agents in Enterprise 06:29 – Deploying Serval Effectively in Large Orgs 07:55 – Day 1 Ambition and Attacking Enterprise Systems of Record 09:51 – Taking on ServiceNow with Workflow Automation Platform 11:01 – Betting on the Evolution of Coding Agents and Building Guardrails in Enterprise 14:30 – Big Risks, Big Rewards, and Big Predictions for Serval and Coding Agents 17:24 – Adopting Different Sets of Building Principles at an Enterprise Level 21:31 – Token Maxing, Long-Term Budget Impacts, and ROI 23:21 – The SaaS-pocalypse and SaaS vs. AI 25:21 – The Mental Model for Delivering Platform-Level Power to the IT User at Enterprise 27:26 – Building Automations with Catalyst and Raising Technical Competence 29:38 – The Next Wave: Background Agents and Autonomy in Enterprise 33:07 – Hiring Velocity and Unlimited Ambition at Serval 34:59 – Keeping Pace with Customers and Fundamental Shifts in Product Function 37:46 – Conclusion

Jake StauchguestElad GilhostSarah Guohost
Oct 29, 202638mWatch on YouTube ↗

EVERY SPOKEN WORD

  1. 0:00 – 0:47

    Intro

    1. JS

      This is the ultimate moonshot in enterprise software. These agents that go off and do work for you and magically discover all your problems and solve all your problems, and I think no one's really figured out how to do this well.

    2. EG

      This is kind of the OpenAI Hugging Face incidents or other things where agents are given a task and they do something that's unexpected.

    3. JS

      The agent becomes pretty competent. It could theoretically just start writing code that could take action on all your systems, and that is an unbounded security risk that I don't think anyone's gonna be able to take anytime soon. On the one hand, you want these to be very autonomous without somebody babysitting them. On the other hand, autonomy is very scary in the enterprise. Serval is the boundary. Serval is the guardrails. 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. [electronic music]

  2. 0:47 – 3:00

    Jake Stauch Introduction and Serval’s Background

    1. SG

      Hi, listeners. Welcome back to No Priors. Today, Elad and I are here with Jake Stauch, co-founder and CEO of Serval. Serval, with all the speed of the African wildcat, is trying to attack ServiceNow, and more broadly, bringing the power of code generation to IT and enterprise teams overall. Welcome, Jake.

    2. EG

      Jake, thanks for joining us today on No Priors.

    3. JS

      Thank you.

    4. EG

      Happy to have you here.

    5. JS

      Great to be here.

    6. EG

      Yeah. Maybe you could tell us a little bit more about your history and how you started Serval, and what, what is the problem that you started with, or why'd you start working on this to begin with?

    7. JS

      Yeah, so background, Serval is enterprise automation, enterprise service management. The idea is you can ask questions and get help at work and automate a lot of the parts of the job you don't enjoy, and we do that through code gen agents. So that's the, what the company does. We compete with companies like ServiceNow, is historically the big legacy provider in the space. I discovered this category actually working at a previous company called Verkada, uh, where we sold enterprise physical security products to IT teams. Spent many, many years talking to IT teams, figuring out what to build for them, and one of the things I love to, to do with these teams is ask them, "What do you spend the most money on, and what do you hate the most?" And ServiceNow would top a lot of those lists. And so I was always interested in this category of maybe there's a better solution here, but it wasn't clear for most of my time there how you'd ever beat ServiceNow. They're a great company. They've done so much so well, and why would you be able to compete with them? And I-

    8. SG

      What was frustrating for users about it?

    9. JS

      I think so hard to build in the platform. So it's a very robust, customizable, powerful platform that can map to all these enterprise workflows. Fundamentally, it's a workflow automation platform. And so it can do so much, but every idea you have for doing something cool, you have to go and implement, and a lot of times you're bringing in consultants to implement it. So it, it's always kinda running six to twelve months behind where you want it to be. And it's fine if you're building something that's gonna last five, 10 years, like a big onboarding flow, and nothing about your business is gonna change, so you can invest all that upfront effort, and then it gets deployed and it works for a while. But for just trying to keep up with all the automation that you wanna build, ServiceNow is not able to catch up. And, and then it's very expensive, and it keeps getting more expensive over time, so that frustration of it's not keeping up with where I wanna go as a business, and it keeps getting more expensive, that's what was driving a lot of the frustration.

  3. 3:00 – 4:40

    Expanding Coding Agents Beyond Engineers

    1. EG

      I think one thing that you mentioned that's really interesting about what you do is if you look at the world of AI adoption, a lot of the really early adoption is coding agents.

    2. JS

      Yes.

    3. EG

      And that's engineers using it to build applications for their business or products or other things. And what you folks have been doing is really pioneering expansion of the category in terms of saying we should let anybody internally, an IT person, et cetera, build internal products or tools that can be used broadly across the enterprise. You're basically providing like coding agents for, for the in- all the internal stuff-

    4. JS

      Yeah

    5. EG

      ... uh, for people who often aren't that adept at coding.

    6. JS

      Yeah.

    7. EG

      So can you talk more about that? I think that's like super fascinating. I think it's-

    8. JS

      Yeah, we love this idea of coding agents for the rest of us because if you think, so much of the early enterprise adoption in AI has been engineering teams. And if you think about why that is, there's a lot of reasons. Obviously, early adopters in a lot of different technologies, but also they're able to build and experiment with these tools because they have this process of code review. It's very safe for even a 19-year-old intern to build something very powerful and then go through this process before it goes into production. We wanna bring that same capability to the rest of the enterprise, so we build a platform that brings coding agents to IT departments who then can bring it to HR and finance and people teams and legal teams. And they can do it because under the hood it's coding agents, but then you have all these abstractions and guardrails and controls, so things go through approval, they go through a staging and, uh, approval cycle and audit trail and all of that. And so it's how do you build a system that makes it easy for everyone to be a builder? And the core insight here was that IT actually wants to build stuff, and for most of the world, they don't have an engineering department, they have an IT department. Most companies have an IT department, not, not a, a team of software engineers. And so IT is what's building and configuring technology for the company, and we're building essentially the AI platform

  4. 4:40 – 6:29

    Limitations with Personal Agents in Enterprise

    1. JS

      for them.

    2. EG

      How does, how does that run into things like all the different, more like workforce agents that are being developed, like Dot from OpenAI or, you know, some of these things where you almost have a virtual assistant that will go and do things for you?

    3. JS

      Yeah, I think those really work well for consumers and SMB and even a lot of the mid-market organizations. In a large enterprise, there's so much, and I didn't even really appreciate this going in, there is so much process around approvals, around what you can and can't do. The permission sets of any individual are so limited that even if you are allowed to bring your agent to work, which a lot of cases you're not, what it can, what it can do is so incredibly limited. It can, it can barely even read your emails. Um, and so when you think about all the stuff you need to do at work and all the systems you wanna touch and all the interesting automations you could build, your personal permissions end up being so limited that these personal agents are also incredibly limited and all, not all that useful. So what we can do, because we work with these IT teams that can connect with, you know, service account credentials and admin-level permissions, we can create a structure where people can access elevated permissions and do all these crazy things in their work, but with very, very strict deterministic approval cycles, workflows that are deterministic, um, and an audit trail, because under the hood we are also a ticketing system. So you say, "Okay, I want my agent to go do X, Y, and Z." Well- Most organizations are gonna be very uncomfortable with that at the large enterprise scale. But with Serval, that's gonna create access requests that go through an approval process, and all that's gonna be documented and logged, and then you can get just-in-time access to be able to run that deterministic workflow one time, and all of it's gonna be tracked. And yes, it's a little bit more annoying than the magical personal agent experience we love with Instinct and Muse and all these tools, but it's what has to be true for a large enterprise, especially a regulated enterprise, to ever adopt these kinds of

  5. 6:29 – 7:55

    Deploying Serval Effectively in Large Orgs

    1. JS

      technologies.

    2. SG

      And this also, I guess, feeds into the traditional diffusion of this technology, which has been consulting firms, the Accentures and Deloittes and the like of the world kind of owning a piece of this, doing the implementation for people. You're kinda taking that and putting it in the hands directly of the IT department. Are you also exploring this Moore's word sort of forward deployed motion, or how do you actually get this really built out in the enterprise or used effectively?

    3. JS

      Yeah, absolutely. Diffusion is obviously the gap here. The technology can do so much, and, and enterprises have barely scratched the surface of what's possible. And a lot of that is just understanding the people, the process, what workflows actually exist, how you want them to exist in the future. And we think that you still need people for that. So we deploy both a, a deployment strategist, we call them, and a f- deployed software engineer that go on site with customers, figure out how do we implement this? How do we solve all your problems as a business? And then walk you through the implementation. What we found, though, is that a lot of times after we've got this implemented and deployed, customers then have a long tail of more stuff they want. And, and as we've discovered with software engineering, there's actually unlimited demand for work. And we've started to build out a team, we call it ProServal, uh, or, or automation engineering is, is the field. And we bring in these automation engineers to kind of do ongoing continued support and services because there's so much that they want to automate, and they need the help to be able to figure out what can be automated, what do the processes look like, how do we navigate all of our systems, and then put it into production with a product

  6. 7:55 – 9:51

    Day 1 Ambition and Attacking Enterprise Systems of Record

    1. JS

      like Serval.

    2. SG

      How old is the company today?

    3. JS

      Two and a half years.

    4. SG

      And, um, you know, if you just look at ServiceNow as a business, I feel like Serval's one of the only companies that is like, "We are direct attack, replacing enterprise systems of record, including for large enterprises." Um, at the beginning, did you think you were going to do that? Like, do you... How do you eat the elephant-

    5. JS

      Yes

    6. SG

      ... just in terms of, you know, how big that product suite is?

    7. JS

      I like to say everything has gone exactly according to our very delusional plans. So we set out from the beginning to be the largest enterprise software company of all time. We actually made a list of all the companies. We circled ServiceNow, and we said, "We're gonna beat them, and we're gonna build something much bigger." We said that on day one when it was two people in my co-founder Alex's living room, and we just said, "We're gonna do it." And so even though that was crazy, that was always the intention. We didn't grow into that ambition. We set out from the beginning. I think that that actually-

    8. SG

      A lot of people would've started with, like, you know, automation on top of their ticketing system, for example.

    9. JS

      Yes, exactly.

    10. SG

      Yeah.

    11. JS

      So the, the way you typically go after these, these large enterprise startups, at least, they, they build, like, the layer-

    12. SG

      Mm-hmm

    13. JS

      ... or they go down-market. And those are kinda the two common approaches. Let's build a small layer, play nice with the big incumbents, AI agent on top of Salesforce-

    14. SG

      Which has never worked

    15. JS

      ... which, like, it, you know, it's, it really caps how big you can get

    16. SG

      I mean, I guess that maybe the only one that worked is Viva or something, right? 'Cause they, they'd started off on Salesforce, and then they migrated to become their own platform. So they, they're the only one that I can think of that backwards integrated fairly successfully.

    17. JS

      It's really tough. It, like, caps you unless you find some niche to kind of, like, uh, expand into later on. Um, the other approach is we just go downmar- you know, go down-market, service the SMB and mid-market, and you see that with a lot of, you know, competitors to Workday, competitors to Salesforce. They just say, "We're gonna be that but for the lower end." And we just looked at-

    18. SG

      This is Rippling or HubSpot-

    19. JS

      Exactly

    20. SG

      ... for the first 10 years. Yeah.

    21. JS

      Exactly. And we looked at that, and we said, "Why not just go after the big one? It's, it's much harder, but at least the prize [laughs] is quite big if you win." And I think that was so important for us because you end up making so many different decisions if you're building for the large enterprise from day one. All the product decisions, how you build your team, how you think about growth, they're fundamentally different than if you go and

  7. 9:51 – 11:01

    Taking on ServiceNow with Workflow Automation Platform

    1. JS

      you serve one market and then you hope to expand later on.

    2. SG

      How'd you choose this versus Salesforce or Ver- You know, there's a few other sort of canonical giant companies in different categories.

    3. JS

      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 co-founder, and my co-founder 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 non-technical 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 b- what is the best market for an automation platform? It's actually taking on these massive

  8. 11:01 – 14:30

    Betting on the Evolution of Coding Agents and Building Guardrails in Enterprise

    1. JS

      legacy software companies-

    2. SG

      Yeah

    3. JS

      ... like ServiceNow.

    4. SG

      I guess two and a half years ago when you got started, though, most of the coding stuff was sort of tab complete, right?

    5. JS

      It did not work.

    6. SG

      Yeah. And so-

    7. JS

      To be very clear, like this was a-

    8. SG

      Yeah, yeah

    9. JS

      ... this was a brilliant idea.

    10. SG

      Yeah.

    11. JS

      But in practice, when we started building this-

    12. SG

      Yeah

    13. JS

      ... uh, it-

    14. SG

      What was the assumption? Was it that the, the coding would get much better? Was it that you'd built tooling and then you didn't need to because things got so good? I'm sorta curious of that transition.

    15. JS

      The bet was that coding agents would be, would get very good. Um, and the, 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. [laughs] And so we'd, we, 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 that it couldn't automate if the APIs existed.

    16. EG

      Yeah.

    17. SG

      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, uh, in terms of impact on your own product?

    18. JS

      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. Um, we are building the guardrails. We are building, um, the, the boundaries, and the boundaries are the product for us because we are the way that a large enterprise, uh, 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 m- more and more narrow, which I think is going to happen-

    19. SG

      Why is it gonna happen?

    20. JS

      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.

    21. SG

      Uh-huh.

    22. JS

      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.

    23. SG

      Absolutely. Yeah.

    24. JS

      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

  9. 14:30 – 17:24

    Big Risks, Big Rewards, and Big Predictions for Serval and Coding Agents

    1. JS

      on end user permissions.

    2. SG

      Is there, um, 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 a, a, is there an experience where people have already gone through to the other side?

    3. JS

      I think we have to convince ourselves and our customers that Serval is the way you get promoted at work. It, it can't be the fact that Serval is a risk that you take to hopefully get something on the other side. We have to convince customers that you do this and you're gonna make your career. You're not just gonna not get in trouble, but you're actually gonna get a promotion.

    4. EG

      And this is top-down, right? So you sell in-

    5. JS

      Top-down. So we sell into the C-level-

    6. EG

      ... and then it goes across

    7. JS

      ... sell into IT leadership-

    8. EG

      Yeah

    9. JS

      ... in, in many cases, and then distribute into other departments. And that is the message is this is people built their career on ServiceNow. You're gonna build your career on this next generation. And we're seeing this play out. So one of our largest customers is Fox. Um, Fox Corporation adopted Serval company-wide, and the person who led that migration at, on the gr- on the ground level actually got nominated to be the MVP of the entire company.

    10. EG

      Wow.

    11. JS

      And, and got an award for his work there, and that is really what we're about, is we're convincing our customers, saying, like, "This is the way to not just prove that you're, you're useful to your organization, but to prove that you might be the most essential person in your company because you're leading this change." And we're so pivotable, pivotal to the AI transformation story that I think it's a, it's something we can sell really nicely to our customers.

    12. EG

      When you started Serval, I think you were very, um, adept at thinking ahead, right? So you knew coding agents or coding would get better. You knew there's this wave of transformation. You k- you kind of identified the good market segment to go after. What do you predict will happen in the next two, three years, not only for your company, but for AI more broadly? Like, is there something else you're seeing on the horizon that you're very excited about or a big shift that you see coming?

    13. JS

      I think consumer often gives us a win- window into what's gonna happen next in enterprise. Um, and it al- it doesn't always look the same, but I think it's a, it's a nice window, so I, I'm very bullish on what do personal agents look like in the enterprise. I think in the same way that email and Slack and these tools transformed how we communicate at work, I think personal agents will also be a big part of that. I think everyone will have their personal agent that does tasks for them, that delegates to other personal agents, and so your agent will talk to other agents at work. So I'm really excited about that, but then how do we secure that in a world of increasing cybersecurity risk and increasing concerns at large enterprises around what's happening with everyone's agents taking action in all their computers and, and using their browsers? And so that tension between what employees, consumers want out of their personal agents at work and what enterprises need from a governance perspective I think is really interesting, and I think there's gonna be a lot of opportunity in that, in that tension of-

    14. EG

      Do you think there'll be a separate personal and work agent-

    15. JS

      I think so

    16. EG

      ... per person?

    17. JS

      Yeah. I think so. In the same way that I have a Gmail and I have a-

    18. EG

      Yeah, exactly. Yeah

    19. JS

      ... a, a corporate email.

  10. 17:24 – 21:31

    Adopting Different Sets of Building Principles at an Enterprise Level

    1. JS

      Um, yeah.

    2. SG

      If there's a premise that... I, I, I mean, there's a bunch of different ideas here, but one is that, um, uh, you know, exceptions or access control is gonna get complex and require a different level of scale, right? Another is that you're just going to have more automations overall because people, you know, if you make it easy, people are going to, um, extend it in all different places. Are there, like, core design principles beyond Uh, code generation should be the actual form of automation that you have put into the product today that reflect that?

    3. JS

      I think the biggest one is the software development life cycle, something that we take for granted in engineering context of the, "Hey, there's actually like a dev environment, and then there's staging, and then there's prod, and there's like these gates between them, and maybe you've got, you know, branches that people can develop on that's not gonna harm the other systems." That is-

    4. SG

      I'm sorry, just to be clear, that's not how IT automation works today?

    5. JS

      Uh, it does in some cases, but I think most new AI products are not embracing that. They're basically saying, "Hey, let's build these cool agents and ship to production." But this idea of, "Hey, you have to actually follow an SDLC process if you're a large enterprise." A large financial institution is not just going to ship new agent capabilities, uh, without a, a review and user acceptance testing and, and all of these-

    6. SG

      Compliance checks that are-

    7. JS

      Exactly

    8. SG

      Yeah.

    9. JS

      And so I think that's something we think about a lot, is what is going to convince the largest companies in the world to adopt this technology, not just what is powerful and cool and something we're excited to get in the hands of customers.

    10. EG

      Feels like it takes a lot of AI companies, particularly if they're vertically centric, a year or two to figure this out, sometimes longer, and it's interesting to watch the whole industry now adopting both the forward deployed motion, starting to think through, uh, software development life cycle, compliance, other aspects of the enterprise in a way that was almost missing.

    11. JS

      I, I think-

    12. EG

      It's like a gap

    13. JS

      ... in some cases they never get there. Like, some companies just, they, they look at what enterprise software takes, and they decide, "We don't really wanna build that." And it, it takes... You know, you, you look at the story of a lot of these companies that we mentioned earlier that have gone down market, I think sometimes they do look at the opportunity to go and build for the enterprise, and it, it requires a whole different set of building principles and products that you have to build, and some just don't choose to do it, and they, they cede that ground to other companies. And, and we've chosen to say like, "Hey, give me your [laughs] , your gnarliest problems, and we're going to solve them and make AI, um, transformations possible in this, this crazy world and this world of risk and, and governance concerns."

    14. SG

      When you, um, have your, you know, deployment, your sort of in-customer environment engineers, and then ongoing automation specialists, and then you have the core platform, how do you decide what s- is actually brought into the core platform or, you know, uh, in every individual customer's environment?

    15. JS

      Yeah. So when we deploy these software news, I think what's really important is we actually never build custom features. We don't build bespoke product capabilities, and luckily for our category, no one asks us to. Everything that people ask for is something that every other customer is going to want at some point. Maybe they impact the prioritization, but it's still something we've always wanted in the platform. Now, because it is a code gen platform under the hood, what you build in Serval is very, very unique. So the password reset workflow for one company is gonna be very different, shockingly, than the password reset for another. Um, same with onboarding and off-boarding and all these different automations internally. They look very different, but that's just baked into the core primitives of the platform. Serval almost becomes the IDE, right, for the IT department and other departments to build their automations and manage them at scale. So what we do do is w- if we look and we see the same customer building the same automations over and over and over again, and having to customize them and, and build them in the product in the same way, we start to consider, hey, should that be a first-class feature in the product? So one example is we saw a lot of customers building workflows to detect knowledge base articles that were out, uh, conflicting or out of date.

    16. SG

      Uh-huh.

    17. JS

      And so we said, "Hey, we should just do that au- automatically." And we, we had customers that, you know, would, would set up automations to reclaim old licenses. So licenses for software you're paying for that no one is using, let's automatically cancel those subscriptions. Well, we just decided to build that in the platform. So it is a way for us to kind of test the waters of what should be really first-class features versus what should sh- stay as automations,

  11. 21:31 – 23:21

    Token Maxing, Long-Term Budget Impacts, and ROI

    1. JS

      uh, in Serval.

    2. SG

      Or enterprise customers as it relates to just general spend on code generation for software teams have gone through a journey this year, right? They're like, "Uh, we're gonna let people try it, then we're gonna token max, then we're gonna, like, restrict that and figure out who's actually doing this productively." Um, how do you think that reflects for your, your business, and how do you think about, um, the sort of actual intelligence cost?

    3. JS

      Yeah, I think we're still watching this. I do see our CIO customers trying to pull back from that initial token maxing era, but I also think we're so early in the adoption curve that it's not going to be a, a clampdown in the aggregate. It's actually gonna continue to be a pretty dramatic rise because most companies are still figuring this out for the first time, and they're, they are all going to go through this cycle of rapid early adoption and then kind of a pullback of spend and trying to measure and calculate ROI. Um, but what I hear from our, our customers all the time is not really a concern about the, uh, long-term budget impacts. They, they realize that there's gonna be a short-term pullback, but they're still planning on increasing spend. What they need, though, is more proof of ROI, and that, I think, is what's gonna transform in the industry is, is people looking for how can I prove that this spend is giving me something, and that is hard. I don't know that anyone's really figured out how to measure what you're getting from the tokens that you're buying, uh, but that, I think, is gonna be a huge opportunity for us to show the work that's being done and try to equate it to work that would've been done in other platforms or with other cost models or by labor. And so that's what c- our customers are asking for is, is, "Help me prove that this was worth it." And, and that's what the assignment is. That's what we have to do. We, we try to price on workflows run because I think it's a better reflection of actual work being done versus just tokens, which is more, like, verbosity, [laughs] um, and inefficiency. Um, but, but I think we're all gonna figure out different models of proving

  12. 23:21 – 25:21

    The SaaS-pocalypse and SaaS vs. AI

    1. JS

      that what we're doing makes sense.

    2. EG

      One of the things people have been talking about is this sort of SaaS-pocalypse, where the idea is, you know, people will just build their internal SaaS software, and all these categories will go away. And a lot of people, to your point on calculating the ROI on tokens, are kinda trying to sort is it worth rebuilding these systems, and can you actually do that effectively? What is your view on the SaaS-pocalypse or this sort of shift in, in SaaS versus AI?

    3. JS

      Yeah. I think all the companies I've talked to that try to vibe code these tools internally, especially the, the main system record tools, not the, the kind of point solutions, but the main system record tools have discovered that it's quite expensive to build and maintain enterprise software. Even if you can do it, it doesn't make economic sense in many cases to do it unless your needs are very bespoke and unique in some way. And so buying off the shelf for things that are not your core competency, I think has always been the build versus buy argument. I think that that Is, is true now as it is, as it, as it's ever been, um, because it c- still is hard to build enterprise software. A lot, a lot of companies are discovering this or relearning this, that actually enterprise software is complex, and you need people to maintain it-

    4. EG

      It's a lot of use cases and edge cases and-

    5. JS

      Edge cases-

    6. EG

      Yeah

    7. JS

      ... uh, thing, things that, um, break down and people need to update it, so then you have to staff the team, and then you're paying for that labor and, and then no one really wants to work on the internal tools team in many cases. So you have all these problems with doing that. Where I do see it is in kind of the point solutions where a lot of companies have hundreds and hundreds of SaaS applications. They probably need a couple dozen-

    8. EG

      Mm-hmm

    9. JS

      ... total. And so I do think you're gonna have a shrinking of the, the sprawl of different point solutions, and they're gonna be eaten by the core systems of record and the core platforms.

    10. EG

      All the middleware too, I think is just gonna go away.

    11. JS

      Exactly.

    12. EG

      Sort of really-

    13. JS

      Exactly. So I think there is gonna be consolidation. Um, and so this, there will be a SaaS-pocalypse, but in that kind of point solution, um, smaller market cap type companies, I don't think that you're gonna truly get away from the courses records, the ERP, the HRIS, the ITSM, the CRM. I think those are going to stick around. They might transform, and what we're seeing with Serval is, is we are displacing the, those tools. Um, so I think there will be a new generation of incumbents, um, but I don't see those categories

  13. 25:21 – 27:26

    The Mental Model for Delivering Platform-Level Power to the IT User at Enterprise

    1. JS

      just disappearing.

    2. SG

      I, I'm curious as to what mental model, uh, w- or what theory of mind do you have for the IT user, um, given, you know, they're not software engineers, but they understand their business, they understand what they're trying to go automate. Is it, you know, when you talk about vibe coding, I'm like, "Okay, but do you understand, like, security architecture? Like, do you understand how this is gonna integrate with governance?" Like, how do you square, you know, code generation and how we think about vibe coding and what the challenges are with that, with, you know, we wanna build robust IT systems?

    3. JS

      Yeah, absolutely. I think IT is really interesting because they're, they're closer to a software engineer than I think a lot of people give them credit for.

    4. SG

      Mm-hmm.

    5. JS

      Uh, especially in, in large enterprises, the IT department is the engineering team in a lot of cases. They don't have the, the software engineering team, so IT runs all these systems and, and IT often does write code and manage the systems. And so I think we treat them as adults. We give them the tools that we would give software engineers. Now, we abstract away some of that complexity. Uh, we make it easier to use in some regards, and, and we don't just kinda hand them cloud code and tell them good luck. We actually, we build a platform that's dedicated to their use case, and we don't expect them to be able to necessarily write code or, or understand what's being written, um, but we still give them access to it under hood. So you can always see the code.

    6. SG

      Mm-hmm.

    7. JS

      And you can always treat this through a s- full software development life cycle, but you'd also don't have to. And so a lot of the, the product principles is thinking with a few different personas in mind. You know, an IT engineer who actually can and does write code all the way through someone maybe in the marketing department or the, the people team that doesn't wanna see code ever but still wants to have that flexibility of, of code gen under the hood because they've got a complex workflow that they wanna build that they don't wanna drag and drop their way to. So I think a lot of it just comes to having multiple personas in your head and also treating IT like an adult. I think a lot of the products that have been out there have actually ch- kind of been pedantic to IT of like, "Oh, you don't actually understand this stuff, so you need this very stripped down, more opinionated, simpler version." Actually, IT appreciates the complexity and appreciates the power of these platforms.

  14. 27:26 – 29:38

    Building Automations with Catalyst and Raising Technical Competence

    1. JS

      We wanna deliver that to them.

    2. SG

      You guys built an agent that helps you build automations. Can you explain how that works?

    3. JS

      Yep. So one of the things, I think every company discovered this as they were building kind of the first generation of these, these AI tools, is that you could build such amazing, complicated systems, but then you had to train people to understand all of your product primitives and how these systems fit together. And so the first generation of this is we deployed all these FDs to explain to customers, "Okay, here's, here's how to build the platform. Actually, let me just build it for you." And then realized it would be really nice if customers could just talk to an agent that understood their requirements and then translated that into the product primitives. And so we built this agent called Catalyst that does exactly that, is it an agent for managing the platform. So it's an agent for admins to build out all those underlying automations, but also configure the rules around approvals, uh, permission checks, um, build out different policies, update all these different systems, understand the, the entire deployment. And so because Serval is all code gen under the hood, having the agent on top of that to help you manage the system just made a ton of sense and is so powerful because now I don't need you to train yourself on how to use Serval. You can just talk to an agent that actually understands how to use Serval and how to build on it, and, and that is your primary interface into the product.

    4. SG

      I, I think one thing that's underappreciated and I think is cool is that, uh, the experiences for agents in different products and actually in, you know, code generation agents as well, being able to bring a user along as they are building a product or an implementation or something is actually like raising the technical competence and ability of a huge number of users and, and turning people into more, you know, engineers actually.

    5. JS

      Yes. Absolutely. You have this blank slate problem in the old generation of automations of where, where do I even begin? I know I wanna automate all these parts of my job, but where do I begin? Products like ours say, "Where do you wanna begin?" And just can start making suggestions, and you can iterate with them. You can say, "I actually don't understand that. What are you trying to say? Can you explain this to me? Okay, I'm trying to do this. How would I even go about doing this?" And they can give you that information. They can fetch the information. They can explain concepts to you. And so it does become a build partner, and you can achieve so much more than just prompting an agent to go and build something, and it can actually walk you through the process and help you explore new opportunities that you wouldn't even

  15. 29:38 – 33:07

    The Next Wave: Background Agents and Autonomy in Enterprise

    1. JS

      have even thought of.

    2. EG

      So one thing that seems a little bit under-discussed right now is background agents. Uh, could you tell us more how you think about that and what you think is coming in terms of this next wave?

    3. JS

      Yeah. I always describe background agents to the companies like this is the ultimate moonshot in enterprise software, just these agents that go off and do work for you and magically discover all your problems and solve all your problems. And it would be amazing if we could get that deployed, and it could work, and it could follow our permissions. And I think no one's really figured out how to do this well because, on the one hand, you want these to be very autonomous, to go off and figure stuff out, and then solve problems without somebody babysitting them. On the other hand, autonomy is very scary in the enterprise, and so you do wanna see what exactly can they read.

    4. EG

      This is kind of the OpenAI Hugging Face incidents or other things where agents are given a task, and then they do something that's unexpected-

    5. JS

      Yes

    6. EG

      ... in order to accomplish that task. And so what are the guardrails you can put in place to have a good set of-

    7. JS

      Exactly, because my best employees, what do you do with them? You say, "Here's the general high-level mission. Go off, don't talk to me, and go do it. And you'll come back, and you'll have done amazing things." I want to be able to trust agents to do the same thing for me, where I can give them this high-level task, and they can come back and solve this problem and come back to me. I don't think we've figured out how to do that in a way that it feels safe-

    8. EG

      Mm

    9. JS

      ... in the enterprise.

    10. EG

      What do you think is a way to make it safe? Is it a... I mean, people have experimented with different things over time, everything from constitutional AI to certain forms of RL. Now that... I'm just sort of curious if you have a solution in mind or, or is it just-

    11. JS

      We think of it f- in, in the large enterprise, it's not perfect, but it's a, it's kind of an incremental escalation of capabilities. So you go off and you do these things, then it comes back and says, "Hey, I would like to be able to do all this stuff. This would help me do my job," and you approve them. And all the stuff are deterministic workflows. I wanna call this tool. I wanna run this script that does X, Y, and Z. Can I do that? And you just kind of approve these with certain permissions and guardrails around them, and you say, "Okay. Yeah, that's okay. That's okay. That's okay." And over time, the agent becomes pretty competent because it has a, a big enough toolkit that it can solve most problems. Um, and it's not perfect because it's annoying to have to babysit that process, but I think it's what you have to do because otherwise it could theoretically just start writing code that could take action on all your systems, and that is an unbounded security risk that I don't think anyone's gonna be able to take anytime soon.

    12. EG

      Mm.

    13. SG

      Do, do you think to your point of being excited, are you and Alex being excited about future capability? Um, like, we're, we're still missing some model capability here. The reason I ask is, uh, y- you know, the ability to be proactive and then predict what an individual, Jake as CEO, me as an investor, um, or me as a human being, you know, and, and get it right is still very hard, right? You need a lot of preference data. Think about an employee working for you. Like, okay, what are Jake's actual priorities? When he s- gives me this high-level mission, what does he mean? Do you think that's a model problem, or it's entirely, like, a, a guardrails and harness problem today?

    14. JS

      I, I think it's, um, it's both honestly. I think memory obviously has to be better and better because you wanna understand the preferences. You want the context to be insanely large because I don't wanna have a bunch of different chats with you. I wanna have kind of one single chat that goes back all the way to our very first conversation, and you remember the key points of that that are relevant. Um, and then I think the permissions problem will always remain the biggest thing because even if I feel like you are a very, very valuable, smart agent and I... You can do all these things for me, how much do I trust you to just run wild and not have to babysit your actions?

    15. EG

      You have to do that with people too, right? I mean-

    16. JS

      But you also have to do that with people

    17. EG

      ... anybody who works for you has to come back and check in, and this is what you wanted, and here's three options. And so I think it's a very normal just process, right?

    18. JS

      Yeah.

    19. EG

      Yeah.

    20. JS

      Yeah.

  16. 33:07 – 34:59

    Hiring Velocity and Unlimited Ambition at Serval

    1. SG

      The company's about two and a half years old. Uh, you have gotten very quickly to at least an enterprise mature product. How big is the team today?

    2. JS

      We are 200 people today.

    3. SG

      200 people.

    4. JS

      We were 20 in January, so it's been an incredible ramp year.

    5. SG

      That, that's quite a year. One, I guess, do you expect to continue hiring so fast? And as somebody who clearly believes in AI, like, why? And then two, just, you know, you've been part, uh, you and your team have been part of startups before. Like, w- what are you operating... How are you operating very differently, you know, the last two years than the previous 10?

    6. JS

      Yeah. The hi- the hiring velocity I think will, will increase even from where we're at today. Um, we believe that there is unlimited demand for work, and there's unlimited competition, and there's unlimited ambition. And so even though every single employee does so much more than what they could do a year ago, we have even bigger ambitions for what they could do. And so I, I think because every employee is so much more productive, we actually want more of them, not less of them.

    7. SG

      Given your, you know, time at Verkada before, uh, w- how are you operating differently o- the last two years than the previous 10?

    8. JS

      I think what's so unique about Serval and the category we're in and the moment we're in is the TAM is unbounded. So it feels like the, the, the addressable market is really more about the size of our ambition than it is about fundamental limitations on how big this business can get. Because we are automating essentially all kinds of work for every single employee in the world, the TAM is as big as we want it to be, uh, and it's really how fast can we grow and what is our ambition and making decisions based on that versus, okay, here's, here's what the market looks like. Here's what we think we can actually do. And that's a different set of challenges. It's not, it's not, uh, strictly better because now there's so much open space, and there's so many more decisions we have to make about what we actually wanna focus on. Um, but it is really fun to not be constrained and, and hemmed in by what the market allows

  17. 34:59 – 37:46

    Keeping Pace with Customers and Fundamental Shifts in Product Function

    1. JS

      for.

    2. SG

      How... Given that scope is very broad, how do you organize, like, the cadence or the, you know, um, the E- EPD team?

    3. JS

      We are embedded with customers. So even the, the engineers that are not necessarily deployed, they are in the customer Slack channels. We are talking about customers nonstop. They're hearing from customers every single day. Most engineers are on a at least one customer call a week. I think most of them are actually on at least a customer call a day. And so what this is, it's, it's like immersion in a, a country to learn a foreign language. You, you become so immersed in your buyer and your customer's mindset that you understand what they want, you understand how they're thinking about things, and you're adapting to their preference changes in real time. So as they're moving with the market and they're starting to talk about different products that they're trying out and things that they're excited about, our engineers are constantly aware of all this and able to adapt very quickly. So we've decentralized Product development really to the engineering team. We don't have a product function because they're the ones talking to customers every day, and they're able to rapidly adapt to whatever customers are saying today and this week versus what they were saying a month ago.

    4. SG

      That sounds like a, a really, like, natural way to keep pace with, um, a, like, a ripping market and changing priorities for your customers. How do you and Alex and leadership then make sense of it? Like, you know, in a traditional enterprise software company, you'd have, like, architectural review to, like, control-

    5. JS

      Yeah, you have a pro- a quarterly roadmap-

    6. SG

      Yeah

    7. JS

      ... and you prioritize the roadmap, and you, you know, train all your customers on the new launches.

    8. SG

      And you'd communicate with your customers that, like, things aren't gonna change too fast because they can only absorb it so fast, too.

    9. JS

      Yeah, it's a big challenge. Our product fa- ships and changes faster a lot of times than anyone can keep up, including myself. Um, we just try to make sure that, one, the engineers that we hire are really product-oriented. That's one change we've made is they have to really understand our customers, and we wanna put them in front of our customers because they're gonna b- have to make so many decisions at the edge, and not every single product decision can be bubbled up to leadership every single time. That is a fundamental change, is you have to be willing to push a lot of the product decision-making down below, and you have to be willing to move fast and also undo and revert, uh, if you go in the wrong direction, and, and kill your darlings. You have to be willing to get... You know, change course on things that you thought were fundamental to the product and switch gears when your engineers bring you something that, "Hey, this is how the customer sees things now, and this is what we should do differently." And one of the things I'm proudest of at Serval is how many times we've decided to erase things we've done in the past that we're very committed to and just say, "You know what? The market's changed. The customer's changed. We're gonna do things entirely different." And, and I think that is what's enabled us to keep up, is that ability and willingness to reinvent ourselves over and over again.

    10. SG

      It's one of the most durable things in this era. Thanks, Jake.

    11. JS

      Thanks, Jill.

    12. EG

      Thanks for joining us.

    13. SG

      [upbeat music]

  18. 37:46 – 38:03

    Conclusion

    1. SG

      Find us on Twitter @NoPriorsPod. Subscribe to our YouTube channel if you wanna see our faces. Follow the show on Apple Podcasts, Spotify, or wherever you listen. That way, you get a new episode every week. And sign up for emails or find transcripts for every episode at no-priors.com.

Episode duration: 38:05

Install uListen for AI-powered chat & search across the full episode — Get Full Transcript

Transcript of episode EZcWEsMuLb4

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.

iOSAndroidClaudeChromeChatGPTComing soon