向 ServiceNow 发起挑战：与 Serval 联合创始人兼 CEO Jake Stauch 谈人人可用的编程智能体

This is the most ambitious project in the field of enterprise software. These agents do the work for you: they magically find all your problems and solve them. I think no one has really figured out how to do that well yet. We’ve seen incidents at OpenAI, Hugging Face, and elsewhere where agents are given a task and do something unexpected. Agents can become quite competent, and theoretically they could start writing code that runs on your systems, which creates an unbounded security risk that I don’t think anyone would take on anytime soon.

On the one hand, you want agents to be autonomous and not need supervision. On the other hand, autonomy is very intimidating in a corporate environment. Serval is the limit. Serval is a fuse. We provide a way for large enterprises with lots of rules, approvals, processes, and policies to implement these tools safely and comfortably at scale.

1. Jake Stauch Introduction and Serval’s Background

Greetings, listeners. Welcome back to No Priors. Today, Elad and I are here with Jake Stauch, co-founder and CEO of Serval. Serval, with the speed of an African wildcat, is trying to attack ServiceNow and, more broadly, bring code-generation power to IT and enterprise teams in general. Congratulations, Jake. Jake, thank you for joining us today on No Priors. Nice to see you.

It’s great to be here.

Could you tell us a little more about your story, how you founded Serval, and what problem you started with, or why you started working on it in the first place?

Serval is an enterprise automation and service management company. The idea is that you can ask questions, get help with your work, and automate many of the parts of your job that you don’t like. We do that with code-generation agents.

We compete with companies like ServiceNow, a historically large, legacy provider in this space. I discovered this category while working at Verkada, where we sold enterprise physical security products to IT teams. I spent many years talking to IT teams and figuring out what to build for them. One thing I loved asking was, “What do you spend the most money on, and what do you hate the most?” ServiceNow topped many of those lists.

I was always interested in the category and thought there might be a better solution, but I was confused about how anyone could beat ServiceNow. They’re a great company and have done so much so well. How could you compete with them?

What was upsetting users?

I think it’s very difficult to create something on the platform. It’s reliable, flexible, and powerful, and it can adapt to any corporate process. Essentially, it’s a platform for automating workflows. It can do a lot, but every great idea needs to be implemented, and that often requires consultants.

As a result, it’s always 6–12 months behind where you need it to be. That’s acceptable if you’re building something for 5–10 years, like a big adaptation process, and your business isn’t changing. You can put in all the effort at the start, and then it works for a while. But when you’re trying to keep up with all the automation you want to implement, ServiceNow simply can’t keep up. It’s also very expensive, and the price only increases over time. So the main frustration was that it couldn’t keep up with the pace of business and was becoming more expensive.

2. Expanding Coding Agents Beyond Engineers

An interesting point about your work is that a lot of the early use of AI in the enterprise is agents for programming. Engineers use them to create business applications, products, and so on. What you’re doing is expanding that category by allowing anyone in the company, like an IT professional, to create internal products or tools for the whole organization. You’re providing agents that can program for people and handle internal tasks.

Yes.

For people who often aren’t very good at programming. Can you tell me more about this? I find it fascinating.

We like the idea of agents programming for everyone else because, if you think about it, a lot of the early adoption of AI in corporations was by engineering teams. There are many reasons for that: they’re early adopters of new technologies, and they can build and experiment with these tools because they have a code review process. It’s very safe: even a 19-year-old intern can create something powerful, and it can be validated before going into production.

We want to provide the same opportunity to all other employees in the company. We’re building a platform that gives IT departments agents to write code, which they can then pass on to HR, finance, and legal departments. They can do this because, under the hood, agents are writing code, but there are abstractions, safeguards, and controls to make sure everything goes through approvals, testing stages, approval cycles, audit trails, and so on.

3. Limitations with Personal Agents in Enterprise

How do you build a system that allows everyone to become a developer? The key insight was that IT departments actually want to build products. Most companies in the world don’t have an engineering department; they only have an IT department. IT builds and configures technology for the company, and we’re essentially creating an AI platform for them.

How does this relate to all the other work agents currently in development, like Dot from OpenAI, where you have a virtual assistant that does the work for you?

I think those are great for consumers, small and medium-sized businesses, and even many mid-tier organizations. In large corporations, there are so many processes related to approvals and what can and can’t be done—something I didn’t even realize at first. Everyone’s permissions are so limited that even if you were allowed to bring your agent to work, which is prohibited in many cases, there’s very little it can do. It can barely read your emails.

