成立两年拿下100家企业客户，Serval凭什么重做ServiceNow

id="podcast-transcript" data-framer-component-type="RichTextContainer" style="transform:none">Full conversationJake Stauch: You know, that there’s always a gap between the idealized vision of what you think your job’s gonna be and then what your job actually is. Pat Grady: Yeah. Jake Stauch: I think that’s true for every profession. You idealize—and kids do this the most, right? When they want to be a firefighter or an astronaut. What that job looks like. And then you get in that job and you’re like, “Oh, there’s actually a lot in this that I don’t like.” And we want to be the tool that actually closes the gap between what you think your job is going to be and what your job actually is. Pat Grady: All right, I’m here with Jake, the co-founder and CEO of Serval. Jake, welcome to the show. Jake Stauch: Thank you so much. Great to be here. Pat Grady: We’re going to start with a high-level question. You guys are building kind of the next generation ServiceNow, like the AI-native ServiceNow, so to speak. Jake Stauch: That is right. Pat Grady: Why does the world need an AI-native ServiceNow? Jake Stauch: Yeah, employees need help at work. That’s kind of the idea here is we are a platform for employee support. The technical term is “enterprise service management,” but what it really means is getting help at work. And the ideal way to get help at work is you ask for something and you get it instantly, automatically. You don’t have to wait on somebody to track down a ticket and assign a ticket to somebody. You just get help immediately. That requires you to have some kind of automated support, and that automation is best built with AI. So we think about this from first principles. How do we support employees? You automate all the requests. How do you automate all those requests? AI is really a good tool to bring that automation to employees. Pat Grady: Awesome. Let’s say more about that. So I remember back in the day when we first met Fred Luddy, who was the founder of ServiceNow in 2007-2008 sort of timeframe. And at that time, people thought that ServiceNow was amazing, because it was this big step function change over Peregrine and Remedy. And the key thing that they got right was to think about enterprise software as an abstraction—it’s just workflows on top of a database, right? So they built kind of this flexible workflow configuration engine on top of a database. And at the time, that was amazing, and IT people loved it and they were off to the races. What I’m hearing you say is that that’s not enough. With AI, there’s kind of a new generation of automation that can be done. Can you just say more about the thing that ServiceNow built and the thing that you guys have built, and kind of the side-by-side, like, what is truly different this time around? Jake Stauch: They got it right. We also built workflows on top of databases, and that is the right abstraction, those are the right primitives. The problem with their workflows and databases is that they require a lot of manual effort to build and maintain. So building those workflows often requires dedicated development resources to put those together. And while that sounds fine—you invest those resources, you get a beautiful automation on the end of it—that can take weeks to months. And in an era where business processes are changing very rapidly, by the time you get that workflow implemented, your business may have changed and moved on and you want a different workflow. And so your automation kind of runs behind where you want it to be. And that’s more true now than ever before. Same with the database. If you need to manually update those entries and look at your IT assets and make sure they’re up to date in those systems, that’s going to be very, very painful, having to bring in consultants or internal developers to update. We took this unique approach of let’s keep those primitives, workflows on top of databases, but allow you to use AI to build the workflows and use AI to update the databases. And the way we do that is this CodeGen engine where you describe the workflow that you want—all the different steps and permissions and approvals and logic—and we take your natural language description and turn that into code. And so your workflow appears instantaneously. There’s practically zero time to develop those workflows. And the same thing goes for our databases. You can describe exactly what data you want to take from which sources, and our system will actually generate the code to fetch that data and keep it up to date without you having to do any kind of manual intervention. Pat Grady: I remember you said months ago—this is one of the things you said when we were first getting to know each other that really piqued my interest—something along the lines of, if you really want to drive enterprise automation, you have to make the process of building the automation just as simple, if not simpler, as the workflow being automated. Jake Stauch: Exactly. Pat Grady: Do you still believe that? Is that still true? Jake Stauch: I still believe that. And that insight came from just putting yourself in the shoes of someone in IT or another function, and you’re presented with a task. Somebody asks you to reset their password, and you’ve got two options. You can go into Google Workspace, find the user, hit a button that says reset password. Pat Grady: Yeah. Jake Stauch: Or you can open up a workflow builder, and you can drag the trigger, and then you can drag the response, and then you can build out this custom workflow. And when you’re presented with that choice, you’re just going to reset the password. You’re going to do the manual thing. But if it were actually easier to build the automation, you would build the automation, because it is just why wouldn’t you? And I think it comes down to that. People in the moment have to make that decision, and you want that decision to be very, very easy to opt for the automation, not opt for the manual step. Pat Grady: Now is there such a thing as being too simple to automate? People talk about vibe coding and all the slop that it produces. Is there such a thing as slop automation? Jake Stauch: Yeah, it’s real. And we’ve had to build some really interesting things around that, because when you make it so easy to automate, somebody might build the 20th password reset workflow this week. And it’s basically the same as the 19 that came before it, and now you’ve got all these duplicate workflows, and the AI gets confused on which one to run. Pat Grady: Yeah, how do you guys manage that? Jake Stauch: We built a new agent basically on top of Serval that we’re really excited about that has full contextual awareness of all the workflows you’ve ever built before, how they work, what they’re going to do. So when you say, “Hey, I want this workflow that does X, Y and Z, it says, “Hey, actually you’ve got 19 that already do that. I could modify one of these, but here’s what I think you should do. I think you should actually delete 10 of them, separate these remaining nine into these different categories, add these approval steps.” And so it actually walks you through the system and is kind of your assistant that’s an expert in our product to help you translate your business requirements into the actual product implementation. Pat Grady: Speaking of the product, so you’re a product guy, and one of the things that we’ve heard about you consistently from every possible source is that you’re extremely customer focused, and really good at listening to customers and figuring out what they need. Do you have a north star metric that you rely on that just tells you the product is getting better and more useful? Or is it more you collect all the anecdotes, you synthesize them, you kind of have an intuitive sense? Is there a number that you can look at? Jake Stauch: I think it’s the latter. I try to be embedded with the customers—full immersion. I am in every single customer Slack channel. I think most of our customers will get a Slack from me in that channel every single day. Pat Grady: Wow! Jake Stauch: And that is a huge—maybe … Pat Grady: And just to set the context. A listener might think, like, okay, you probably have four customers. How many customers do you have? Jake Stauch: No, we’re 100 customers. Pat Grady: Okay. Jake Stauch: And a lot of large enterprises. And it is overwhelming at times to be in all those conversations all the time. And sometimes I feel like, oh man, am I wasting my time? But I feel like I really understand what’s going well, what’s not going well, and I just have my finger on the pulse. And there’s just no substitute for that, especially when a lot of the implementation work has gotten very fast. More and more of the moat for any startup is the customer insight, the empathy of actually understanding what they want. And if we can have a differentiated advantage around the customer insight, that’s going to be much more valuable than having a product advantage, which is copyable overnight. Pat Grady: Let’s talk more about that, because this has been a hot topic for a few years now. ChatGPT comes out in November of 2022, and immediately people start deriding application layer companies as wrappers on top of a foundation model, right? And what you just said kind of plays directly into this theme of there’s always this school of thought that says the foundation models can just do everything, and then there’s a school of thought that says sure, but you can build a company on top to close the gap between raw capabilities and actual customer problems. How do you view your role running an application layer company versus the role of the foundation models? Where do you think the moats form around your business over time, basically to the extent somebody listening is interested in how do you build an application layer company in this era, what are your thoughts on that? Jake Stauch: I think you have to be happy when the new models come out, and that is kind of the guiding principle that we have is how do we make sure whatever we’re building is actually not made obsolete by whatever the labs and hyperscalers come out with, but actually is made better? Pat Grady: What’s a good example? Jake Stauch: For us, we think the product is the boundaries. The product is the controls. The product is actually what limits the capabilities of the model. Because the question now is not can Opus, can GPT-5.5 do these amazing things? Can they do the things I want to do in my enterprise environment? The capabilities are practically unlimited. The limitation now is how do I get comfortable as a large enterprise that cares about security in deploying this company-wide without elevating my security risk? And so we think about it from the boundaries. And that means really boring old-school enterprise software things around permissions and approvals and limiting the scope of your API integrations and having visibility into that, having audits and reporting and logs and alerts, and just all of the things that make you feel comfortable letting the models run wild in your environment. Pat Grady: Yeah. Jake Stauch: And so one of the fundamental things we did from an architecture perspective is kind of divide the agents into two parts. So our customers, when they experience Serval, there are really two agents they work with. One is the admin agent that helps build all of these tools and skills that configure what things the help desk agent can do and what it knows about. And so it’s the admins that build that. And then there’s a help desk agent that end users talk to that resolves their problems. The help desk agent can only use the tools and skills that have been expressly built and published with approvals and permissions and all of that by the admins. And that architecture, that kind of two-pronged architecture, ends up being really, really powerful, because you can let the help desk agent run wild, right? Because the end user can ask it anything, and it can use its reasoning ability and its full intelligence to be able solve user problems. But it can only use the tools that the IT admin has expressly said are okay to use. And those may have approvals attached, permissions that gate certain users from doing certain things. All of that is done on the admin side, but then you get the full ability and intelligence of the help desk agent to use those tools appropriately. Pat Grady: What’s under the hood? Is there anything you can say about which models you guys are having luck with and maybe how that’s evolved over time? Jake Stauch: Yeah, we use OpenAI and Anthropic models today, always experimenting with the latest models from all providers to make sure that we’re on the cutting edge, running eval suites on everything that we do. Today it’s still OpenAI and Anthropic models. We find different models are better at different applications. So for the interaction with the end user, we’re seeing the most luck with OpenAI models, and that has remained consistent for quite a long time that, you know, actually calling the correct tools and responding to the user in the appropriate way, that’s still—we’re having a lot of success with various GPT models and always keeping those up to date depending on the latest release. But on the automation side, which is mostly CodeGen automation, we’re having the most success with Anthropic models. Pat Grady: Interesting. Jake Stauch: Continuing to use Sonnet, Opus. And there are tons of tradeoffs between the different models. And I think what’s interesting in recent times is the new releases oftentimes are not just plug and play. Sometimes you get some advantages and some things that were working really well don’t work as well anymore. So that’s become an interesting challenge as things go. Pat Grady: Actually yeah, how do you guys manage that? How long does it take to incorporate new models into the production version of your product? How much of that process is automated in some fashion? How much of that is somebody just has to sit down and figure it out? Like, how do you manage that? Jake Stauch: It’s not as automated as I’d like. We have the evals automated, but then in every situation when we have a new model that we’re testing, some things get better and some things get worse. And a lot of the things that get worse—not necessarily because the model got worse, but we built a lot of prompt tuning and a lot of infrastructure around the known quirks or behaviors of that model—and those make less and less sense when the new model comes out or when you’re swapping models. And so that’s where a lot of the adjustments have to be made. Then you kind of run it through the evals and do a slow release across customers. So we’re getting better at this, but I think there’s certain cases where the tradeoffs have not been worth it, where we’ve actually upgraded models and then downgraded the models and said, you know what? The old models are maybe a little bit faster, or maybe they’re reliable in a way that the new models aren’t. So maybe the new models are a little bit smarter, but they misbehave in ways that are less predictable and we have less predictable guardrails to prevent against. And so we’re like, hey, this model might not be as smart, but we know it’s going to behave the right way for these customers. It’s been an interesting challenge, and it’s changed over time. Pat Grady: How much are you guys factoring cost into the equation right now? Because I think, you—one, step one, you’ve got to make sure the product does something magical. Step two, okay, now let’s make sure we’ve got a business, and we can extract an appropriate amount of value for this functionality. Do you guys think much about cost at this point, or we kind of know where that’s going over time, let’s make sure the product is magical and we’ll figure out the cost element later? Jake Stauch: It’s the latter. And I think one of the reasons that gives us this flexibility is that our unit economics end up looking much better than a lot of AI companies, because we are not in the business of reselling tokens. The way our product works is that you build these automations, which are basically TypeScripts. Pat Grady: Yeah. Jake Stauch: And once they’re built, you don’t have to rebuild that. So every time the end user asks for a password reset, it’s not going and regenerating code to reset a password, it’s actually just running the code that’s already been generated. Over time, users have to generate less and less actual code because we have a growing library of automations that cover the very long tail of things that you might want to do. And so there’s not as much—especially in the very expensive CodeGen token consumption—there’s not as much as you’d expect. And so the economics are very strong even though we haven’t done a lot of optimizations around that. So I try to tell the team, spend more money, use the best possible product. We know long term where this is going, we know that there are all kinds of optimizations we can make down the line. So that’s been our focus to date. I think where it starts to get more interesting is as we explore more and more applications of background agents, long-running agents that are not just responding to help desk requests, they’re not just building quick scripts for you, but investigating all of your historical tickets, or investigating logs from devices and doing all this work in the background and maybe generating solutions to problems you didn’t know you had. That’s where it becomes a little bit more interesting, where maybe the costs become more relevant. So that’s where we’ll probably start to think about costs a little bit earlier in the journey, because those could run away pretty quickly if you’re not keeping an eye on it. Pat Grady: Yeah, that makes sense. Let’s say somebody at OpenAI or Anthropic wakes up tomorrow and they’re like, wait a minute, I found this company called ServiceNow and it seems to be like a major system of record, a major center of gravity inside the enterprise. I think we should build, as a first-party product, the OpenAI ServiceNow or the Anthropic ServiceNow. If they set their sights on you and come after you directly or come after your category directly, what would that mean for Serval? Jake Stauch: Yeah. I mean, this is always a really tough question, because on the one hand, any response to, like, okay, this company with infinite money and the best engineering talent and AGI wants to do what you do, how are you better, any response to that is going to sound pretty naive of like, “Well, we’re just gonna, like, beat them.” But I think the history of startups tells us that often the smaller company does beat them. I mean, the existence of OpenAI and Anthropic are kind of proof that you can beat the entrenched incumbent with infinite resources. And I think it comes down to maybe divine providence favoring startups or maybe a lack of focus is often what makes it hard to execute. And so when I was starting my first company in the whole, every VC would ask me, won’t Google just do this? And yes, Google will do a lot of those things, but it actually is very hard to do a lot of different things really, really well, and it’s hard to divert your focus into all these categories. And I don’t think ITSM makes the most sense as a focus area. One reason is that I think in the past couple of months, Anthropic has added more ARR than ServiceNow has in the past 20 years. Pat Grady: Good point. Jake Stauch: And so does it really make sense for them to take their best and brightest people and throw them at this problem that even if they’re very successful would take them years to get what they could get out of the rest of their product portfolio in a matter of months? And so I don’t think they’re going to—they’ll probably look at this category, and I wouldn’t be surprised if they built some kind of simple version, maybe a more mid-market or SMB-focused version. But to really devote the time and energy to master the complexities of enterprise service management—not to say they couldn’t, but the focus that would require, I think, would be a bad use and bad prioritization of their resources. And I don’t think that’s going to happen. Pat Grady: Yeah, I think you’re right. Let’s talk about your customers for a minute. So you’ve got a bunch of really nice AI-native logos, and you’re also starting to have some big enterprises. How do the needs differ from the AI-native crowd to the big enterprise crowd? And if you had to pick from each of those, what’s the nicest thing that they would have to say about you? You know, “Serval is amazing because—” what would they say? Jake Stauch: Yeah, I think what’s been the biggest learning is how similar they are relative to how different. I expected them to be much more different. But the pain points and the problems end up looking remarkably alike from the AI-native to the large enterprises. We work with companies as small as a few hundred employees up to companies as large as a few hundred thousand employees. The difference ends up being how many people it takes to make a decision, and that’s what actually makes things really challenging is because … Pat Grady: It’s more of a go-to-market thing. Jake Stauch: It’s a go-to market, it’s an implementation thing, more than anything else. So if you’re working with a company with a few hundred employees, there’s probably an IT leader that can say, “This is how we’re going to do things. This is how onboarding works. This is how we’re going to reset passwords.” Whatever. If you’re working with a company with a few hundred thousand employees, no one even knows who that person is, if that person exists. And so you end up in all these committees trying to figure out what should we do here? And that’s actually what makes it very, very challenging. And I think you see that in these labs building out consulting these businesses and more and more services and deployment resources, because that ends up being a lot of the rate-limiting step in adoption is coordinating all these folks. So what would the nice things they say about me—or about Serval? In the AI-native, early-stage companies, we often take an IT person that’s passionate about technology and we let them spend their time building. They got into IT because they love technology, and so much of their job before Serval, they weren’t really getting to experience technology. My favorite example of this is a customer we had that spent a lot of their day fielding ServiceNow requests to provision someone’s access to Cursor. Pat Grady: Yeah. Jake Stauch: And that juxtaposition was just so sad. I am in this ancient ticketing system helping somebody else at the company get access to a really cool AI tool, and my tools are still stuck in the past and I don’t get to use the cool stuff. And with Serval, they get to use the cool stuff. Like, there’s actually an AI tool for IT built for them. And so that’s what we see on the AI-native side. I think in the large enterprise, generally they’re thinking about it at just a higher level of business transformation. And we hear a lot more about the end employee experience, because at a small company, even if your IT processes aren’t perfect, no one’s waiting weeks to get a response back from IT. But at a large organization, you could send a ticket into the abyss and just have no idea where it’s at, if it’s being worked on. So then you’ll send another ticket, and then there’s confusion on the other side because now you’ve got two tickets from the same person, and there’s actually people that are blocked for weeks from getting back to the thing they’re trying to do. And so I think in a large enterprise, we actually change the employee experience and what it feels like to be an employee, and have this more broad impact because the problems are actually a lot deeper in those big organizations. Pat Grady: What is a delightful or surprising use of Serval at Serval? How do you guys use it? Jake Stauch: Oh man, I force the team to use it for everything. Pat Grady: [laughs] So where do they really push the boundaries? Jake Stauch: I mean, obviously things like office requests, snacks, like, all of that has to go through Serval. But I think one of the coolest things we do at Serval is one, we have a channel called Dream Team Draft. We take this very person-first approach to recruiting, where we want to identify the best people in the world and we want to bring them to Serval, versus just cast a wide funnel, host an open tryout and see who makes it. And so people put the best people they’ve ever worked with in this channel, they post to LinkedIn. That’s a Serval channel. So Serval will take that profile and then run a series of automations. One, it’ll run into all of our outbound campaigns, our nurture campaigns. It’ll also do a lot of things that my marketing team won’t let me talk about, like making sure that they are seeing Serval everywhere they go, and Serval becomes very top of mind for them. And we basically warm this audience to make sure that they know about Serval. And we’re playing the long game because these are generally not people that are going to leave their job tomorrow, but people that we’d love to work with one day. And so I love the idea of going in and saying, like, all I have to do as an employee is say, “I love this person, they’re great,” and I’m done. And the talent team will be able to, through Serval, have all these automations that kind of get them into the system. Pat Grady: That is very cool. What’s the best reason to work at Serval? Why do people join your team? Jake Stauch: I think it is the greatest group of people I’ve ever worked with. I think when you walk into our office and you meet our team, it’s just a group of people that are so kind and so talented and so fun to be around. And I think that’s what’s really unique is—I didn’t even know I was selecting for this when we started the company, but something candidates started telling me is that wow, your team is so nice and they’re so fun to be around, and I walked into the office and the energy was just contagious and I wanted to work there. And obviously there are really interesting technical problems, you know, building these very complex enterprise automations, getting to touch HR, legal, finance, IT security. It’s kind of a training ground. We often think about this as a training ground for anyone who wants to do anything in AI. You get to touch all these different departments, build all these cool workflows. But I think if I’m being honest, the reason you join Serval is because you meet the team and you realize this is the place for you. Pat Grady: Yeah, very cool. We heard some of the words you used to describe your culture—fun and nice and high-energy people. What is it not? Jake Stauch: It is not a good place for let’s say a lot of training or mentorship. So everyone is kind, but everyone’s doing their job. And there is not a lot of hey, you’re going to be onboarded through this program and you’re going to learn how to do these things, and we’re going to train you really well and pair you with some resources and coaching and mentorship. There are great companies that do that really well. We are not one of them. So we hire people to come in and basically be productive on day one and who like the ambiguity of I’ve got to show up and figure out what I’m supposed to do and then do it really, really well. So it’s not a place for coaching or mentorship. It’s not a place for very clearly defined career paths. We don’t know where a lot of these functions are going to go, so there’s not going to be a clear progression up the org chart—there’s not really an org chart. I don’t actually know who reports to me at the company. Pat Grady: [laughs] Jake Stauch: I am blissfully unaware of who technically reports to me versus other people, because we try to keep everything as flat as possible. And so if you’re looking for that kind of natural progression, it’s just not going to be a good place for you. Pat Grady: Yeah. As far as one of the big topics that we’ve had a lot of conversations on recently, just amongst founders and folks, is this idea of living in the future. And not only the product you build needs to be AI-native, but the way that you build it and the way that you manage your organization needs to be AI-native. Beyond using Serval itself, what does that mean for you guys? How has the way that you operate changed this time around versus Verkada or your prior companies? Jake Stauch: In so many ways. So one is we are questioning everyone’s role—every department—we’re wondering if it needs to exist anymore and if it still makes sense. And oftentimes it does. We relearn the necessity of some departments that we thought maybe we didn’t need. But we start with the assumption that maybe this doesn’t need a person anymore. Maybe this could be AI. So AI almost gets the right of first refusal for every job or every department of, like, hey, maybe we don’t need this at all. And maybe this can be much smaller or much … Pat Grady: Is there a good example of something that fully went to AI? Jake Stauch: Solutions engineering. So we don’t have SEs. We also don’t have SERs, but I think that’s been a less controversial take over the past few years. But we don’t have SERs and we don’t have solution engineers. Our reps are not necessarily more technical than reps in past generations have been, but they have access to Serval. And so any question they have about how the product works, or that a customer comes up with a prospect, Serval’s going to give them an instant answer to that question. Serval can even build them decks, build them one-pagers and quick battle cards and comparison sheets. Like, all of that on the fly in the middle of a call. So we expect more out of our AEs and they’re not going to have the SE resource. We do have four deployed engineers that assist with the actual pilot implementation, but that’s been one example where we didn’t need that. Jake Stauch: We also delayed hiring in a lot of domains. And sometimes not by choice, just by the slowness of our hiring, but we’ve discovered how far we can get. On the enablement side, we have someone in product marketing who’s done an incredible job of building out enablement and all these automated resources and scaled that quite far. And we definitely need more help there, but a lot of times you get further than you think with these AI tools. RevOps is another one where we’ve gotten pretty far without a RevOps hire, but then discovering that actually you do need somebody eventually. And so there’s a lot of these things where you delay it a little bit and then you’re like, actually, we need somebody, but maybe this department is a little bit smaller than we thought it was going to be. Pat Grady: Hmm. The company is about two-and-a-half years old or thereabouts? Jake Stauch: Just two years old. Pat Grady: Two years old, okay. And you guys have grown like crazy—more people, more customers, all that good stuff. How has your job changed in the last two years? Jake Stauch: In the very early days, I felt very useless, honestly. Pat Grady: [laughs] Jake Stauch: My CTO is building the product, and it’s very clear what we need to build. There’s so much to build, and I’m trying desperately to hire and to set up customer calls and maybe try to sell this thing, and it’s not working. And so I think in the early days, it was kind of like trying to figure out how I can be most useful when we don’t really have a business yet. And then over time, it switches and it becomes a business and stops being me kind of pushing the boulder up the hill and more the business dragging me along. I think what hasn’t changed is I’m still very involved with customers, both in the sales side but also in the long-term success and talking to customers every day. I’m still very involved in recruiting. What I’m not as involved in that I’d like to be is a lot of product. In the early days, I am thinking nonstop about the product direction. And now it feels like the product direction is kind of emerging from our customers through our four deployed engineers and going right into the product. And which is in many ways great, because you have this nice closed loop of customers talking to four deployed engineers and then the product getting implemented and getting better all the time. You know, I’ve often referred to this as, like, gradient descent for product improvements, because our four deployed engineers are just swarmed with all this feedback from customers and they’re like, “I’ll fix this, I’ll make this better, I’ll change this.” And you fast-forward a week and wow, the product is a lot better than it was a week ago, and it keeps going that way. But I get to spend a lot less time thinking about the future and where we want to be. And I think that’s something that I need to spend more time on, because this stuff is changing so quick. To your question earlier about how are we different as an organization, an AI-native organization, I think a big difference is you have to be willing to reinvent yourself so much faster and disrupt yourself so much faster. Like, we are thinking about just uprooting things that we were convinced were true months ago and going in completely different directions and all these different ways. And we have to have that flexibility. We’re going to be renaming parts of the product. We’re going to be completely shifting how we do certain things in the product. And we have to be willing to do that over and over and over again. And there’s going to be less of this idea of, like, I am building software that’s going to last for 20 years, and more, I’m going to build software that hopefully will last six months, and then I might have to rebuild it once the paradigm shifts and the markets have changed. Pat Grady: Yeah. And let me ask you about that, because there’s a foundation model on one side—or a set of foundation models and capabilities—there’s a customer on the other, and there’s Serval in the middle. And these capabilities are changing at a very rapid pace. This customer is probably not changing all that fast. And so you guys in the middle are kind of this buffer that is trying to take all these capabilities and put them to work for the customer. So the question is really—it’s kind of a change management question. Like, how do you keep the customer from drowning in this downpour of capabilities coming out of the foundation models? Jake Stauch: I think that’s exactly the right way to think about it. We are kind of that translation layer. Pat Grady: Yeah. Jake Stauch: And we have to meet customers where they are. I think we very much have to understand their business problems, and that’s what really helps with the four deployed engineers is we are starting with their business problems. What are they trying to solve for? And then we are helping them discover how those solutions are implemented in Serval. We are on the other side figuring out how to take in the latest advances in AI to be able to deliver those solutions. And so that is kind of the role we serve. And then we’re often educating them of, like, hey, here’s how we do this. And by the way, it’s changed since how we would have done this three months ago. And we have these new tools at play, but we will be the ones to help figure this out for you. And one of the things we’re working on is how can we bridge that gap a little more succinctly, so how can we make an agent available to the end user that kind of says okay, what are your business problems? Cool. Here’s what we’re going to do. Here’s how we’re going to solve them. So you don’t really have to think about the latest advances—Serval just kind of takes care of that for you and you just have to focus on what are your problems, what are you trying to achieve? Pat Grady: What’s your most contrarian take on the world of AI? Jake Stauch: One take that I have—which I don’t know how contrarian this is—but I think there’s this big gap emerging between who wants autonomy and who wants control of these agents. And the individuals in an enterprise, they want autonomy. They want their Claude agent to do everything for them and have access to everything. The organization itself doesn’t want their employees’ agents to have all this autonomy. And there is this interesting tension emerging between—and I often see this in consumer-versus-enterprise products, where the consumer products obviously are built for a world where you want it to do everything, and the enterprise products are built more with this control layer. And what’s happening in the enterprise is that the individuals are adopting these tools and wanting them to be able to do more, and the security organization and the IT organization are very worried about this. And for good reason. And I think that’s something interesting to track—this tension between autonomy. Do organizations actually want autonomy? Or do just individuals want autonomy? And how do you navigate that tension? And that’s where we’re thinking a lot about the Serval product and how we help solve that. Pat Grady: It reminds me of shadow IT back in the day when consumers started to adopt iPhones and enterprises still had BlackBerrys. Jake Stauch: Yeah. Pat Grady: Because they could lock down the BlackBerry, and the iPhone started to show up with work information and then work applications, and they’re kind of sneaking their way into the enterprise. And the instinct of most CISOs was protect, protect, protect. And then I think eventually they realized well, wait a minute, this is kind of the leading indicator on what my employees need to be productive. And they started to embrace it, right? And it feels like the same thing’s happening now with AI, where a lot of employees kind of know what they need to be productive, and as long as you can just kind of systematically follow those signals and embrace it, you’re more likely to end up on the right side of history. Jake Stauch: Yeah, and I think the companies that basically say yes as the default are going to be way ahead of the companies that say no as a default. And we’re seeing this with the companies that just embrace it. They will also kind of be leading the charge and face a lot of the consequences of there are going to be security incidents, there are going to be problems, and we’re going to learn a lot from those. But I think that’s what we’re going to see is the companies that take those risks are going to get ahead. But those risks are real, and they’re also going to be some of the ones that suffer some of the consequences on the security incidents. Pat Grady: What’s your biggest issue at the moment? Jake Stauch: Our biggest issue is hiring still. Every AI company I talk to is in the same situation. Even though AI is allegedly supposed to automate all this work and take away all these jobs, we’re all still hiring more than ever before. And it’s still our number one priority and our number one concern. But I think people remain the biggest moat you can have, and having better people in the room is really the only thing that will keep you ahead of the competition. It’s the only moat that’s left is the people in your organization. So hiring and scaling and keeping the bar incredibly high as we hire are the things that keep me up at night and worry me, especially as the business grows so much and I’m less involved. You know, there’s a lot of people that I will only meet in their interview and their onboarding, but not have a lot of one-on-one interactions with after that. Pat Grady: Yeah, the talent density point, I think, is a good one. And we think about that a lot too, because we’re sort of in this world where cost goes down, capabilities go up, and the result is accelerating change. If the world is changing quickly around you, you have to optimize for agility. The best way to optimize for agility as an organization is to have the smallest possible number of the best possible people, right? And so I feel like the returns-to-talent density have never been higher than they are today. And you guys could go hire a million people, but doing so with the sort of quality and culture fit that you need, that’s tricky. Jake Stauch: And to your point, it makes it harder to turn the ship. Pat Grady: Yeah. Jake Stauch: And so our mantra on hiring is fewer, better. Fewer, better. Like, we say this over and over again: fewer, better. How can we make this department fewer and better? And that’s going to be really important because again, I think we’re going to have to reinvent ourselves more frequently than companies have ever had to do this before, and I can imagine a future version of Serval where it’s unrecognizable from what we do today because we just had to adapt so quickly. And that’s much easier to do with a small agile team than if you scale very rapidly and become thousands and thousands of employees and you say hey, by the way, we’re changing everything about our go-to-market, we’re changing everything about what our product does. Pat Grady: Yeah. Jake Stauch: You know, we’re making some big changes to the product, and it’s nice to have a relatively small organization that can embrace that shift almost overnight. I can’t imagine what we’d do if we had to convince thousands of people that this is the new direction. Pat Grady: Yeah. Let’s assume—and obviously this is not something we can take for granted, but just for fun—let’s assume that Serval becomes a monster company. You know, a gazillion customers and employees and revenue and market cap and free cash flow and all that great stuff. Let’s assume you become a monster company. At that point, what would you want people to say about you? What else would you want to be true that is not contained in one of those traditional metrics of scale or success? Jake Stauch: I think I would want the impact of Serval to be very clear in terms of what it did for the world. The impact, I think, that is most important of what we do today is we unlock meaningful work for people. You know, I think there’s always a gap between the idealized vision of what you think your job is going to be and then what your job actually is. I think it’s true for every profession. You idealize—and kids do this the most, right? When they want to be a firefighter, an astronaut—what that job looks like. And then you get into that job and you realize, oh, there’s actually a lot in this that I don’t like. And we want to be the tool that actually closes the gap between what you think your job is going to be and what your job actually is. And we do that by automating away all this repetitive, menial work that you don’t want to do, that is not productive and is not part of the reason you took this job. And we’ve done that in many ways for IT. And I think as we unlock automation for the entire organization, that’s what we do for people is we get them back to the work that they actually signed up for and the work they actually enjoy. And so I would hope that there is clarity that that was the impact that we had, and it wasn’t just like, oh, Serval automated away a bunch of IT jobs. It’s like, no, I want people to feel like Serval made people’s work lives a lot better. Pat Grady: Awesome. That feels like a great place to end it. Jake, thank you so much for joining us today. Jake Stauch: Thank you so much for having me. This was a blast. <div class="framer-mcvrsd" id="