Serval Bets Boring IT Controls Will Unlock Enterprise AI

Serval is a platform for employee support, or Enterprise Service Management: the machinery by which employees get help at work. Jake Stauch describes the ideal version simply. An employee asks for access, an approval, a fix, a reset, information, or help navigating company systems, and gets a resolution instantly, without waiting for a ticket to be triaged, assigned, and worked through by a human.

The hard part, in Stauch’s account, is not whether a frontier model can produce impressive behavior in the abstract. It is whether an enterprise can let that model operate inside company systems without creating unacceptable security risk. He argues that the product in enterprise AI is “the boundaries” and “the controls” — the parts that determine what the model is allowed to do.

That makes Serval deliberately resemble “boring old school enterprise software”: permissions, approvals, scoped API integrations, visibility, audits, reporting, logs, and alerts. Stauch’s point is that these controls are not incidental compliance features. They are what let an enterprise become comfortable deploying AI broadly.

Serval’s architecture reflects that constraint. Customers interact with two agents. The admin agent helps build the tools, skills, workflows, and knowledge that define what the system can do. The help desk agent is what end users talk to when they need something resolved.

The help desk agent can reason about a user’s request and decide how to use the available tools. But it can only use tools and skills that admins have explicitly built, published, approved, and permissioned. Stauch describes this as a “two-pronged architecture”: the end-user agent can “run wild” conversationally and intellectually, but only inside a tool boundary established by IT.

That architecture also maps to a broader tension Stauch sees in enterprise AI. Individuals want autonomy. They want a Claude-like or general AI agent to have access to everything and do everything on their behalf. The organization often wants the opposite: control over what employee agents can access, execute, and change. Consumer AI products tend to optimize for maximum agency. Enterprise products need a control layer.

Pat Grady compares this to shadow IT in the iPhone era: employees adopted devices and applications that made them more productive before IT organizations were ready to sanction them. Stauch agrees with the analogy and argues that companies whose default answer is “yes” will get ahead of companies whose default answer is “no.” But he does not treat the risks as imaginary. The companies that move fastest will also encounter security incidents and other consequences from which the market will learn.

The claim is narrower than simply saying an application company can outmodel the model labs. Stauch’s case is that value in enterprise deployment comes from translating general model capability into controlled business execution: approved tools, explicit permissions, auditable actions, and workflows that fit how the company actually operates.

Pat Grady frames ServiceNow’s original insight as “workflows on top of a database.” Stauch agrees. “They got it right,” he says. Serval also uses workflows on top of databases. The difference, in his view, is that the older model made those primitives too expensive to create and maintain.

A workflow that takes weeks or months to implement can be structurally behind the business by the time it ships. If the company’s process has already changed, the automation is automating the old company, not the current one. The same problem applies to the database layer: IT assets and other system entries become painful if they require consultants or internal developers to keep current.

Serval’s answer is to use AI not as a loose end-user assistant, but as a builder and maintainer of the workflow system itself. An administrator can describe a workflow in natural language — the steps, permissions, approvals, and logic — and Serval generates the code for it. Stauch says the workflow “appears instantaneously,” with “practically zero time” required to develop it. The same approach applies to databases: an admin can describe what data should be pulled from which sources, and the system generates code to fetch it and keep it up to date.

That design follows an operating rule Grady recalls from earlier conversations with Stauch: if enterprise automation is going to spread, building the automation has to be as simple as, or simpler than, doing the thing manually. Stauch says he still believes that. His example is a password reset. If an IT worker can either open Google Workspace, find the user, and click “Reset Password,” or instead open a workflow builder and assemble triggers and actions by hand, the manual reset wins. The person in the moment will do the thing that is faster. Automation only becomes the default if creating the automation is easier than performing the task once.

That ease creates its own failure mode. Grady asks whether there is such a thing as “slop automation,” analogous to low-quality “vibe coding.” Stauch says it is real. If automation becomes too easy, a company can end up with the twentieth password-reset workflow in a week, mostly duplicative of the prior nineteen. The AI may then have trouble deciding which one to run.

Serval’s response is another agent, one that sits above the product with awareness of the workflows already built. When an admin asks for a new workflow, that agent can say, in Stauch’s example, that nineteen already do something similar. It can propose modifying an existing one, deleting ten, sorting the rest into categories, and adding approval steps. In that sense, Serval is not only making automation easier to create; it is trying to keep the resulting internal system coherent enough for both humans and agents to operate.

Serval’s use of code generation is part of the architecture, not just a way to make demos feel faster. Stauch says the system generates scripts for automations, and once those automations exist, they can be run again without regenerating the underlying code. A password-reset request does not require the model to write a password-reset workflow every time an employee asks. The system runs the code that has already been generated.