When you think about all the things you need to do at work, all the systems you want to access, and all the automations you could create, your personal permissions are so limited that these personal agents become completely useless. We can work with IT teams, which can connect through service-account credentials and admin rights, to create a structure where people get access to advanced permissions and can do complex things. But that access is managed through strict, deterministic approval cycles, clear workflows, and an audit trail. Under the hood, we’re also a ticketing system.

You can say, “Okay, I want my agent to do X, Y, and Z.” Most large enterprises would be very unhappy with that. But with Serval, it creates access requests that go through an approval process, and everything is documented and logged. Then you get just-in-time access to run a deterministic workflow once, and it’s all tracked. It’s a little more annoying than the magical personal-agent experience we love in Instinct, Muse, and other tools, but it’s something that needs to be in place for a large company, especially in a regulated industry, to adopt these technologies.

This also seems to fit with the traditional deployment of this technology, where consulting firms like Accenture and Deloitte control part of the process and implement it for clients. You take it and hand it directly to the IT department. Are you exploring this as a forward-deployment model, or how do you make it work effectively within the enterprise?

Definitely. Distribution is obviously the main gap. The technology can do so much, and businesses have barely touched the surface of what’s possible. A big part of this is understanding the people and processes: what workflows actually exist, and what do you want them to look like in the future? We believe that still requires people.

We send deployment strategists, as we call them, and field software engineers who work on the ground with customers. They figure out how to implement it and solve business problems, then guide customers through the entire implementation process. But we’ve found that often, after we’ve implemented and deployed everything, customers are left with a long list of things they want to do.

4. Token Maxing, Long-Term Budget Impacts, and ROI

As we’ve learned in software development, the demand for work is unlimited. So we started building a team called Pro Serval, or the automation engineering field. We bring in automation engineers for ongoing support and service because customers want to automate so much. They need help understanding what can be automated, what the processes look like, how to work with all our systems, and how to make it work with a product like Serval.

How old is the company?

5. Hiring Velocity and Unlimited Ambition at Serval

Two and a half years.

If you look at ServiceNow as a business, I think it’s one of the few companies directly attacking and replacing corporate accounting systems, even in large companies. Did you think at the very beginning that you could do this? How do you eat this elephant, considering how big their product package is?

I like to say that everything is going exactly according to our very crazy plans. From the very beginning, we set a goal to become the largest enterprise software company of all time. We made a list of all the companies, circled ServiceNow, and said, “We’re going to beat them and build something much bigger.”

We said it on the very first day, when it was just the two of us in my co-founder Alex’s living room. We just decided we were going to do it.

And although it was crazy, that was our intention from the beginning. We didn’t grow into these ambitions gradually. We targeted this from the beginning.

I think people would typically start with automation on top of their ticketing system.

Yes, that’s right. Startups that try to compete with large corporate giants typically either build a “superstructure” or go after the lower end of the market. Those are the 2 most common approaches. Building a thin layer, trying to play nice with the big players, and adding an AI agent on top of everything never works. It limits you a lot. Maybe the only example that worked is Vevo or something like that, right? They started on Salesforce and then migrated to become their own platform. That’s the only example I can think of where they did a backward integration. It’s really difficult, and it limits you unless you find a niche you can expand into later.

Another approach is to go after the lower end of the market and serve small and medium-sized businesses. You see this with many of Workday’s or Salesforce’s competitors. They simply say, “We’ll be the same, but for smaller clients.”

We looked at that—it’s like Rippling or HubSpot.

6. Taking on ServiceNow with Workflow Automation Platform

Exactly. We looked at this and asked ourselves: Why not go after the big player right away? It’s much more difficult, but the payoff is pretty big if you win. I think that was extremely important for us, because you make completely different decisions when you’re building a product for large enterprises from day one. All the product decisions, the way you build the team, and the way you think about development are fundamentally different from a situation where you work in one market and hope to expand later.

How did you choose this option over Salesforce? There are a few other canonical giant companies in different categories. How did you understand how you could beat the other companies, where you had an advantage, and what AI had unlocked that they couldn’t catch up with?

