Serval Uses Coding Agents to Bring Enterprise Automation Beyond Engineers

Jake Stauch sees Serval’s opportunity in a mismatch between what enterprise IT teams want to automate and what existing tools make practical. At his previous company, Verkada, he spent years talking with IT departments about what they spent the most money on and what they disliked most. ServiceNow often came up. Its platform could map to complex enterprise workflows, but building those workflows was difficult enough that companies often needed consultants. By the time an idea was implemented, Stauch said, the business might have moved on. The platform was expensive, too, and became more so over time.

The premise behind Serval is that code is a better way to express automation than drag-and-drop workflow builders—but, until recently, most people could not write code quickly enough to make that practical. Stauch and his co-founder believed coding agents could change that. Serval uses them to let IT teams build internal tools and workflows, then extend that capacity to departments such as HR, finance, legal and people operations.

Stauch calls the idea “coding agents for the rest of us.” Software engineers can experiment with powerful coding tools partly because their work passes through code review before it reaches production. Serval aims to give non-engineering teams a comparable path: people can build with an agent, while the platform provides staging, approvals and an audit trail. The idea is not simply that anyone can generate code. It is that more employees can build useful automations without losing the controls an enterprise needs.

That puts IT in a central role. In many companies, Stauch said, IT is the group configuring and building technology for the business, even when there is no software engineering department. Serval is designed as an AI platform for those teams—not just a personal assistant attached to an individual employee’s account.

Customers also need a reason to take the career risk of replacing an established system. Serval’s pitch, Stauch said, is that adopting the platform can become a way to demonstrate value and advance at work. He cited Fox Corporation, one of Serval’s largest customers: Fox adopted Serval company-wide, and the employee who led the migration on the ground was nominated as the company’s MVP and received an award. For Stauch, that kind of recognition is part of the argument to customers: leading a transition can make someone essential to the company’s AI work, rather than simply exposing them to the risk of a new tool.

The distinction between a personal agent and an enterprise system is not only what the agent can do. It is what it is allowed to touch. In a large organization, an individual employee’s permissions are often too narrow for a personal agent to do much useful work across company systems. Serval can connect through service accounts and administrator-level credentials, but that capability needs a controlled route to action.

When an employee asks an agent to perform a task, Serval can create an access request, send it through an approval process and provide time-limited access to run a defined workflow. The action is logged and associated with a ticket. A ticketing screen shown during the discussion listed associated IT requests, including onboarding, offboarding, device-password resets and a Tailscale request. Stauch acknowledged that this approach is less frictionless than a personal agent acting on its user’s behalf. For large and regulated organizations, that friction is part of what makes adoption possible.

The balance will get harder as agents improve. Stauch expects more capable systems to make companies more cautious about permissions, not less. If an employee—or an agent acting through that employee—can use elevated access in unexpected ways, the potential damage grows. Enterprises may respond by moving closer to least privilege: employees can read or change only what they need for their jobs. Serval’s role, in his view, is to manage the exceptions: who gets additional access, for what purpose, with what approval and what record of the action.

Stauch’s bet is that better models strengthen the value of that boundary. Serval does not build the underlying language models; it builds the controls that let enterprises use them. As agents become more capable, he expects customers to want to govern their access more closely.

That vision also shapes how he thinks about background agents: systems that receive a broad task, work independently and return with a result. Stauch called them “the ultimate moonshot in enterprise software,” because they promise to find and solve problems without someone supervising each step. But the autonomy that makes them attractive is also what makes them risky. An agent given a high-level objective might take an unexpected route to achieve it; in the enterprise, it could potentially write code that acts across company systems.

He sees consumer agents as a signal of what may come to work, though not as a model enterprises can simply adopt unchanged. Stauch expects personal agents to become part of workplace communication and task delegation: one person’s agent could handle tasks and interact with other agents. He also expects separate personal and work agents, much as people use separate personal and corporate email. At work, the appeal of agents will run up against governance and cybersecurity concerns over what they can access and do.

Serval’s proposed path to greater autonomy is incremental. An agent asks to use a particular tool or run a defined script; a person approves it under specific permissions and guardrails. Over time, the agent can accumulate a useful toolkit. It is not the unsupervised autonomy Stauch ultimately wants, and he described the process as annoying. But he does not think companies will soon accept agents with unrestricted ability to write and execute code across their systems.

He sees both model capability and product design as unfinished. Agents need better memory and enough context to understand preferences and prior conversations. Even then, permissions remain the fundamental question: how much can an organization trust an agent to act without supervision?

Stauch said Serval began with the ambition to become the largest enterprise software company of all time. He and his co-founder circled ServiceNow as the company they intended to beat when Serval was just two people working from his co-founder’s living room. Rather than enter as a small layer on top of an incumbent or start with smaller businesses, they chose to take on the large enterprise market directly.

The choice followed from seeing ServiceNow as a workflow automation platform. Stauch and his co-founder believed code was a better way to express enterprise automation than drag-and-drop workflow builders, which he described as too complex for nontechnical users and overly abstract for technical ones. The obstacle was that few people could write code quickly enough for it to be practical as an everyday automation tool. Coding agents, in their view, could remove that constraint.

The original bet was that agents would become effective in a domain where tasks are procedural and outcomes can be checked—for example, resetting a password or obtaining an approval. Early systems needed examples and suggested workflows to get started. As the models improved, Stauch said, it became harder to give the agent a workflow it could not automate when the necessary APIs were available.

A chart shown during the discussion compared models on SWE-bench, a benchmark for real-world software engineering performance. It displayed Devin at 13.86%, ahead of Claude 2 at 4.80%, SWE-Llama 13B at 3.97%, SWE-Llama 7B at 3.01%, GPT-4 at 1.74% and ChatGPT 3.5 at 0.52%. The chart offered one on-screen illustration of the coding-agent progress behind Stauch’s bet; his stated case for Serval rests specifically on agents handling defined, verifiable enterprise workflows.