That matters for cost. Stauch says Serval is not currently optimizing heavily around model spend, because the company is focused on making the product work as well as possible and because its unit economics do not look like those of a company “reselling tokens.” The expensive code-generation work is concentrated at creation time. Over time, he expects users to generate less new code because Serval’s library of automations grows to cover more of the long tail of employee-support requests.

This gives the company room, in Stauch’s view, to tell the team to “spend more” and use the best available product. He expects long-term cost curves and later optimizations to help, but his priority is the customer experience.

The exception is background agents. Stauch distinguishes between help desk requests and quick code generation on one hand, and long-running agents that might investigate historical tickets, inspect device logs, or generate solutions to problems the company did not yet know it had. Those workloads could run continuously and “run away pretty quickly” if not watched. In those cases, cost needs to be considered earlier.

Serval currently uses models from both OpenAI and Anthropic, and Stauch says the company tests new models from multiple providers with automated evaluation suites. The model choice is not uniform across the product. For end-user interaction — calling the correct tools and responding appropriately to employees — Serval has had the most success with OpenAI models, and Stauch says that has been consistent for some time. For the automation side, which is largely code generation, Serval has had the most success with Anthropic models, including Sonnet and Opus.

The division is practical rather than ideological: different models perform better for different jobs. But Stauch is explicit that new model releases are not simply “plug and play.” When a new model arrives, some behaviors improve and others regress. Sometimes the model itself is not worse; the surrounding system was tuned around the quirks of the prior model.

Serval has automated evals, but the work of upgrading still requires judgment. Prompts, guardrails, and surrounding infrastructure may need to be changed because assumptions that were helpful for one model make less sense for another. The company tests, adjusts, runs evaluations, and then releases slowly across customers.

Sometimes the right answer is rollback. Stauch says Serval has upgraded models and then downgraded after deciding that the tradeoffs were not worth it. A newer model might be smarter but misbehave in less predictable ways. An older model may be less capable in the abstract, but more reliable for the customers and workflows at hand.

This is why Stauch says application companies should want new models to improve, but “better” does not mean blindly adopting every release. The product has to absorb model progress into a controlled environment where reliability, predictability, and customer trust matter.

Stauch does not describe Serval’s moat primarily as model access. He argues that implementation speed has compressed so much that customer insight has become more important. He is personally in every customer Slack channel, and says most customers receive a message from him there every day.

Stauch acknowledges that this level of customer immersion is sometimes overwhelming. Still, he sees no substitute for it. Product advantages, in his view, are increasingly copyable. The harder advantage is knowing what customers actually need, where the product is failing, what workflows matter, and how the enterprise’s real operating constraints differ from a clean product narrative.

That also informs how he thinks about foundation labs moving downmarket into application categories. Asked what happens if OpenAI or Anthropic decides to build a first-party ServiceNow competitor, Stauch concedes that any answer can sound naïve: these companies have enormous resources, top engineering talent, and increasingly powerful models. But he argues that startups often beat larger organizations because focus matters.

His specific claim is that IT Service Management may not be a rational priority for the labs. He says Anthropic, in the past couple of months, has added more ARR than ServiceNow did in its first twenty years. On that assumption, he questions whether it would make sense for a foundation model company to assign its best people to mastering Enterprise Service Management, a complex category that would take years to produce what other parts of the product portfolio might produce in months. He would not be surprised to see labs build simpler versions, perhaps for mid-market or SMB customers. But he doubts they will devote the focus required to master the enterprise version.

Serval’s customers range from companies with a few hundred employees to companies with a few hundred thousand. Stauch says the surprising lesson is that their pain points are more similar than he expected. The difference is not usually the type of request but the number of people involved in deciding how a process should work.

At a smaller company, an IT leader may simply decide how onboarding, password resets, or access provisioning should happen. At a very large company, no one may know who owns the process, or whether a single owner exists. Implementation becomes a coordination problem across committees and stakeholders. Stauch connects this to the broader trend of AI labs building services and deployment capabilities: in enterprise adoption, coordinating the organization is often the rate-limiting step.

The value customers perceive differs by scale. In AI-native startups, Stauch says Serval gives technical IT people a tool built for them. One example he cites is an IT worker spending the day inside ServiceNow provisioning employees’ access to Cursor. The mismatch bothered him: the IT person was stuck in an old ticketing system so someone else could use a modern AI tool. Serval lets that IT worker use the “cool stuff” directly and spend more time building.

In large enterprises, the value is more about employee experience and business transformation. A ticket can disappear “into the abyss,” leaving an employee blocked for weeks. They file another ticket, which creates duplication and confusion on the support side. Automation changes not only IT efficiency but what it feels like to be an employee inside the organization.

Stauch says he forces the team to route requests through Serval. Ordinary office requests, such as snacks, go through Serval. But his more revealing example is recruiting.