Through our experience in IT, we understood that ServiceNow is fundamentally a platform for automating workflows. My co-founder and I had the idea early on that code was the right way to express automation at the enterprise level: all automation should be built through code. These drag-and-drop builders are a painful level of abstraction—too complicated for nontechnical users and annoying for technical specialists. Code is the best way to build automation.

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

The problem, of course, is that few people know how to write code and do it fast enough for automation to be worthwhile. When AI made it possible, it dawned on both of us: if code is the right path for automation, and now everyone can write code, we can build a better platform. What is an automation platform, and what is the best market for it? This is a real challenge for huge legacy software companies like ServiceNow.

But 2.5 years ago, when you started, most coding tools were just autocomplete. It didn’t work.

Yes, and that’s why… But in practice, when we started building it…

What was the assumption? Was it that programming would get much better, or that you would create tools you wouldn’t need later because everything would get much better? I’m interested in this transition.

The bet was that the agents would become very skilled at programming. The theory was that it was a well-defined field and should develop quite well. We fundamentally believed programming agents would become good at least at these kinds of tasks. I didn’t expect them to become that good at general software development, but deterministic procedural scripts—like resetting a password or getting approval—are so well-defined that we felt they would become good at them. From a workflow automation perspective, we believed they would succeed.

Although, in the beginning, it wasn’t like that. In all of our early demos, we would give a request to an LLM and say, “Hey, here’s a suggested way to build a password reset workflow.” We filled it with lots of examples, and over time we expanded the library. But the models became so good that it became difficult to fool them. It was difficult to give them a workflow they couldn’t automate, if the appropriate APIs existed.

When you think about where coding agents are now and what your clients want, are you and Alex excited about them getting better? Are you worried? How do you think this will affect your product?

We’re really excited that they’re getting better, because it opens up a lot of possibilities we’d like to implement, such as better browser and computer use, and an approach to background and personal agents that can be very useful for businesses. So we’re happy with the evolution of this category.

We’ve always fundamentally believed that we don’t create LLMs ourselves. We create fuses. We create boundaries. Those boundaries are what the product is for us, because we give a large company with a bunch of rules, approvals, processes, and policies a way to use these tools safely and conveniently at scale. Serval is the limit. Serval are fuses. Improving intelligence makes our product more powerful, and it also encourages our customers to strengthen these boundaries and safeguards.

I really think access for individuals in businesses will become increasingly controlled. As access becomes stricter, you allow people to do less and less, and their access rights become narrower. I think that’s inevitable.

Why would this happen?

Before, I could have easily given you more permissions than necessary because I didn’t think you could do much harm. But if you have access to all of these agents, the damage you can cause with even slightly elevated rights increases. We see this in cybersecurity risks right now.

Certainly.

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

If I’m a large corporation, I’ll want to limit everyone’s rights to the bare minimum. That means you won’t be able to access documents or take any action unless it’s absolutely necessary for your work. But there will always be exceptions. We’re the layer that provides these exceptions and allows you to set up approval procedures, have an audit log, and create a corresponding ticket. By controlling how privileges escalate in a company, we become even more powerful and necessary the more you restrict end users’ rights.

Do you have a story or a successful example? People are taking a big risk by choosing you over a long-established supplier, right? I think it’s an investment of their own time. It’s a kind of personal risk. Why do this? Is there an experience from people who have already gone all the way?

I think we need to convince ourselves and our clients that Serval is a path to promotion at work. It shouldn’t be a risk you take in the hope of getting something in return. We have to convince clients: do this, and you’ll build your career. You won’t just avoid problems; you’ll actually get a raise.

And it works from the top down, right? So you sell it to senior management.

We sell this to IT leaders in many cases and then roll it out to other departments. The message is that people built their careers on ServiceNow. You’ll build your career on this new generation. And we see this come true.

For example, one of our largest clients is Fox. Fox Corporation implemented Serval company-wide, and the person who led this migration at the grassroots level was nominated for the company’s best employee award.

Oh.

And he received an award for his work there. That’s really what we’re working for: we convince our clients that this is a way not only to prove your value to the organization, but also to become the most important person in the company because you’re leading this change. We’re so important to the AI transformation story that I think this is something we can sell to our customers very successfully.

When you founded Serval, you seemed to be very forward-thinking. You knew coding agents, or coding itself, would get better. You knew there was a path to transformation. You successfully identified a promising market segment that was worth entering. What do you think will happen in the next 2–3 years, not just for your company but for AI in general? Is there anything else on the horizon that you’re really excited about, or any big changes you’re anticipating?

