No PriorsTaking on ServiceNow: Coding Agents for the Rest of Us with Serval Co-Founder and CEO Jake Stauch
CHAPTERS
- 0:00 – 1:12
Enterprise autonomy vs. security: why “guardrails” matter for agents
Jake frames the core challenge of enterprise agents: the more capable and autonomous they become, the scarier they are to deploy inside companies. He positions Serval as the boundary layer that makes adoption possible through governance, approvals, and auditability.
- •Agents could become competent enough to take actions across many enterprise systems, creating major security risk
- •Enterprises want autonomy without “babysitting,” but autonomy is inherently risky at scale
- •Serval is described as the guardrails and boundary that lets enterprises adopt agents safely
- •The product focus is governance mechanisms that fit enterprise rules, approvals, and politics
- 1:12 – 3:00
Serval’s origin story: discovering ServiceNow pain through IT teams
Jake explains Serval’s category—enterprise automation and service management powered by code generation agents—and how his prior experience selling to IT teams revealed a consistent frustration with ServiceNow. He outlines why users felt stuck with a powerful but slow-to-change platform.
- •Serval is positioned as enterprise automation and service management driven by code generation agents
- •Jake learned the space by working with IT teams and repeatedly hearing complaints about ServiceNow
- •ServiceNow is described as robust and customizable, but difficult and slow to implement changes
- •Heavy reliance on consultants and long implementation cycles create lag behind business needs
- •Rising costs plus slow iteration drive user frustration
- 3:00 – 4:40
“Coding agents for the rest of us”: expanding beyond engineering teams
Elad and Jake discuss how early AI adoption centered on engineers using coding agents, largely because code review makes experimentation safer. Jake describes Serval’s goal: bring that power to IT and then to other departments via enterprise-grade controls.
- •Engineering adopted coding agents early due to established safety processes like code review
- •Serval aims to extend builder capability to IT, and then HR, finance, legal, and more
- •The platform emphasizes approvals, staging, audit trails, and controls around what gets deployed
- •Jake argues most companies have IT departments (not large engineering teams) as the builders of internal systems
- 4:40 – 6:30
Why personal/workforce agents stall in large enterprises: permissions and process
Jake explains why consumer-style assistants can work in SMB settings but struggle in large enterprises: individual permissions are narrow, approvals are required, and many organizations won’t allow agents broad access. Serval’s approach uses IT-controlled connections and a ticketing/approval structure for just-in-time access and deterministic workflows.
- •In large enterprises, approvals and limited permissions constrain what personal agents can do
- •Even when allowed, agents may be unable to read or act across needed systems due to access restrictions
- •Serval connects through IT with elevated permissions (e.g., admin/service accounts) while enforcing strict approval flows
- •Requests can create access approvals, logged with an audit trail, granting just-in-time access for specific workflows
- •Jake contrasts “magical” personal agent experiences with what regulated enterprises require to feel safe
- 6:30 – 7:55
Deploying Serval in big orgs: forward-deployed teams and ongoing automation support
Sarah asks how Serval gets implemented effectively given enterprise complexity and the historic role of consultancies. Jake describes an on-site deployment model with both strategy and engineering support, plus a longer-term services motion to help customers continue automating after initial rollout.
- •Enterprises need help mapping people and process to workflows; technology alone isn’t enough
- •Serval uses deployment strategists and forward-deployed software engineers on-site with customers
- •After launch, customers typically want a long tail of additional automation work
- •Serval builds an ongoing support/services capability (“ProServal” / automation engineering) to help identify and implement automations
- 7:55 – 9:53
Day-one ambition: going straight at enterprise systems of record (not a thin layer)
Jake explains that Serval set out immediately to replace deeply embedded platforms rather than building a small add-on layer or starting down-market. He argues that building for large enterprise from the start changes product, team, and growth decisions.
- •Jake says the team intended from day one to beat ServiceNow and build something larger
- •He contrasts typical approaches: building a layer on top of incumbents or going down-market first
- •Sarah and Jake discuss why “agent on top of X” often caps how big a company can get
- •Jake emphasizes that designing for large enterprises from day one forces different product and organizational choices
- 9:53 – 11:02
Why ServiceNow specifically: code as the best abstraction for enterprise automation
Jake explains the strategic logic: ServiceNow is fundamentally a workflow automation platform, and Serval believes code is the right way to express automation. AI makes that feasible for far more users, potentially outperforming drag-and-drop workflow builders.
- •Jake frames ServiceNow as, at its core, a workflow automation platform
- •Serval’s belief: enterprise automations are best expressed in code rather than drag-and-drop builders
- •He argues drag-and-drop can be too complex for non-technical users and too limiting for technical users
- •AI code generation changes the constraint—more people can effectively build code-driven automations
- 11:02 – 12:21
Betting on coding agents: from early brittleness to “hard to break” workflows
Sarah probes what it looked like to build Serval when models were weaker. Jake describes the early reality—seeded examples and heavy prompting—and how improved models made it increasingly difficult to find workflows the system couldn’t automate when APIs exist.
- •Jake says early on the approach “did not work” reliably in practice
- •Early demos relied on seeding models with examples and growing a library over time
- •Jake’s bet was that coding agents would improve because coding is verifiable and can “hill climb”
- •As models improved, it became difficult to break the system for many procedural, verifiable workflows
- •Jake notes strength in deterministic scripts like approvals and password resets
- 12:21 – 14:31
Guardrails as the product: SDLC, least privilege, and controlled exceptions
Jake explains why better models increase the need for stronger boundaries in enterprises. He predicts permissions will tighten toward least privilege, making a governance layer for exceptions—approvals, audit trails, and SDLC gates—more essential.
- •Jake says Serval isn’t building LLMs; it’s building the boundaries that make enterprise adoption workable
- •He predicts enterprises will shrink user permissions toward least privilege as agent capability increases
- •Serval’s role becomes granting and tracking exceptions through approvals and audit trails
- •Jake highlights SDLC concepts—dev/staging/prod gates and reviews—as crucial for enterprise AI deployments
- •He contrasts enterprise requirements with AI products that ship powerful agents directly to production
- 14:31 – 21:32
Selling transformation: making Serval the “get promoted” migration
Sarah asks why customers would risk replacing an incumbent. Jake argues the story must be career-making, not merely risk-managed, and explains Serval’s top-down enterprise sales motion with an example of recognition earned by a customer champion.
- •Jake says Serval must be positioned as a path to career advancement for customer champions
- •Elad and Jake describe selling top-down into IT leadership and C-level stakeholders
- •Jake compares the dynamic to people who built careers on prior platforms and now bet on a new generation
- •He cites Fox Corporation adopting Serval widely and a migration lead being recognized internally for that work
- 21:32 – 27:27
Measuring ROI and the “SaaS-pocalypse”: consolidation vs. rebuilding systems of record
The conversation shifts to cost controls, proving value, and broader SaaS consolidation narratives. Jake discusses token spend pullbacks, the difficulty of measuring ROI, pricing tied to workflows run, and why building systems of record in-house often remains expensive despite AI—while point-solution sprawl may shrink.
- •Jake observes a pattern: early token “maxing,” then pullback and increased focus on ROI proof
- •He says customers ask for help showing work performed and translating it into business value
- •Serval tries to price based on workflows run, framing it as closer to “work done” than token volume
- •Jake argues building and maintaining enterprise systems of record internally is still costly and complex
- •He expects consolidation to reduce point-solution sprawl, while major systems-of-record categories persist and evolve
- 27:27 – 38:05
Catalyst and the next wave: platform-managing agents, background autonomy, and hiring speed
Jake describes Catalyst, Serval’s agent that helps admins build automations and configure approvals and policies by translating requirements into product primitives. The group then explores background agents as a “moonshot,” discussing incremental permission escalation as a safety path, and closes on Serval’s rapid growth and customer-embedded operating model.
- •Catalyst is presented as an agent interface that helps admins build automations and configure rules, approvals, and policies
- •Sarah and Jake discuss agents as a way to raise users’ technical competence by guiding iteration and explanation
- •Jake calls background agents the “ultimate moonshot,” but emphasizes the safety challenge of autonomy in enterprises
- •His safety approach relies on incremental capability escalation: requesting approvals for deterministic tools and workflows over time
- •Jake shares Serval’s rapid team growth and a customer-embedded approach where engineers stay close to user needs and adapt quickly
