Serval’s Challenge to ServiceNow: What Enterprises Need After Code Generation

1. Guest Background

Jake Stauch, co-founder and CEO of Serval, joins Sarah Guo and Elad Gil on No Priors to discuss bringing coding agents to the people who configure and operate enterprise technology. Serval works in enterprise automation and enterprise service management, competing with providers such as ServiceNow. Its proposed route runs through IT departments, which can then extend automation capabilities to HR, finance, legal, and other business teams.

Stauch’s relevant experience predates Serval. He describes working at Verkada, selling enterprise physical security products to IT teams and spending years learning what those customers needed. Two questions helped him identify the opportunity: which tools consumed the most money, and which tools customers disliked most. ServiceNow frequently appeared in those conversations, he says.

That background gives the interview a particular perspective. Stauch approaches code generation through the responsibilities of IT buyers and operators, rather than solely through the experience of software developers. He is also explaining the strategy of a company challenging an incumbent. His observations about customer frustration, product progress, and adoption requirements should therefore remain attributed to him; the interview is an informed operating account, not an independent assessment of the market.

2. What the Episode Covers

The problem Stauch identifies is the distance between an automation idea and a working implementation. He credits ServiceNow with being powerful, customizable, and capable of supporting complicated enterprise workflows. His complaint is that customers still have to implement each idea, often with consultants. He describes the platform as running six to twelve months behind where customers want it to be. That range is his characterization, not an independently established industry benchmark. An expensive implementation may be reasonable for an onboarding process expected to remain stable for years; it becomes harder to justify when requirements keep changing.

Serval’s response combines a technical bet with a market choice. Stauch says the company intended from the beginning to compete directly for large enterprises. Serving that market immediately, he argues, leads to different decisions about the product, the team, and growth than starting with smaller customers and hoping to expand later.

The technical bet is that code is the right underlying representation for automation. Stauch and his co-founder see drag-and-drop builders as an awkward abstraction: still complicated for nontechnical users, yet restrictive for technical ones. Code generation changes the cost of using a more expressive foundation. The early product did not enjoy today’s capabilities, however. Stauch recalls supplying extensive examples in prompts to make demonstrations work. The team expected clearly defined, verifiable procedures—such as resetting a password or obtaining approval—to improve as coding models advanced. Eventually, he says, it became difficult to propose a workflow the system could not automate when the necessary APIs existed.

The intended users span IT engineers who want to inspect code and business employees who do not want to see it. Serval retains access to the underlying implementation while providing higher-level ways to build. That flexibility does not remove the work of understanding a customer. Deployment strategists and software engineers go on site to investigate processes and implement the platform; a continuing automation engineering service, ProServal, addresses subsequent demand.

Catalyst, the company’s administrator-facing agent, addresses another source of friction: understanding the platform itself. It translates requirements into automations, approval rules, permission checks, and policies. Taken together, these choices make the episode a discussion of an operating system for enterprise automation in the organizational sense: how people specify work, deploy it, and remain responsible for what it does.

3. Core Views: Reasoning, Examples, and Limits

The interview’s strongest distinction is between an agent’s ability to produce an implementation and its authority to act. Stauch argues that a personal agent in a large enterprise inherits the limitations of its user’s permissions. Better reasoning alone cannot give that agent legitimate access to every system needed for a cross-functional task. Serval’s answer is to work with IT-controlled service accounts and elevated permissions, then govern their use through deterministic approval workflows and an audit trail. Ticketing becomes part of the execution infrastructure because an action needs an associated request, decision, and record.

His concrete example is deliberately narrow. An agent’s request creates an access request; after approval and logging, the user receives just-in-time access to run a particular deterministic workflow once. The approved object is a bounded action, rather than an open-ended delegation. Stauch acknowledges the cost: this is more cumbersome than the seemingly effortless personal-agent experience. The interview makes a case for that friction in large enterprises, but does not establish that every task needs the same approval burden. How much review is appropriate remains a design question tied to the action and its consequences.

This is the reasoning behind his claim that boundaries are Serval’s product. The company is not building the underlying language models, he says. It is building the conditions under which enterprises can use them. He further predicts that stronger agents will encourage companies to narrow employees’ standing permissions. Access that previously seemed tolerable could enable more consequential activity when an agent can exercise it quickly and broadly. Narrower permissions would then create more demand for approved exceptions, making the privilege-escalation layer more important. This is a coherent strategic thesis, but the interview supplies no measurement of how quickly permissions are tightening or how much exception traffic will grow.

Software development discipline supplies a second boundary. Stauch emphasizes development, staging, and production environments, with review and user acceptance testing between creation and release. The significance is organizational: a person can become a more capable builder without acquiring unilateral authority to deploy. His preference for code over visual workflow builders concerns expressive power. His account of moving from example-heavy prompts to more capable models concerns construction cost. Neither observation establishes that a generated workflow has already satisfied an enterprise’s operational requirements, and his API condition also limits the reach of the automation claim.