I think the consumer sector often gives us a window into what’s going to happen next in the corporate sector. It doesn’t always look the same, but I think it’s a pretty good window. So I’m very optimistic about what personal agents in enterprises will look like.

Just as email, Slack, and other tools have changed the way we communicate at work, personal agents will also become an important part of this. I think everyone will have their own personal agent that will perform tasks and delegate them to other personal agents. Your agent will communicate with other agents at work. I’m really excited about this, but how do we secure it in a world of growing cyber risks and concerns from large companies about what every employee’s agents are doing on their computers and in their browsers?

This tension between what employees and consumers want from their personal agents at work and what businesses need from a management perspective seems really interesting to me. I think there will be a lot of opportunity in this tension.

Do you think there will be separate personal and work agents?

I think so. I think so. Yes, I think so. Just like I have Gmail and corporate email.

9. Adopting Different Sets of Building Principles at an Enterprise Level

Assuming that—I mean, there are a lot of different ideas here, but one is that exceptions or access control will become more complex and require a different level of scalability, right? The other is that there will be more automation in general because people will implement it everywhere if you make it easy.

Are there any core design principles, beyond code generation being the primary form of automation, that you’ve implemented in the product to reflect this?

I think the most important thing is the software development life cycle. In an engineering context, we take for granted that there’s a development environment, then a staging environment, then a production environment. There are barriers between them, and maybe you have branches people can work on without breaking other systems.

Sorry, just to be clear: IT automation doesn’t work like that today. In some cases, it does, but I think most new AI products don’t take this into account. They’re essentially saying, “Hey, let’s build these cool agents and release them into production.” But if you’re a large enterprise, you actually have to follow the SDLC process. A large financial institution isn’t going to release new agent capabilities without validation, user testing, and all that.

We think a lot about what will convince the biggest companies in the world to adopt this technology—not just what’s powerful and cool, or what we’re trying to convey to customers. It seems like many AI companies, especially if they’re vertically focused, take a year or two to figure this out, and sometimes longer. It’s interesting to watch the entire industry adopt on-premises deployment models and start thinking about the software development life cycle, compliance, and other aspects of enterprise operations, which were almost nonexistent before.

I think some companies never get to that point. They look at what enterprise software requires and decide they don’t really want to do it. You look at the history of many of the companies we mentioned earlier that went to the lower end of the market. Sometimes they still see an opportunity to build for corporations, but that requires a completely different set of design principles and products to develop, and some just don’t choose that path. They see this as a field for other companies. We decided to say, “Hey, give us your toughest problems, and we’ll solve them, making AI transformations possible in this crazy world of risk and governance.”

When you do a deployment, you have engineers in the customer environment, then continuous automation specialists, and then the core platform. How do you decide what gets migrated to the main platform and what stays in each individual customer’s environment?

When we deploy software, I think it’s very important that we never build custom features. We don’t develop custom product capabilities, and fortunately for our category, no one asks us to. Everything people ask for is something every other customer will want sooner or later. They may affect prioritization, but they’re still things we’ve always wanted to see on the platform.

Because it’s a code generation platform, what you create in Serval is very unique. The process of resetting a password at one company will be very different, oddly enough, from resetting a password at another. It’s the same with onboarding and offboarding: all these internal automations look very different, but they’re built into the core primitives of the platform. Serval almost becomes an IDE for IT and other departments to build and manage their automations at scale.

If we see the same customer building the same automations over and over, and having to configure and create them in the product each time, we start thinking, “Hey, shouldn’t this be a full-fledged feature of the product?” For example, we’ve seen many customers create workflows to identify knowledge base articles that conflict with each other or are outdated. We said, “Hey, we should do this automatically.”

We had clients set up automations to reclaim old licenses—that is, software licenses they pay for but no one uses—and automatically cancel those subscriptions. We decided to build that into the platform. This is a way for us to test what should become a full-fledged feature and what should remain an automation in Serval.

Our enterprise customers have come a long way this year in how they think about overall code generation costs for development teams, right? They say, “We’ll let people try.” Then they’ll use the tokens to the fullest, and then they’ll limit it and figure out who’s actually working productively. How do you think this impacts your business, and what do you think about the actual value of intelligence?