The company has an internal channel called “Dream Team Draft.” Employees post the best people they have worked with, usually by adding a LinkedIn profile. Serval then runs automations: adding the person to outbound and nurture campaigns, and performing other marketing-related steps that Stauch says his marketing team does not want him to describe. The idea is to make Serval familiar to people the company may want to hire long before they are ready to move. The employee’s input is minimal: identify someone great. The talent system handles the rest.

That example reflects a broader operating philosophy. Stauch says Serval questions every department and role. The company begins with the assumption that maybe a person is not needed, or maybe the function can be much smaller because AI can do part of the work. He describes AI as having “the right of first refusal” for every job or department. Sometimes that assumption is wrong and the company relearns why a function exists. But the starting point is that the old organizational chart should not be inherited uncritically.

One concrete example is solutions engineering. Serval does not have solutions engineers, and it also does not have SDRs. Stauch says the SDR point has become less controversial, but the absence of solutions engineers is more notable. Account executives are not necessarily more technical than prior generations of salespeople, but they have access to Serval. If a prospect asks how the product works, Serval can answer. It can also build decks, one-pagers, battle cards, and comparison sheets during the sales process.

Serval does have four deployed engineers who help with pilot implementation. The distinction is that implementation still needs technical support, but pre-sales explanation and enablement can be compressed into tools used by the sales team.

The same pattern appears in other functions. Serval delayed hiring in enablement and RevOps, partly by design and partly because hiring was slow. In some cases, the company discovered it could get further than expected with automated resources. In other cases, it eventually found that it did need a person, just later or in a smaller department than originally assumed.

This approach also shapes the culture Stauch wants. He says Serval is not a good place for people who need extensive training, structured mentorship, clear onboarding programs, or defined career paths. The company hires people expected to be productive on day one, comfortable with ambiguity, and able to determine what needs doing. It is flat enough that Stauch says he does not know who technically reports to him versus to others, and he describes himself as “blissfully unaware” of those lines.

That is not framed as a universal virtue. Stauch says there are great companies that train and mentor well; Serval is not one of them. The company’s appeal, as he describes it, is the team itself: kind, talented, high-energy people, plus the chance to work across IT, HR, legal, finance, and security on complex AI workflows. But the tradeoff is explicit. Candidates looking for structure, coaching, and a predictable progression up an org chart may not fit.

Serval is just two years old, and Stauch says his own role has already changed. In the earliest days, he felt “very useless”: the CTO was building the product, the product needs were obvious, and Stauch was trying to hire, arrange customer calls, and sell something that did not yet work. Over time, the company became a business, and instead of him pushing the boulder uphill, the business began dragging him along.

He remains heavily involved in customers and recruiting. The area where he is less involved than he would like is product direction. In the early days, he was constantly thinking about where the product should go. Now, product improvements often emerge through customers and forward deployed engineers. Stauch calls this “gradient descent for product improvements”: forward deployed engineers are surrounded by customer feedback, fix issues, make changes, and a week later the product is noticeably better.

That loop improves the product quickly, but Stauch worries it leaves too little time for thinking about the future. In AI, he argues, companies must be willing to reinvent themselves and disrupt themselves much faster than before. Serval is prepared to uproot assumptions it held only months ago, rename parts of the product, and change how core pieces work. The old software-company assumption — build something that lasts twenty years — gives way to a more provisional model: build software that may last six months before a paradigm shift forces a rebuild.

This is where Pat Grady frames Serval as a buffer between rapidly advancing foundation models and customers whose organizations change more slowly. Stauch accepts that framing. Serval’s role is to meet customers where they are, understand their business problems, and then absorb the newest AI capabilities on their behalf. Customers should not need to track every model advance. They should be able to state the problem they are trying to solve, while Serval figures out how to implement the solution as the underlying technology changes.

Hiring is the constraint that matters most to Stauch. Despite AI’s promise to automate work, he says every AI company he talks to is hiring heavily, and hiring remains Serval’s number-one priority and concern. His view is that people are the biggest remaining moat. Better people in the room are what keep a company ahead when product advantages can be copied and technology shifts quickly.

Grady connects this to talent density: if capabilities are rising and costs are falling, change accelerates, and organizations need agility. The way to stay agile is to have the smallest possible number of the best possible people. Stauch says Serval’s mantra is “fewer better.” The goal is to make each department smaller and stronger.

That is partly a hiring-quality principle and partly an adaptability principle. Stauch can imagine a future Serval that is unrecognizable from today’s company because it had to adapt so quickly. Such a shift is easier with a small, high-talent team than with thousands of employees who must be persuaded that everything about go-to-market or product direction is changing.

For Stauch, the company’s larger purpose is not simply automating IT work. He wants Serval to close the gap between the job people thought they were taking and the job they actually experience. Every profession has repetitive, menial work that is not why people chose it. Serval’s intended impact is to automate enough of that work that employees can return to the work they signed up for.