Serval’s enterprise approach depends on software development practices that Stauch said many AI products do not yet accommodate. In an engineering organization, a change can move through development, staging and production, with review and testing between environments. Large enterprises need similar gates for agents and automations. A financial institution, he argued, will not simply put new agent capabilities into production without review and user-acceptance testing.

That requirement changes what a company has to build. Some AI companies may choose not to take on the extra work of serving enterprises. Supporting their needs means building for compliance, process, permissions and governance—not merely making an agent that performs well in a demo. Serval chose to take on those constraints from the beginning, with the ambition of competing directly with established systems of record.

The platform is intended for users with different levels of technical comfort. Stauch argued that IT teams, especially in large enterprises, are often more technically capable than software products assume: they manage systems and may write code themselves. Serval gives them access to the code and the option to use a full development lifecycle, without requiring every user to understand the code being generated. Someone in marketing or HR may want to build a complex workflow without seeing code at all.

Sarah Guo described this kind of agent as a way to raise users’ technical competence as they work. Stauch agreed: an agent can help someone find a starting point, explain unfamiliar concepts, fetch information and explore what is possible. It becomes a build partner, not merely a prompt box.

Serval built Catalyst to help customers work with the platform itself. The agent helps administrators translate requirements into automations, configure approvals and permission checks, set policies and manage a deployment. Stauch said the product grew out of a problem with the first generation of complex AI tools: customers had to learn the product’s many primitives before they could use it. Serval initially relied on deployed engineers to explain the system or build for customers. Catalyst offers another route: customers can describe what they need to an agent that understands how to operate the platform.

Stauch does not expect the software alone to close the gap between what an enterprise could automate and what it actually deploys. Companies still need help identifying their workflows, understanding how those processes should change and navigating the systems involved. Serval sends deployment strategists and deployed software engineers to work with customers on implementation: they learn how the organization works, help decide what to build and guide the implementation through to deployment.

The demand does not necessarily end at deployment. Customers often have a long list of additional automations they want to build, along with a need for help deciding what can be automated and how to put it into production. Serval has developed ProServal, a team of automation engineers that provides ongoing support and services. The team helps customers continue identifying opportunities and implementing workflows after the initial platform deployment, rather than treating implementation as a one-time handoff.

This work does not mean building bespoke product features for each customer. The platform is code-generation-based, so a password-reset workflow or onboarding process can differ substantially between organizations while still being built from shared platform capabilities. When customers repeatedly create similar automations, Serval can consider whether those should become standard features. Stauch gave two examples: workflows to identify outdated or conflicting knowledge-base articles, and automations to reclaim unused software licenses.

In the license example, customers were building workflows to find software subscriptions that were being paid for but no longer used, then cancel them. Serval decided that this recurring need belonged in the platform. Repeated customer requests can therefore indicate that a capability should become a first-class product feature; differences in a company’s own processes can remain in automations built on the platform.

Stauch is skeptical that companies will broadly replace their core enterprise systems by building them in-house with AI. Companies that try to recreate systems of record, he said, discover that enterprise software remains expensive to build and maintain. Edge cases need attention, systems break, users expect updates, and the company must staff a team to keep the software working. For systems outside a company’s core competency, buying an established product can still make more economic sense.

He expects more change among smaller point solutions. Many companies have accumulated hundreds of SaaS applications, Stauch said, when they may need only a few dozen. Some of those tools could be absorbed by core systems of record and larger platforms. Elad Gil added that middleware may also be vulnerable. Stauch agreed that consolidation is likely, but distinguished it from the disappearance of categories such as ERP, HRIS, IT service management and CRM. Those systems may be transformed or displaced by a new generation of providers; he does not expect the underlying needs to go away.

He made a related distinction about AI spending. Customers that initially pushed hard to use code-generation tools may pull back to assess costs and productivity, but Stauch expects aggregate spending to keep rising as more companies begin adoption. What customers want is stronger evidence of return on investment. Measuring the value of tokens is difficult, and he thinks the industry will need better ways to connect AI usage to work completed, labor avoided or other costs.

Serval tries to price around workflows run, which Stauch sees as a better measure of work than token consumption alone. Tokens show how much a model generated, but can also reflect verbosity or inefficiency. Pricing by completed workflows is intended to connect the bill more directly to activity customers can assess as work done. Customers still need help proving that the spend was worthwhile; establishing that link between usage, completed work and economic value remains an industry challenge.

Serval’s ambition is large enough, in Stauch’s view, that the company is not constrained by a narrow definition of its market. It aims to automate work across departments and employees. That breadth creates its own challenge: choosing what to focus on when many areas are open to development.

The company’s response is to keep engineers close to customers. Stauch said engineers participate in customer Slack channels and calls, often speaking with customers daily. Serval has decentralized product development so that engineers can make decisions based on what they are hearing, rather than routing every choice through a separate product function.

That approach calls for engineers who understand the product and its users, and who can make judgment calls at the edge of the organization. It also means accepting that the product may change faster than customers—or even Stauch—can keep up with. Teams have to be willing to reverse course and discard work they previously considered fundamental when customer needs shift. Stauch said Serval has repeatedly removed or changed things it had been committed to as the market and customers changed.

The company’s growth has been rapid alongside that operating model. Stauch said Serval had 200 employees at the time of the interview, up from 20 in January. He expected hiring velocity to increase further. His argument is that greater individual productivity has not reduced the company’s appetite for people: it has increased what the team believes it can attempt. That model depends on ambition, but also on staying close enough to customers to notice when the work itself has changed.