We’re still watching that. I see our CIO clients trying to move away from that initial era of maximum token usage, but I also believe we’re so early in the adoption curve that there won’t be an overall reduction. In fact, it will continue to grow rapidly because most companies are still figuring it out for the first time. They’ll all go through this cycle of rapid initial implementation, then some cost cutting and an effort to measure and calculate ROI.

What I keep hearing from our clients isn’t so much concern about the long-term impact on the budget. They understand there will be a short-term setback, but they still plan to increase spending. What they need is more evidence of return on investment. I think that’s what’s transforming the industry: people are looking for ways to prove these expenses are producing results, and it’s hard.

I don’t think anyone has really figured out how to measure the value of the tokens they receive, but I think there will be a huge opportunity to show the work that’s been done and compare it to work that would have been done on other platforms, with different cost models or workforces. That’s why our clients ask us to help prove that it’s worth it. That is precisely the task. This is what we have to do.

We try to set prices based on the workflows performed because I believe that better reflects the actual work than tokens alone, which tend to indicate verbosity and inefficiency. I think we’ll all find different models to prove the value of our work.

One of the topics people are talking about is a kind of “SaaS apocalypse”—the idea that people will just build their own in-house SaaS software, and all these categories will disappear. Many people, returning to your point about calculating the payback on tokens, are trying to understand whether it’s worth rebuilding these systems at all, and whether it can even be done effectively. What’s your view on the “SaaS apocalypse,” or this shift from SaaS to AI?

All the companies I’ve talked to that have tried to build these tools in-house, especially core systems of record rather than highly specialized solutions, have found that developing and supporting enterprise software is quite expensive. Even if you can do it, in many cases it isn’t economically feasible unless your needs are very specific and unique. Buying ready-made solutions for something that isn’t your core competency is the eternal “build versus buy” argument. I think that’s as relevant now as it’s always been.

Creating enterprise software is still difficult. Many companies are discovering, or relearning, that enterprise software is complex and requires people to maintain it. There are use cases and edge cases, things that break and need to be updated. You have to hire a team and pay for that work, and no one really wants to work on an internal tools team. There are all these problems with this approach.

I see this with point solutions, where many companies have hundreds and hundreds of SaaS applications. They probably only need two or three dozen tools. I believe the number of individual solutions will decrease; they’ll be absorbed by the core systems of record and key platforms. Middleware, I think, will also simply disappear.

That’s right. That’s right.

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

So I think there will be consolidation. There will be a SaaS apocalypse, but precisely among small-cap companies that offer point solutions. I don’t think you can really do without the core accounting systems: ERP, HRIS, ITSM, and CRM. I think they’ll stay. They can transform, and what we see with Serval is that we’re displacing these tools. I believe a new generation of market leaders will emerge, but I don’t see these categories simply disappearing.

I’m curious what your mental model or theory is about the IT user, given that they’re not software engineers, but they understand their business and what they’re trying to automate. You talk about “vibe coding,” and I think, “Okay, but do you understand security architecture? Do you understand how this will integrate with government administration? How do we combine code generation, our vision of vibe coding and the challenges associated with it, with the desire to build reliable IT systems?”

Yes, definitely. I find IT a very interesting field because they’re closer to software engineers than many people think. Especially in large companies, the IT department is in many cases the engineering team. They don’t have a separate development team, so IT manages all these systems, and IT professionals often write the code and administer the systems.

I think we should treat them like adults. We give them the tools we would give software engineers, although we abstract some of the complexity. We make them easy to use to some extent; we don’t just give them Claude Code and wish them success. We create a platform specialized for their tasks. We don’t necessarily require them to be able to write code or understand it, but we provide access to it under the hood.

You can always see the code and work with it throughout the development life cycle, but you’re not obligated to do so.

11. Building Automations with Catalyst and Raising Technical Competence

A significant part of the product’s principles is targeting several different users: from an IT engineer who really knows how to code to someone in marketing or HR who doesn’t want to see code at all, but still wants the flexibility of generating code under the hood because they have a complex workflow they don’t want to build using drag-and-drop. I think it all comes down to taking different types of users into account and respecting IT professionals as adults. A lot of products on the market treat IT a bit condescendingly, as if to say, “You don’t understand this, so you need a simplified, more limited, more opinionated version.” In fact, IT professionals appreciate the complexity and power of these platforms. We want to give them that opportunity.

You’ve created an agent that helps people build automations. Can you explain how it works?

12. The Next Wave: Background Agents and Autonomy in Enterprise