Background agents expose the remaining gap. Stauch would like to give an agent a broad mission and trust it to discover and solve problems, but says enterprises have not figured out how to do this safely. His proposed approach expands capabilities incrementally. An agent asks to call a tool or run a script; a human approves it under defined permissions; over time, the approved toolkit becomes more useful. This offers a path toward greater autonomy, while retaining supervision that he admits is inconvenient. It is a proposal for managing the transition, not evidence that autonomous enterprise operation has been solved. Better memory, larger context, and a stronger understanding of individual preferences are also needed, he says. Even successful improvements there would leave the authorization question intact.

Economic proof remains similarly unfinished. Stauch says customers want help demonstrating return on investment. Serval tries to charge for workflows run, which he considers closer to work performed than token consumption. That is a useful distinction between an input and an activity measure, but an activity measure is not automatically a value measure. As an analytical implication, repeated or unsuccessful runs would need different treatment from useful completed work. Stauch himself acknowledges that measuring the benefit obtained from token spending remains unresolved.

His view of software markets preserves the maintenance problem as well. Based on companies he has spoken with, rebuilding core systems internally still requires people to handle changing use cases, edge cases, and failures; unusually bespoke requirements may justify a different decision. He predicts consolidation among point solutions and some middleware, while ERP, HRIS, ITSM, and CRM categories survive with potentially different vendors. The distinction is between generating functionality and assuming continuing responsibility for a system. The market outcome remains his forecast.

4. Learning and Application

A practical use of this interview is to design construction, release, and execution as separate decisions. The following methods are applications of its arguments, rather than customer outcomes reported in the episode. For an initial password-reset or onboarding workflow, a team could specify the trigger, connected systems, approving authority, and permitted actions before asking an agent to implement it. Review and acceptance testing would establish readiness for production. A sensitive execution could then use the episode’s narrower model: authorization for a defined workflow run. This adds coordination, but keeps a successful generation from becoming an implicit deployment or access approval.

Implementation planning should also include process discovery. Serval’s combination of on-site staff and continuing ProServal support suggests that customers need help deciding what to automate and how their systems fit together. A useful pilot would document the current process, the desired process, exceptions, and the person responsible after launch. Where stakeholders have not agreed on the rules, faster code generation cannot settle the disagreement. Business owners still need to choose the process the software should implement.

For platform teams, Stauch’s distinction between shared capabilities and customer-specific workflows offers a product-development method. He says Serval does not build bespoke product capabilities for individual customers, although their password-reset, onboarding, and offboarding workflows differ substantially. Repeated requests can then reveal candidates for native features. His examples are detecting conflicting or outdated knowledge articles and reclaiming unused software licenses. Applying this method requires checking whether customers share an underlying mechanism or merely use the same label. A native feature is most useful when it removes repeated work without burying different policies under proliferating exceptions.

Catalyst also suggests a way to combine adoption with education. An administrator can ask why an approval rule is needed, request an explanation of a permission check, and revise a proposed workflow through conversation. Stauch describes this ability to ask for starting points and explanations as part of the value of a building partner. A practical learning goal would be that the user can explain the resulting configuration and identify who handles exceptions. Conversational fluency alone cannot establish whether a policy is appropriate for the organization.

Purchasing decisions need a broader scorecard than generation speed. Workflow counts can show activity, while task completion, human intervention, review effort, and ongoing maintenance costs help evaluate usefulness. Those are suggested evaluation dimensions derived from the discussion, not metrics Serval disclosed in the interview. For a core system, a build-versus-buy comparison should include the continuing team and edge-case burden Stauch describes. Highly distinctive requirements may support internal development; routine requirements still deserve a comparison of lifecycle costs. A quick first implementation does not answer that economic question.

There is an organizational lesson in the feedback loop as well. Stauch says engineers participate directly in customer channels and meetings, with product decisions distributed to engineering and no separate product function. The transferable practice is giving decision-makers close exposure to actual users. Replicating the organization chart is a separate choice. He acknowledges that changes can outpace even leadership’s understanding, which makes the ability to revise or reverse decisions essential. Local authority needs a practical route for correction.

Finally, his hiring account should remain a company-specific example. Stauch reports growing from twenty employees in January to two hundred at the time of the interview and wanting to accelerate hiring despite higher individual productivity. He explains this through expanding demand, competition, and ambition. That does not establish a general employment effect of AI. Other organizations should decide whether released capacity supports more services, higher quality, or lower expenditure by examining their own demand and continuing responsibilities.

Source

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