One thing I think every company discovered while building the first generation of these AI tools is that you can build incredibly complex systems, but then you have to train people to understand all the primitives in your product and how those systems interact. In the first generation, we had a bunch of full-time employees explaining to customers, “Okay, here’s how to build on this platform,” or even, “Let me just do it for you.” Then we realized it would be great if customers could simply communicate with an agent that understands their requirements and translates them into product primitives.

So we created an agent called Catalyst that does just that. It’s an agent for managing the platform, for administrators. It helps create basic automations, configure approval rules, check access rights, develop different policies, update systems, and understand the entire deployment process. Since Serval does full code generation under the hood, having an agent to help you manage the system is completely logical and very powerful. You don’t need to learn how to use Serval on your own. You can simply talk to an agent that understands how to use Serval and build on it, and that becomes your primary interface for interacting with the product.

One thing that’s underrated, and that I think is cool, is that experience with agents in different products and with code generators—being able to walk a user through a product or project—actually increases the technical competence of a huge number of users. It turns people into real engineers.

Yes, certainly. With older generations of automation, you had the problem of a “clean slate”: where do you even start? You know you want to automate all these parts of your job, but where do you start? Products like ours ask, “Where do you want to start?” They can make suggestions, and you can interact with them and say, “I honestly don’t get it. What do you mean? Can you explain this to me? I’m trying to do this. How do I even go about it?” They can give you that information, find it, and explain the concepts to you.

So it becomes a partner in creation, and you can achieve much more than by just giving an agent a command to do something. It can guide you through the entire process and help you explore new possibilities you wouldn’t have thought of.

Another thing that seems to be under-discussed right now is background agents. Could you tell us more about what you think of them and what you expect from this next wave?

13. The SaaS-pocalypse and SaaS vs. AI

I always describe background agents to companies as the “project of the month” in enterprise software: these are agents that do the work for you, magically finding all your problems and solving them. It would be great if we could deploy them so they work while respecting our access rights. I don’t think anyone has figured out how to do that well yet, because on the one hand, you want them to be very autonomous, able to figure things out on their own and solve problems without constant supervision. On the other hand, autonomy in a corporate environment is very intimidating. You really want to see exactly what they can read. There have been incidents involving OpenAI, Hugging Face, and others where agents were given a task and did something unexpected to complete it.

So what guardrails can you put in place?

That’s right. How do you treat your best employees? You give them a general, high-level mission and say, “Go, don’t bother me, do this,” and they come back having done incredible things. I want to trust agents to do the same for me: give them high-level tasks so they can solve the problem and come back with the result. I don’t think we’ve figured out how to do that safely.

Mm. In a corporate environment, how do you think this can be made safe? People have experimented with various things over time, from Constitutional AI to certain forms of reinforcement learning. I’m wondering if you have a ready-made solution, or if it’s just—

We look at this in large corporations as a gradual build-up of capabilities, although it’s not ideal. The agent goes to do a task and comes back with a request: “Hey, I want to be able to do all this. It would help me at work.” And you approve it. These are all deterministic workflows: “I want to use this tool. I want to run this script that does X, Y, and Z. Can I do that?” You approve it with certain permissions and safeguards, saying, “Okay, yes, this is allowed. This is allowed. This is allowed.” Over time, the agent becomes quite competent because it has a large enough set of tools to solve most problems.

It’s not ideal because it’s exhausting to constantly monitor this process. But I think it’s necessary, because otherwise the agent could theoretically start writing code that would take actions on your systems, which would be an unlimited security risk that no one is going to take anytime soon.

What do you think, in terms of what excites you? Are you and Alex inspired by the future possibilities, or are we still missing some model capabilities? I ask because the ability to be proactive and anticipate what a person wants—Jake as a CEO, me as an investor, or just as a person—and do it well is still very difficult, right? You need a lot of data about someone’s preferences. Think about an employee who works for you. What are Jake’s real priorities? When he gives me a general task, what does he mean? Do you think this is a problem with the model itself, or is it entirely a matter of today’s limitations and safeguards?

Honestly, I think it’s both. I think memory should get better and better because you want the system to understand your preferences. You want the context to be incredibly large, because I don’t want to have a bunch of different chats with you. I want one single chat that goes back to our very first conversation, where you remember all the relevant key points.

I also think permissions will always remain the most important issue, because even if I feel that you’re a very valuable and intelligent agent who can do all this for me, to what extent can I entrust you with complete freedom of action so that I don’t have to constantly monitor your every move? We do the same with people, don’t we? Anyone who works for you should go back, report back, and ask, “Is this what you wanted? Here are 3 options.” So I think this is a completely normal workflow, right?

14. Day 1 Ambition and Attacking Enterprise Systems of Record

Yes. The company is about 2 and a half years old. You’ve reached at least the level of a mature enterprise product very quickly. How big is the team today?

Today, we’re 200 people.

200 people. In January? It’s been a year of incredible growth. This is an impressive year. First, do you expect the hiring pace to remain this high? And, as someone who believes in AI, why? Secondly, you and your team have worked at startups before. How has your way of working over the last 2 years radically differed from the previous 10?

I think the hiring rate will even increase compared to today. We believe that the demand for work, competition, and ambition are limitless. So while every employee today does significantly more than they did a year ago, we have even bigger plans for what they’re capable of. Since every worker has become much more productive, we actually want more of them, not fewer.

Given your experience at Verkada, how have you been working differently in the last 2 years than in the previous 10?

I think the uniqueness of Verkada, our category, and the current moment is that our market is unlimited. It seems that the available market depends more on the size of our ambitions than on the fundamental limits of how big this business can become. Since we’re essentially automating every job for every worker in the world, this market is only as big as we want it to be. It really depends on how fast we can grow and what our ambitions are, not what the market looks like.

Here’s what we think we can really do. It’s a whole different set of challenges. It’s not that it’s better, because now we have so much open space and so many decisions to make about what to focus on. But it’s really interesting not to be limited by what the market allows.

15. Keeping Pace with Customers and Fundamental Shifts in Product Function

Given such a large scale, how do you organize the rhythm of work or, say, the EPD team?

We’re integrated into working with clients. Even engineers who aren’t directly involved are in customers’ Slack channels. We talk about customers nonstop. They hear customer feedback every day. Most engineers participate in at least 1 customer call per week. I think most of them actually have at least 1 client call a day.

It’s like immersing yourself in a country’s linguistic environment to learn a foreign language. You become so immersed in the mindset of your buyer and client that you begin to understand what they want. You understand their mindset and adapt to changes in their preferences in real time.

As they move with the market and start talking about different products they’re trying out and things they’re excited about, our engineers are constantly aware of all of that and can adapt very quickly. We decentralized product development, essentially handing it over to a team of engineers. We don’t have a separate product department because the engineers are the ones who talk to customers every day, and they can respond quickly to what customers are saying today or this week, compared to what they were saying a month ago.

This sounds like a really natural way to keep up with the fast-paced market and your customers’ changing priorities. How do you and management make sense of this, then?

Well, in a traditional enterprise software company, you have an architectural review. You have a quarterly plan, you set priorities, and you educate all your clients on new launches. You would be letting your clients know that things are going to change too quickly because they, too, can only absorb it at a certain speed. Yes, it is a big challenge. Our product comes out and changes often faster than anyone can keep up, including me.

We’re just trying to make sure that, first of all, the engineers we hire are really product-oriented. That’s one of the changes we’ve made: They have to really understand our customers, and we want to put them in front of the customers because they’re going to have to make so many decisions on the ground, and not every product decision can be passed to management every time.

This is a fundamental shift: You have to be willing to delegate a significant portion of product decision-making downwards, and you have to be willing to act quickly, cancel and go back if you’re moving in the wrong direction, and “kill your pets.” You have to be willing to change course on things you thought were fundamental to the product and change your approach when your engineers say, “Hey, the customer now sees it this way, and here’s what we need to do differently.”

One of the things I’m most proud of at Serval is how many times we’ve decided to erase what we’ve done in the past, what we’ve been very committed to, and just say, “You know what? The market has changed, the customer has changed. We’re going to do things completely differently.” I think that’s what has allowed us to keep up—this ability and willingness to reinvent ourselves over and over again.

Some of the most enduring things in this era. Thanks, Jake.

Thank you, Sarah.

16. Conclusion

Find us on Twitter at No Priors Pods. Subscribe to our YouTube channel if you want to see our faces. Catch the show on Apple Podcasts, Spotify, or wherever you listen. This way you will receive a new episode every week. And subscribe to the email newsletter or find transcripts of each episode at no-priors.com.