Serval's Stauch Splits AI Models to Automate Enterprise Workflows

Serval 的 Stauch：通过模型分工实现企业工作流自动化 在瞬息万变的 AI 格局中，依托高密度精简团队与自适应架构打造企业自动化软件，相比依赖固定的产品功能拥有更深厚的护城河。 Serval 通过将自然语言转化为基于核心数据库原语的可执行 TypeScript 工作流，化解企业 IT 面临的行政流程拖累。为构筑严格的安全防线，该平台将职责分工为负责构建工作流的 Admin Agent 与负责终端用户执行的 Help Desk Agent。通过采用 OpenAI 负责对话式工具调用、Anthropic 负责代码生成，Serval 既优化了单体经济效益，又淘汰了 SDR 与 SE 等传统销售岗位，转而起用前线部署工程师（FDE）。最终，该公司秉持“少而精”的招聘理念，以维持足够的敏捷性，随着底层模型的演进而每六个月对产品进行一次架构重构。 Serval 致力于打造 AI 原生企业服务管理（ESM）平台，旨在通过实时 AI 自动化消除传统工单流转中的繁杂行政负担，填补员工职业预期与实际工作琐事之间的鸿沟。 (0:00) 针对低门槛开发带来的冗余流程风险，Serval 设计了监管智能体审查工作流目录，并采用双智能体架构：Admin Agent 通过自然语言生成代码构建工具，Help Desk Agent 则严格在获批权限内执行任务。 (5:00) 在底层技术上，Serval 将任务分流：OpenAI 模型驱动前端服务对话，Anthropic 模型（Sonnet/Opus）负责后端代码生成；同时工作流会直接编译为 TypeScript，大幅降低 Token 消耗并保障单元经济效益。 (10:00) 面对底层大模型厂商的潜在下沉竞争，Serval 认为 ESM 的高领域复杂度使巨头难以深度聚焦；公司内部取消了 SDR 和解决方案工程师岗位，转而由 AI 和现场部署工程师（FDE）直接驱动客户交付与产品迭代。 (15:00) 在软件架构可能每六个月就需要推倒重来的 AI 时代，Serval 坚守“少而精”（fewer, better）的高人才密度招聘法则，将其视作维持极度敏捷与长期竞争壁垒的核心策略。 (35:00)

Serval founder Jake Stauch argues that enterprise service management must be rebuilt using AI-driven code generation to eliminate administrative ticketing friction, positioning robust security boundaries—rather than foundation models themselves—as the core moat for application software. Modernizing Workflow Primitives and Preventing Automation Sprawl (0:00) When ServiceNow emerged around 2007–2008, it advanced legacy platforms like Peregrine and Remedy by defining enterprise software as workflows structured on top of databases. Stauch observes that while this core abstraction remains correct, traditional implementations take weeks or months to code and maintain, leaving IT automations lagging behind evolving business operations. Serval retains the workflow-over-database model but uses natural language prompts to automatically generate workflow logic and keep databases synchronized, adhering to the principle that creating an automation must be easier than performing the manual task. However, lowering creation barriers introduces what Stauch calls "slop automation"—the rapid proliferation of redundant or conflicting workflows, such as dozens of slightly different password-reset processes created across teams. To prevent system bloat and model confusion, Serval introduces a supervisory agent that monitors the organization's full workflow catalog, recommending updates to existing automations, suggesting consolidation, or inserting approval steps before new workflows are created. Two-Agent Architecture and Compiled Unit Economics (10:00) To counter skepticism that application startups are merely thin model wrappers, Stauch frames Serval's value around enterprise security guardrails, auditing, and permissions. The platform relies on a two-agent architecture: an Admin Agent that collaborates with IT teams to generate tools and permissions through natural language code generation, and a Help Desk Agent that interacts with employees. The Help Desk Agent is strictly limited to running tools that administrators have explicitly approved and published. Serval divides model usage between vendors, employing OpenAI models for conversational context and tool calling on the help desk, while using Anthropic models (such as Sonnet and Opus) for backend code generation. Stauch notes that foundation model upgrades frequently disrupt custom prompt tuning, occasionally prompting Serval to downgrade to earlier, more predictable models to preserve system stability. To protect unit economics and avoid pure token reselling, Serval compiles workflows into standard TypeScript, executing static code on subsequent user requests rather than generating new tokens for every transaction. Navigating Shadow AI and Enterprise Security Controls (30:00) Stauch identifies an emerging operational tension between employees demanding friction-free autonomous AI agents and enterprise IT departments requiring stringent data security. Drawing a parallel to the enterprise transition from locked-down BlackBerrys to consumer-introduced iPhones, Stauch and Sequoia partner Pat Grady contend that IT organizations embracing employee adoption signals will ultimately prevail, though Stauch notes that "yes-first" enterprises must be prepared to manage early security incidents. Serval positions itself as an enterprise translation layer designed to insulate clients from the constant churn of foundation model releases. Supported by Forward Deployed Engineers (FDEs) who run customer pilots and feed real-time fixes back into the core codebase, Serval continuously modifies its backend methods so non-technical enterprise buyers can address operational problems without needing to track underlying machine learning developments. The AI-Native Operating Model and Rapid Rebuilds (25:00) Internally, Serval operates by giving AI "right of first refusal" before expanding headcount, functioning without traditional Sales Development Representatives (SDRs) or Solutions Engineers (SEs). Account Executives rely on Serval live during sales calls to generate comparison decks, battle cards, and product answers, while Forward Deployed Engineers handle client implementations directly. Stauch complements this operational structure with a "fewer, better" hiring policy that rejects structured onboarding, formal career ladders, and mentorship programs in favor of autonomous self-starters. Because rapid model capability improvements can make technical architectures obsolete, Stauch argues that AI-era software must be built with the expectation of being substantially rewritten every six months, making high talent density and organizational adaptability essential for enduring competition against both incumbents and hyperscalers. Stauch concludes that software leadership must abandon expectations of twenty-year static platform lifespans in favor of high-velocity adaptability that removes menial administrative friction. However, Serval's long-term enterprise penetration remains dependent on overcoming multi-layered enterprise procurement committees and balancing autonomous employee tooling against corporate security vulnerabilities.

Serval 联合创始人兼首席执行官 Jake Stauch 认为，传统企业服务管理因人工维护工作流的高昂成本而已无法适应当下节奏；通过在严格的企业安全与审计边界内将自然语言即时编译为可执行代码，AI 能够消除员工日常支持中的摩擦并重构现代企业软件范式。 重构传统ITSM：从静态工作流到即时代码生成 (0:00) Stauch 回顾指出，ServiceNow 在 2007 至 2008 年间将 Peregrine 和 Remedy 等旧系统抽象为“基于数据库的工作流”，奠定了现代企业服务管理（ESM）的基础。然而，传统工作流开发往往耗时数周甚至数月，导致系统自动化进度严重滞后于快速变化的业务实际。在现实场景中，若构建自动化流程本身的耗时超过了直接手动处理任务（例如重置 Google Workspace 密码），自动化投资便失去意义，员工只能被迫依赖人工提交工单并陷入漫长等待。 Serval 保留了“工作流覆盖数据库”的核心抽象，但引入了代码生成引擎来消除开发瓶颈。管理员仅需使用自然语言描述操作步骤、分支逻辑、审批流与权限设置，系统便能即时将其转化为可执行程序；底层数据库维护同样被自动化接管，系统依据用户指令自动从数据源拉取并更新记录，从而实现员工端支持请求的秒级即时响应。 双智能体安全架构与TypeScript编译的经济性 (10:00) 针对应用层初创公司沦为大模型“薄封装层（wrapper）”的行业质疑，Stauch 指出，大型企业由于审计、合规和访问控制限制，不可能无边界地直接接入基础模型。Serval 的核心产品实质上是让模型在企业环境内安全运转的控制框架。为此，系统采用了双智能体架构：面向管理员的“管理智能体（Admin Agent）”负责将自然语言转化为技能与权限配置，而面向终端员工的“服务台智能体（Help Desk Agent）”仅能严格执行已被管理员审批发布的工具，杜绝不受约束的模型自主权。 在技术与经济模型设计上，Serval 采用 OpenAI 模型支持终端服务台的多轮对话与工具调用，而采用 Anthropic 模型（包括 Sonnet 和 Opus）承担底层代码生成。与高频消耗模型 Token 的转售模式不同，Serval 构建的自动化流程会被编译为标准 TypeScript 代码。后续的用户请求将直接执行已编译代码而非反复调用大模型生成逻辑，这在显著降低持续推理成本的同时，保证了 enterprise 级运行的确定性与健康的单位经济效益。 治理垃圾自动化与跨越底层模型升级陷阱 (5:00) 创建门槛的大幅降低带来了“垃圾自动化（slop automation）”的结构性风险，即不同员工可能因操作简便而在单周内生成数十个功能重复但略有差异的工作流，造成系统冗余并干扰 AI 的调用判断。为解决该问题，Serval 部署了具备全局组织上下文的监督智能体。当管理员尝试建立新规则时，监督智能体会自动比对现有资产目录，提出合并工作流、调整既有规则或设置特定审批节点的架构优化建议。 在底层技术迭代方面，Stauch 明确表示追逐最新模型并非始终有益。由于既有的 Prompt 调优和基础设施高度依赖特定模型的行为特征，直接升级新模型常会引发功能退化或逻辑破坏；在实践中，Serval 宁可回滚至较旧但输出更稳定受控的版本。面对来自底层模型实验室自研同类产品的竞争顾虑，Stauch 强调，尽管 Anthropic 近期新增的 ARR 在数月内便超过了 ServiceNow 二十年累积的体量，但超大规模厂商的核心战略在于基础模型与算力设施，难以将顶尖工程资源分配给业务极度复杂垂直的企业服务管理（ITSM）场景。 AI原生组织模式：前线工程师与半年软件周期 (25:00) 在企业内部运营层面，Serval 奉行 AI 拥有“第一拒绝权”的组织范式，在配置人力之前优先由 AI 承担职能。公司完全取消了传统的销售拓展代表（SDR）与解决方案工程师（SE），客户主管（AE）在与客户沟通时直接借助 Serval 即时生成竞对对比与定制演示方案。针对客户部署环节，公司派遣前线部署工程师（FDE）深入现场，将客户的具体痛点高频转化为产品底层的代码修复。Stauch 将这种高密度实地反馈循环定义为驱动产品演进的“梯度下降”。 为了支撑这种快节奏运作，Serval 坚持“少而精（fewer, better）”的人才密度，不提供传统的导师培训或梯队晋升机制，要求新员工在模糊环境中具备首日交付能力。Stauch 预测，随着底层基础模型能力每隔数月发生一次代际跃迁，企业软件行业必须摒弃打造“维持二十年寿命架构”的传统执念，转而适应核心软件架构可能每六个月就必须全盘推翻并重写的新现实。 自主权与安全的博弈：企业影子AI的落地平衡 (30:00) Stauch 与红杉资本投资人 Pat Grady 探讨了当前企业 AI 落地面临的核心矛盾：一线员工希望赋予个人智能体（如 Claude）完全无阻碍的访问权限以释放生产力，而企业 IT 和安全部门则出于合规与风险顾虑力图施加严格管制。Grady 将这一冲突比作当年员工私自将 iPhone 带入黑莓主导的企业环境所引发的“影子 IT”浪潮，认为顺应员工真实生产力诉求的首席信息安全官（CISO）才能站在历史的正确一边。 Serval 的角色定位即是作为企业与底层大模型之间的“翻译缓冲层”，使非技术企业客户无需追踪每一次模型变化即可解决实际业务问题。Stauch 坦言，在实践中采取“默认放行（yes-first）”策略拥抱智能体自主权的企业将获得显著的竞争优势，但这一路线同时也意味着管理层必须有心理准备去接纳和处理早期不可避免的安全故障与试错成本。 Jake Stauch 将 Serval 的长远愿景定义为消除职场人在琐碎管理流程上的精力耗损，使其重回工作本身的创造性价值；然而，在底层基础模型高频跃迁的背景下，初创企业如何在软件架构面临“每六个月全盘重写”的客观现实中平衡系统可靠性与企业安全底线，依然是 AI 原生软件必须持续应对的根本挑战。

## Background 本期内容由红杉资本（Sequoia Capital）于 2026 年 5 月 19 日在其官方播客及网络平台上发布，由红杉合伙人 Pat Grady 主持。节目聚焦企业服务初创公司 Serval 的创始人兼 CEO Jake Stauch，深入探讨其如何通过“外表朴素但具备无限智能”的反共识理念、双 Agent 架构与代码生成引擎，打造面向 AI 时代的下一代 ServiceNow。 ## TL;DR 对话围绕 Serval 颠覆传统企业服务管理（ESM/ITSM）的创新实践展开。Jake Stauch 详细拆解了 Serval 如何用自然语言代码生成替代传统低效的手动工作流搭建，并通过解耦“负责配置代码生成的管理员 Agent”与“在安全边界内行动的服务台 Agent”，在保障企业级确定性安全的同时释放大模型推理潜力。团队在工程上差异化调用 OpenAI 与 Anthropic 模型，在商业上依靠深度的客户共情和“精简卓越（Fewer, Better）”的人才密度构筑防线。其终极使命是消除日常工作中的琐碎杂务，让员工真正回归有意义的核心业务。 ## Atmosphere & style 整场对话深入务实、专业且极富极客气质，在投资人与创始人的高质量碰撞中既有对底层系统架构的硬核拆解，也有关于商业本质的第一性原理推演。Jake 的分享诚恳接地气，既毫不避讳模型换代回滚、管理焦虑等真实挫折，又充满黑色幽默（如 IT 工程师在老旧系统里给别人开通 Cursor 权限的荒诞场景）。访谈氛围在高能量的战术复盘与对技术解放人性的宏大憧憬之间自如切换，兼具理性穿透力与感染力。 ## Bulletin - `00:00` Serval 创始人 Jake Stauch 认为企业软件的本质是“在数据库之上建立工作流”，而 Serval 通过代码生成（Code Gen）将工作流的搭建成本压缩至近乎为零，彻底打破传统平台依赖人工维护的瓶颈。 - `10:00` Serval 采用双 Agent 解耦架构：管理员 Agent 用自然语言生成带安全与权限限制的 TypeScript 代码，服务台 Agent 则完全受限于这些确定性护栏，避免 AI 在生产环境中发生不可控行为。 - `11:12` 在模型选型上，Serval 采用 OpenAI 处理用户交互与 Tool Calling，Anthropic（Claude 系列）负责核心代码生成；面对新模型发布时若 Prompt 失效或行为飘移，团队宁可降级回滚至稳定旧模型。 - `24:49` 公司内部践行极端的 AI 原生组织原则，彻底取消 SDR 和 SE（解决方案工程师）岗位，全员推行“精简、卓越（Fewer, Better）”招聘理念，以极高的人才密度应对每六个月可能发生一次的产品全面推倒重构。 ## Key takeaways - `00:00` ESM（企业服务管理）的终极愿景是员工即时提需并自动解决；传统 ServiceNow 模式的核心瓶颈在于工作流与资产数据库的搭建、维护需耗费大量人力与漫长周期。 - `03:30` 企业推行自动化的关键阻力在于“构建成本”：自动化生成的门槛必须低于手动处理本身，否则人员本能会选择直接手动操作。 - `03:30` 为了避免 Vibe Coding 带来的“垃圾自动化（Slop Automation）”，Serval 引入全局上下文感知 Agent，负责主动拦截冗余流程并提供架构级的精简重构建议。 - `06:30` 在模型能力极易被复制的时代，初创企业的真正护城河是对业务细节的深度共情与第一手客户洞察，而非单纯的技术功能壁垒。 - `08:30` 企业级 AI 产品的核心价值不在于提供无限的通用智力，而在于提供严格的边界与安全轨道（Guardrails），让大型企业敢于在生产环境中上线 AI。 - `10:00` 双 Agent 架构将管理员侧（意图理解与脚本生成）与用户侧（受控执行）物理切分，使前台能充分享受前沿模型的推理能力，同时确保后台系统运行具备确定性。 - `13:25` Serval 不做“转售 Token”的生意，其自动化以沙箱运行固化的 TypeScript 代码为主，随着脚本库沉淀，高频请求无需重新调用昂贵的生成模型，从而保证了健康的单客经济模型。 - `15:22` 基础模型实验室不太可能下场吞噬 ITSM 领域：顶尖实验室的 ARR 增速极其惊人，调派顶尖 AGI 人才陷入充斥着定制化集成与繁琐合规的企业服务泥潭属于商业战略上的资源错配。 - `17:18` 大型企业落地 AI 的最大阻碍不是技术问题，而是冗长、模糊的组织决策链条与多部门审批摩擦；自动化首要解决的是工单落入“无底深渊”的结构性内耗。 - `21:07` Serval 内部践行深度 Dogfooding，开发出“梦之队选秀”等高度自动化的招聘流程，利用系统精准且长线地渗透顶尖人才心智。 - `24:49` AI 原生公司应当赋予 AI“第一拒绝权”，默认先探索 AI 自动化替代方案，从而砍掉传统 SaaS 销售中臃肿的 SE、SDR 和 RevOps 架构。 - `26:38` 面对 AI 时代的快速范式转移，“打造能用 20 年的软件”的传统 SaaS 模式已死，现代初创企业必须具备每六个月将产品推倒重构的敏捷性与勇气。 - `31:20` 现代企业正重演智能手机早期的“影子 IT”博弈：员工对 Agent 极致自主性的追求与企业安全部门对控制力的渴望形成张力，积极接纳、以“Yes”为默认选项的企业将最终占据先机。 - `33:45` 技术差距会被极速抹平，极高的人才密度是企业唯一持久的护城河；小团队、高人才密度的“精简卓越（Fewer, Better）”模式是实现组织快速战略掉头的根基。 - `35:45` Serval 的终极愿景在于为从业者解锁真正有意义的工作，剥离掉机械繁琐的无意义打杂，弥合理想职业憧憬与现实工作琐事之间的鸿沟。 ## Detailed walkthrough ### `00:00` 缩小理想与现实的鸿沟：打造 AI 原生代 ServiceNow 对话一开始，Serval 创始人兼 CEO Jake Stauch 分享了一段颇具共鸣的职业哲学：任何人在初入职场时，所抱有的理想化憧憬与日后日复一日面对的真实工作之间，往往横亘着一道巨大的鸿沟。就像孩童时代人们渴望成为宇航员或消防员，真切入行后才会察觉工作中充斥着大量繁琐、枯燥的杂务；而 Serval 诞生的初衷，正是要做一款能够抹平“理想中的工作”与“现实中的工作”之间差距的工具。红杉资本合伙人 Pat Grady 随后直切主题：Serval 正在打造面向 AI 时代的下一代 ServiceNow，那么企业界究竟为何需要一个 AI 原生的企业服务管理（Enterprise Service Management，ESM）平台？ Jake Stauch 从第一性原理（first principles）解释道，ESM 的本质就是“员工在工作中获取支持与帮助”。员工提需求的理想状态，理应是即时提出、系统瞬间自动解决，无需苦苦等待服务台人工流转或指派工单。要达成这种完全自动化的体验，必须仰赖底层强悍的 AI 驱动支持。Pat 回忆起 2007 至 2008 年间红杉初识 ServiceNow 创始人 Fred Luddy 时的往事——彼时 ServiceNow 之所以能彻底颠覆 Peregrine 与 Remedy，关键就在于它提炼出了极其优异的底层抽象：**建立在数据库之上的工作流（workflows on top of a database）**。对于这一底层抽象，Jake 明确表示赞同并沿用，但他指出传统模式的核心死穴在于工作流的搭建与维护极其耗费人力： * **传统工作流运维周期冗长**：旧式平台搭建一套流程通常需要专职开发人员或外部顾问耗费数周乃至数月；但在当今业务迭代迅猛的环境下，当工作流终于上线时，实际业务逻辑可能早已变更，导致自动化永远落后于现实需求。 * **CMDB 与资产数据库滞后**：IT 资产数据的维护、录入与同步同样需要持续的人工干预与顾问支持，过程繁复痛苦。 * **Serval 的代码生成引擎（Code Gen）解法**：Serval 保留了“工作流架在数据库之上”的原语，但将构建方式全面升级为 AI 驱动。管理员只需用自然语言描述所需的工作流步骤、权限逻辑与审批节点，底层代码生成引擎就能立即产出代码，搭建耗时几乎压缩至零；面对外部数据源时，系统同样通过代码生成自动拉取并实时更新数据库，彻底终结了人工干预。 ### `03:30` 自动化建立门槛与“垃圾工作流（Slop Automation）”的治理 Jake 透露，在与 Pat 结识之初就曾提出一条核心观察：**要想在企业内真正推行自动化，构建自动化的过程必须与被自动化的工作本身一样简单，甚至要更加简单。** 换位思考一下 IT 人员的真实场景便能明白其利害——当收到一个重置密码的请求时，IT 人员面临两个抉择：其一是直接在 Google Workspace 中搜索用户并点击“重置密码”按钮，耗时几秒；其二是打开笨重的工作流设计器，费力地拖拽触发器、配置响应与分支逻辑。只要搭建自动化的门槛高于直接手动处理，人类本能就会倒向手动操作。唯有让自动化生成的阻力低于手动操作，企业自动化才能规模化普及。 然而，随着构建门槛骤降，业界开始出现“Vibe Coding”带来的负面效应——即“垃圾自动化（Slop Automation）”。例如，管理员可能在一周内为重置密码随手创建了 20 个功能大同小异的冗余工作流，导致底层 AI 在路由时发生混乱。为了解决此类“自动化膨胀”，Serval 开发了一款具备全局上下文感知的治理 Agent： ```mermaid flowchart TD accTitle: Serval 工作流防冗余治理架构 accDescr: 展示用户输入自然语言需求后，全局上下文 Agent 如何识别重复并输出结构化优化建议的完整流程。 subgraph UserInput["用户自然语言意图"] A["管理员输入新需求<br/>'我需要一套处理 X/Y/Z 的工作流'"] end subgraph ContextEngine["Serval 上下文治理 Agent"] B["全局工作流检索与拓扑分析<br/>分析历史库中已有流程与逻辑"] C{"检测到冗余？<br/>发现已有 19 个类似工作流"} end subgraph OptimizationPlan["智能治理与架构重整"] D["拦截无序创建并提供重构建议"] E["删除冗余流程（如移除 10 个重复项）"] F["分类合并剩余流程并补齐审批节点"] end A --> B B --> C C -- 是 --> D D --> E D --> F ``` 该 Agent 熟知系统中过往构建过的所有流程及其细微逻辑。当用户再次提议新建相似功能时，它会主动介入并给出架构专家级的引导：“系统中其实已有 19 个类似流程。我建议不要重复新建，而是删掉其中冗余的 10 个，将剩下的 9 个归整为不同分类并补齐审批节点。”它不仅是工作流生成器，更充当了帮助企业将业务意图精准落地为产品架构的智能参谋。 ### `06:30` 客户沉浸式共情：应用层初创企业在 AI 时代的真正护城河 针对外界对 Jake“极度以客户为中心”的评价，Pat 询问团队是否存在用来衡量产品改善的单一“北极星指标（North Star Metric）”，抑或更多依靠直觉与个案综合反馈。Jake 坦言自己采用的是彻底的“沉浸式浸润（full immersion）”策略： * **深陷客户现场的第一线互动**：Jake 亲自进驻了每一家客户专属的 Slack 协作频道，目前平台已拥有超过 100 家客户，涵盖大量大型企业（Large Enterprises）。这意味着客户在各自频道内几乎每天都会收到 Jake 本人的实时消息。 * **克服被琐事淹没的心理怀疑**：面对海量群组的高频对话，Jake 承认有时确实会感到不堪重负，甚至偶尔自省“我是不是在浪费时间”；但他坚信，这种对第一线运转情况的敏锐感知（finger on the pulse）是任何间接汇报都无法替代的。 * **以客户洞察对抗“可被隔夜复制”的功能壁垒**：在底层模型开发门槛骤降的时代，单纯的产品功能优势在极短时间内就能被竞品抄袭复制；初创企业最根本、最难以撼动的防御壁垒（Moat），正是深入业务毛细血管的**客户洞察与深度共情**。 ### `08:30` 应用层 vs 基座模型：以安全与边界为核心的企业级产品哲学 面对自 2022 年 11 月 ChatGPT 问世以来关于应用层软件“只是模型套壳（wrappers on top of a foundation model）”的持续争议，Jake 分享了他对于应用层公司如何与基座模型（Foundation Models）共处的核心心法：**“当新的更强模型发布时，你必须是由衷感到高兴的。”** Serval 的产品构建原则，就是确保自身的软件设计不会被基础实验室或超大规模云厂商（Hyperscalers）的能力跃迁淘汰，相反，新模型越强大，Serval 的产品表现就越出色。 Jake 犀利地指出，如今企业面对的核心矛盾早已不是“下一代前沿模型（无论是 Claude Opus 还是未来的 GPT-5.5）能力够不够强”——在通用智力层面，模型能力几乎是无限的；核心矛盾在于**“一家高度重视安全的大型企业，如何能够放心地在全公司范围内铺开这项技术，而不抬高自身的安全风险”**。因此在 Serval 的哲学里： * **“产品本身即是边界与管控（The product is the boundaries. The product is the controls）”**：企业级产品的核心价值在于对模型的能力施加精准的限制与轨道保护（guardrails）。 * **枯燥但必不可少的传统企业级特性**：这包括细粒度的权限体系（permissions）、审批流（approvals）、限制 API 集成的作用域（limiting the scope of API integrations）、全链路审计合规（audits）、日志（logs）、报表与告警通知。唯有具备这些严丝合缝的控制台，企业才敢放行 AI 在生产环境中运行。 * **架构解耦：双 Agent（Two-Agent）设计**：在整体系统架构上，Serval 并不把所有任务混杂在单个黑盒模型中，而是将员工和管理员面对的系统切分为两大核心 Agent，首要角色便是专注于理解意图、在安全边界内生成代码的管理员 Agent（Admin Agent）。 ### `10:00` 双 Agent 架构：在严格控制的确定性护栏下释放大模型推理力 Serval 的核心架构建立在两个协同工作的 Agent 基础之上：负责系统配置的 Admin Agent（管理员智能体）与直接面向终端用户的 Help Desk Agent（服务台智能体）。IT 管理员利用 Admin Agent，通过自然语言和代码生成构建企业所需的所有技能、集成工具与自动化脚本；而终端用户求助时面对的则是服务台智能体。这里的架构设计原则非常严格：服务台智能体绝对无法越权行事，它只能调用管理员已明确发布、配置了权限门禁与审批流程的工具。 这种“双管齐下”的架构带来了巨大的解耦优势。Jake Stauch 解释道，由于外围设有牢不可破的安全边界与审批链条，开发团队可以完全“放开手脚让服务台智能体自由发挥”（let the help desk agent run wild）。用户无论提出多么离奇或复杂的问题，服务台智能体都能调用最前沿的大模型推理能力去理解意图、拆解问题，但它实际落地的操作权限被死死框定在 IT 部门预设的安全工具箱内，兼顾了前台的极高智能化与后台企业级控制的确定性。 ```mermaid flowchart LR accTitle: Serval 双 Agent 协作架构 accDescr: 展示管理员 Agent 与服务台 Agent 如何分工以及安全审批门禁机制 subgraph AdminSide ["管理员侧 (Admin Tier)"] A["IT 管理员"] --> B["Admin Agent<br/>(自然语言生成 TypeScript)"] B --> C["企业工具与技能库<br/>(权限 / 审批流规则)"] end subgraph UserSide ["终端用户侧 (Help Desk Tier)"] D["终端员工"] --> E["Help Desk Agent<br/>(全推理交互)"] end E -->|"受控安全调用"| C C -->|"执行自动化脚本"| F["企业系统与 SaaS 资源"] ``` ### `11:12` 模型分工与“反向升级”：OpenAI 负责交互，Anthropic 负责代码生成 在底层模型选型上，Serval 并没有死守单一模型，而是根据任务类型对 OpenAI 与 Anthropic 进行了细分匹配。Jake 透露，在面向终端用户的直接交互、工具调用（Tool Calling）以及礼貌合规的响应生成上，OpenAI 的 GPT 系列模型长期保持着领先的稳定表现；而在后台编写自动化脚本的代码生成（Code-gen）场景中，Anthropic 的 Claude 系列（如 Sonnet 和 Opus）则表现最为出色。团队持续通过自动化 Eval（评估体系）追踪各大厂商最新模型的表现，力求始终保持在技术最前沿。 然而，将最新发布的模型接入生产环境绝非简单的“即插即用”。Jake 坦言，新模型往往是一把双刃剑：某些指标变强的同时，另一些过去运行顺畅的链路可能会突然崩坏。这并不是说新模型变笨了，而是因为团队针对旧模型的固有怪癖与特定行为习惯积累了大量的 Prompt 调优和工程基础设施；一旦底层模型切换，这些精细优化的提示词就会失效甚至产生副作用。Jake 甚至分享了他们不得不进行“模型降级回滚”的经历：有时新模型理论智商更高，但在边缘案例中的行为模式更加不可预测，缺乏稳定有效的安全护栏，团队最终宁愿换回虽然稍微没那么聪明、但行为稳定可控且速度更快的旧模型。 - **模型具体分工**：终端用户交互与 Tool Calling 倾向于选择 OpenAI；自动化代码生成（TypeScript）主力依赖 Anthropic（Claude Sonnet / Opus）。 - **模型切换挑战**：大量既有的 Prompt Engineering 是围绕特定模型“脾气”定制的，换代容易引发难以预测的连锁反应。 - **发布节奏与回滚**：新模型上线必须经过自动化评估与小规模客户灰度发布；如果出现不可控的漂移，团队会毫不犹豫地降级回滚。 ### `13:25` 为什么 Serval 不担心 Token 成本：生成代码而非转售 Token 针对主持人 Pat Grady 提出的关于成本控制与商业化成熟度的疑问，Jake 强调团队现阶段的战略重心依然是“确保产品具有魔法般的体验”，而非过早压缩模型预算。Serval 拥有这种底气的原因在于其独特的单客经济模型（Unit Economics）——他们本质上并不做“转售 Token”的买卖。 在 Serval 的架构中，生成的自动化流程是编译后的 TypeScript 代码。当用户初次定义流程时，系统消耗 Token 生成脚本；但当后续成千上万名员工请求重置密码时，系统只需在沙箱中直接执行已固化的代码，根本不需要重新调用昂贵的代码生成模型。此外，随着 Serval 内部覆盖长尾企业场景的自动化脚本库越来越庞大，实际需要从零生成代码的频次在持续递减。Jake 甚至经常提醒工程师：“去花更多的钱，用最好的模型”，因为长期的技术优化空间非常巨大。但他同时也指出，未来的成本痛点可能会出现在长期运行的“后台 Agent”（Background Agents）上——这类智能体需要深入挖掘历史工单、解析海量设备日志并主动寻找潜在隐患，这类重度消耗算力的场景需要尽早建立成本风控。 ### `15:22` 基础模型实验室会下场吞噬 ITSM 吗？专注力与 ARR 算术题 当 Pat Grady 假设 OpenAI 或 Anthropic 某天决定利用第一方资源下场打造一个“OpenAI 版 ServiceNow”时，Jake 剖析了初创公司在面对巨头时的生存逻辑。他直言，任何初创公司声称“我们靠纯技术就能碾压拥有无限资金和顶尖 AGI 人才的巨头”听起来都很幼稚，但商业历史一再证明，初创公司往往能战胜资源无限的现有巨头——甚至 OpenAI 和 Anthropic 本身的崛起就证明了专注的初创团队可以击败科技寡头。 Jake 提出了一个极具说服力的 ARR 现实对比：在过去短短几个月内，Anthropic 增加的年度经常性收入（ARR）甚至超过了 ServiceNow 在过去 20 年积累的总和。对于这些致力于实现通用人工智能的基础模型实验室而言，把最顶尖的天才工程师抽调出来，投身于错综复杂、充斥着长尾合规与定制化集成的企业服务管理（ITSM/ESM）泥潭，在商业战略上是极不划算的资源错配。大模型实验室可能会发布轻量级、面向中小企业（SMB）的简单问答工具，但深入复杂的企业级工作流核心需要极高的专注度，巨头很难为此转移核心航向。 ### `17:18` 跨越规模的 IT 痛点，与在 ServiceNow 审批 Cursor 的荒诞日常 谈到客户群体的分布，Serval 既服务数百人的前沿 AI 原生公司，也服务员工规模达数十万人的传统跨国巨头。出乎 Jake 意料的是，AI 原生初创与超大型企业在 IT 痛点与核心需求上表现出了惊人的一致性。真正的差异完全在于决策链条与落地摩擦力（Go-to-market and implementation）： - **数百人的初创公司**：通常有一位雷厉风行的 IT 负责人，能当场拍板员工入职流程该如何做、密码重置由谁批准。 - **数十万人的大型企业**：往往没有人明确知道某项流程的最终负责人是谁，推进任何改动都需要在冗长拖沓的跨部门委员会之间反复拉扯。这也解释了为何各大 AI 实验室近年来纷纷组建庞大的企业咨询与落地部署团队，因为组织协调成本才是阻碍 AI 渗透的真正限速步骤。 最后，Jake 分享了客户向他们反馈中最令人动容的一点：Serval 重新让那些热爱技术的 IT 人员找回了技术工作的创造力与乐趣。许多 IT 工程师最初选择这个行业是因为对技术充满热忱，但现实中却被淹没在机械重复的工单审核中。Jake 讲述了一个极具黑色幽默的真实故事：在采用 Serval 之前，有位客户的 IT 人员每天耗费大量工作时间，困在古老陈旧的 ServiceNow 工单界面里，一次次手动点击审批，只为了给公司里的其他工程师开通 AI 编程工具 Cursor 的使用权限。这种“在极其老旧的官僚软件里为别人开通下一代尖端技术”的反差感令人窒息，而将 IT 人员从这种荒诞的打杂苦工中彻底解放，正是 Serval 带来的最大价值。 ### `20:00` 从“工单黑洞”到业务重塑：大小企业对 IT 体验的差异需求 在谈到客户画像时，杰克·斯陶奇（Jake Stauch）对比了 AI 原生企业与传统大型企业对 Serval 的截然不同诉求。在 AI 原生公司中，IT 团队往往有一种被时代抛下的失落感——公司的工程师和业务人员都在使用各种酷炫的 AI 工具，而 IT 团队自己的系统却还停留在旧时代。Serval 为他们带来了专属的现代化 AI 武器库，让 IT 部门终于能用上尖端技术。 相比之下，大型企业更看重业务层面的深度转型以及基层员工的实际体验。在小型公司，即便 IT 流程不够完善，也绝不会有人为了等待一个回复而耽搁数周；但在大型企业中，员工提交的工单往往会直接坠入“无底深渊”（into the abyss）。员工不知道工单处于什么状态、有没有人在处理，焦急之下只能再提一张相同的工单，结果造成后端处理混乱、重复劳动，甚至导致核心业务被彻底卡住数周之久。Serval 深入解决这类大企业的结构性痛点，从而从根本上重塑员工在组织内的日常工作体验。 ### `21:07` 吃自家狗粮：“梦之队选秀”与自动化全员招聘 当被问及 Serval 内部有哪些令人惊喜的“吃狗粮”（Dogfooding）用法时，Jake 笑称自己逼着团队“把所有事情都搬到 Serval 上跑”，上至日常办公申请，下至零食采买全不例外。而在这些实践中，最惊艳的莫过于内部一个名为“梦之队选秀”（Dream Team Draft）的招聘渠道。Serval 摒弃了广撒网、海选式的传统招聘套路，采取以人为本（person-first）的策略，专注于在全球范围内定向锁定并挖掘顶尖人才。 整个流程极其丝滑：团队成员只要在工作中遇到过极具天赋的前同事或业内高手，就可以把对方的 LinkedIn 主页链接直接丢进 Slack 里的“梦之队选秀”频道，剩下的全权交给 Serval。Serval 会自动解析候选人档案，并触发一整套自动化流程——不仅将候选人纳入精准的外展培育计划，还会配合一系列连市场团队都要求保密的定向曝光策略，让对方在各种日常浏览场景中反复看到 Serval 的身影。Jake 指出，这些顶级人才通常不可能第二天就辞职，公司是在“放长线钓大鱼”，通过 Serval 的自动化系统提前完成心智占领。 ```mermaid flowchart LR accTitle: Dream Team Draft Recruitment Workflow accDescr: An automated candidate sourcing flow triggered by an employee submitting a LinkedIn profile into a Slack channel. subgraph Trigger["员工触发"] A["员工发现顶尖人才"] --> B["分享 LinkedIn 链接至频道"] end subgraph ServalEngine["Serval 自动化中枢"] B --> C["解析档案与背景"] C --> D["自动化定向外展与培育"] C --> E["全网心智渗透与精准触达"] end subgraph Outcome["长线沉淀"] D --> F["持续保持品牌第一提及度"] E --> F F --> G["建立高意向顶尖人才库"] end ``` ### `22:43` Serval 的团队文化：极度友善、高能量与“零新手保护” 在聊到为何顶尖人才愿意加入 Serval 时，Jake 动情地表示这是他共事过的最棒的一群人。许多求职者在踏进办公室、与团队接触后，都会被那种极具感染力的友善、聪明且充满乐趣的氛围所震撼。除了技术上充满吸引力——构建极其复杂的企业级自动化，横跨 HR、法务、财务、IT 和安全等多个领域，堪称 AI 工程师的“终极训练场”之外，真正让人下定决心加入的，往往是那种强烈的团队归属感。 然而，谈及文化中“不具备”的特质时，Jake 同样非常坦率：Serval 绝非适合所有人，尤其不适合渴望系统化培训与导师辅导的人： - **拒绝保姆式培训**：团队虽然友善，但每个人都专注在自己的战斗中，这里没有按部就班的入职培训项目（onboarding program），也不会有专门的教练或导师手把手教学。 - **高模糊度与首日生产力**：公司要求员工从第一天起就具备产出能力，能够主动在巨大的不确定性中摸索出自己该做的事，并以极高水准将其交付。 - **扁平到底与模糊的晋升路径**：组织内部没有传统意义上的层级晋升阶梯，甚至几乎没有组织架构图。Jake 幽默地承认自己“甚至不知道谁在技术上直接向我汇报”，对于追求传统职级晋升的人来说，这里并不是理想选择。 ### `24:49` AI 优先原则：砍掉 SE 与 SDR，重构企业组织职能 在探讨如何真正作为一家“AI 原生组织”运营时，Jake 分享了他与以往在 Verkada 及早期创业经历完全不同的管理哲学：公司开始对每个岗位和部门的存在合理性提出质疑，并赋予 AI“第一拒绝权”（right of first refusal）。这意味着每当考虑设立新职能或招聘新团队时，默认的假设都是“这件事情或许不再需要由真人来完成”。 在这一原则下，Serval 彻底颠覆了传统的企业软件销售架构： - **砍掉 SDR 与 SE**：公司没有设立销售开发代表（SDR），也完全不设解决方案工程师（Solutions Engineering / SE）。客户执行官（AE）虽然在技术背景上并不比以往的销售更深厚，但他们实时配备了 Serval。 - **销售实时辅助能力**：在与潜客通话的过程中，Serval 能够根据客户提问瞬间给出精准的技术解答，甚至在电话中实时生成定制演示文稿（deck）、竞品对比小抄（battle cards）以及对比分析表。 - **极度精简的后台职能**：通过让前置部署工程师（Forward Deployed Engineers, FDE）负责客户试点交付，并利用 AI 自动化赋能工具，产品市场团队仅凭极少的人手便支撑起了大规模的赋能体系，大幅延缓了收入运营（RevOps）等传统职能岗位的扩张节奏。 ### `26:38` CEO 角色的演变与“梯度下降式”六个月产品重建论 Serval 成立已有约两年时间，公司的爆炸性增长也彻底重塑了 Jake 作为 CEO 的精力分配。在最早期，他曾感到自己“非常没用”：CTO 正在全力写代码搭建产品，而他拼命尝试招聘、约客户电话，却屡屡受挫，就像推着巨石上山；而如今，公司已经形成运转飞轮，开始拉着他向前狂奔。尽管他依然每天深入一线抓销售、跟客户、搞招聘，但他坦言自己花在深度思考产品方向上的时间变少了。 ```mermaid flowchart TD accTitle: Gradient Descent Product Feedback Loop accDescr: Closed loop feedback mechanism between customers, forward deployed engineers, and product iterations. C["客户现场实际诉求"] --> FDE["前置部署工程师 (FDE) 驻场响应"] FDE -->|"快速修补与功能调整"| P["产品即时更新迭代"] P -->|"每周产品质的飞跃"| C ``` 如今 Serval 的产品进化更像是一个“产品改进的梯度下降”（gradient descent for product improvements）：客户的真实反馈源源不断地涌向驻场的前置部署工程师（FDE），FDE 迅速在现场修补、调整并迭代进核心产品，形成了一个紧密的闭环，使得产品几乎每周都在脱胎换骨。 对于 AI 原生创业，Jake 提出了一个极具颠覆性的底层认知：企业必须具备以极快速度自我革命和自我颠覆的勇气。几个月前坚信不疑的架构或方向，可能转眼就要推倒重来，无论是在产品端重命名模块，还是彻底转变核心机制。在这一代技术浪潮中，“打造一套能维持 20 年的软件”的传统 SaaS 幻梦已经破灭，现在的现实是：“去打造一套希望能用上 6 个月的软件，一旦范式转移、市场巨变，你就必须做好将其彻底推倒重建的准备。” ### `30:00` Serval 作为技术与企业业务之间的“翻译缓冲层” Pat Grady 指出，底层基础模型的演进速度日新月异，但企业内部的变革速度往往相对迟缓。因此，像 Serval 这样的初创团队处于中间位置，扮演着一个缓冲层（Buffer Layer）的角色，核心职责就是吸收这些飞速涌现的新能力，并将它们转化为对客户真正有用的业务价值。这在本质上是一个变革管理（Change Management）的课题：如何防止客户被基础模型倾泻而下的能力洪流所淹没？ Jake Stauch 完全赞同这一视角，认为 Serval 的本质就是一层“翻译层”（Translation Layer）。企业必须从客户的实际业务问题出发，而 Serval 部署的前线部署工程师（Forward Deployed Engineers，FDE）正是实现这一目标的关键。他们深入一线去理解客户究竟想解决什么业务痛点，然后帮助客户发现如何在 Serval 中构建落地方案。在另一端，Serval 的工程团队则负责紧跟底层 AI 技术的最新突破，将其转化为解决方案交付给客户。Serval 经常需要给客户做科普：“看，我们现在是这样解决这个问题的；顺便提一句，这跟三个月前我们的做法已经完全不一样了，因为我们有了全新的工具，不过别担心，我们会替你们搞定这一切。” 目前 Serval 正在进一步探索如何更凝练、更直接地弥合这一鸿沟。团队正在研发一种面向最终用户的 Agent，用户只需说明自己的业务痛点，Agent 就会直接给出方案并搞定执行，客户甚至完全不需要关心底层最新的 AI 突破，Serval 会在底层抹平所有技术复杂性。 ```mermaid flowchart LR accTitle: Serval 翻译缓冲层架构 accDescr: 展示 Serval 如何连接前沿 AI 能力与企业实际业务需求 subgraph Tech["底层技术"] A["基础模型能力浪潮<br/>(迅速迭代更新)"] end subgraph ServalLayer["Serval 缓冲与翻译层"] B["工程研发体系<br/>(吸收最新 AI 技术)"] C["前线部署工程师<br/>(FDE 方案落地)"] B --> C end subgraph Enterprise["企业客户业务"] D["企业实际业务痛点<br/>(变革节奏相对平缓)"] end A --> B C <--> D ``` --- ### `31:20` 自主性 vs. 控制力：现代企业中的“影子 IT”博弈 谈及对 AI 领域最反共识（Contrarian）的观点时，Jake 指出，当前正在显现一道巨大的认知鸿沟——究竟是谁想要自主性（Autonomy），又是谁想要控制力（Control）。在企业内部，员工个人渴望极致的自主性，巴不得自己的 Claude Agent 能拥有所有系统权限、替自己代办一切琐事；然而，企业组织本身却绝对不希望员工的 Agent 拥有如此不受约束的自由度。这种张力在消费级产品与企业级产品的分化中尤为明显：消费级产品生来就是让 AI 替用户做所有事，而企业级软件的核心则是构筑严密的控制层（Control Layer）。当下员工正在自发把各种外部 Agent 引入日常办公，这让企业的安全部门和 IT 部门如临大敌。 Pat 联想到了当年智能手机兴起时的“影子 IT”（Shadow IT）浪潮：最初企业全员配发黑莓（BlackBerry），因为 IT 部门可以完全锁死黑莓系统；随后员工开始私自携带 iPhone 办公，在上面同步工作信息和工作软件。当时绝大多数企业 CISO（首席信息安全官）的第一本能也是严防死守、全面封杀，但最终他们意识到，这其实是员工追求生产力的先行指标，最终只能选择接纳并拥抱这一潮流。 两人一致认为，今天的 AI 正在上演完全相同的剧本。员工最清楚什么工具能让自己高效，顺应这些信号的企业最终会站在历史正确的一边。在应对 AI 工具时： - **以“Yes”为默认选项的企业**将大幅领先那些默认说“No”的保守公司； - 敢于冒险、积极拥抱 AI 的企业也将成为首批遭遇安全事故并承担后果的先锋，并在教训中率先跑通治理体系。 --- ### `33:45` 唯一持久的护城河：高人才密度与“精简卓越”（Fewer, Better） 被问及 Serval 眼下面临的最大痛点时，Jake 坦言依然是“招聘”。尽管外界普遍鼓吹 AI 将自动化所有工作并消灭就业机会，但现实中每家 AI 初创企业都在前所未有地疯狂招人。在 Jake 看来，技术本身会被快速拉平，**人才是唯一剩下的真正护城河**。唯有招募到更优秀的人才，才能在激烈的竞争中保持领先。 随着公司体量快速增长，创始人很难再与每位员工保持深入互动，往往面试和入职培训之后就很少有一对一交流的机会，因此如何维持极高的招聘门槛是 Jake 最感到焦虑的挑战。Pat Grady 补充道，在推理与算力成本不断下降、模型能力持续上升的时代，唯一的常量就是加速变革。面对瞬息万变的环境，组织必须针对敏捷性（Agility）进行极致优化，而实现组织敏捷性的最佳途径就是拥有极少数量但素质最高的核心人才。 Jake 透露，Serval 团队在招聘上的核心准则是 **“精简、卓越”（Fewer, Better）**。这一理念贯穿整个公司的管理思维： - **六个月重塑一次公司**：未来产品的形态可能每隔六个月就需要推倒重来，Serval 未来的形态可能与今天完全不可同日而语； - **小团队的高敏捷掉头**：如果团队规模膨胀到数千人，在需要调整 GTM（走向市场）策略或颠覆核心产品形态时，说服全员转向将极其困难；而维持一个精简、高人才密度的敏捷团队，可以在一夜之间拥抱重大的战略转型。 --- ### `35:45` Serval 的终极愿景：弥合理想职业与现实工作的鸿沟 Pat 提出了一个假设性问题：假定未来 Serval 成为了一家庞然大物，拥有数不清的客户、员工、收入、市值和自由现金流，届时在这些传统的商业度量指标之外，Jake 希望世人如何评价 Serval 的社会影响力？ Jake 回答，他希望 Serval 留给世界的印记非常纯粹：**为人们解锁真正有意义的工作（Unlock meaningful work for people）**。 Jake 分享道，在任何职业中，人们心中对这份工作的理想化构想，与其每天真正面对的现实琐事之间，永远存在着巨大的落差。就像小孩子梦想成为消防员或宇航员，可一旦真正入行，就会发现充斥着大量自己不喜欢的内容。Serval 的终极使命，就是成为那个弥合“职业理想”与“现实工作”鸿沟的工具——把那些重复、枯燥、没有生产力、违背人们从业初衷的琐碎事务全部自动化剥离掉。 Serval 已经在 IT 运维领域初步证明了这一点，未来随着全组织自动化能力的释放，它将让各行各业的从业者重新回归到他们最初满怀热情签下劳动合同时真正想做的工作中。Jake 总结道，他不希望人们只把 Serval 记作“一个自动化砍掉了大量 IT 岗位”的工具，而是希望大家真切地感受到：“Serval 让人们的工作生活变得美好了太多。” ## Notable quotes > `00:00` 建立在数据库之上的工作流（workflows on top of a database） — Fred Luddy > `03:30` 要想在企业内真正推行自动化，构建自动化的过程必须与被自动化的工作本身一样简单，甚至要更加简单。 — Jake Stauch > `08:30` 当新的更强模型发布时，你必须是由衷感到高兴的。 — Jake Stauch > `08:30` 产品本身即是边界与管控（The product is the boundaries. The product is the controls） — Jake Stauch > `13:25` 去花更多的钱，用最好的模型 — Jake Stauch > `21:07` 把所有事情都搬到 Serval 上跑 — Jake Stauch > `26:38` 打造一套希望能用上 6 个月的软件，一旦范式转移、市场巨变，你就必须做好将其彻底推倒重建的准备。 — Jake Stauch > `30:00` 看，我们现在是这样解决这个问题的；顺便提一句，这跟三个月前我们的做法已经完全不一样了，因为我们有了全新的工具，不过别担心，我们会替你们搞定这一切。 — Jake Stauch > `33:45` 精简、卓越（Fewer, Better） — Jake Stauch > `35:45` 为人们解锁真正有意义的工作（Unlock meaningful work for people） — Jake Stauch > `35:45` Serval 让人们的工作生活变得美好了太多。 — Jake Stauch ## Mentioned Jake Stauch, Pat Grady, Fred Luddy, Serval, Sequoia Capital, ServiceNow, Peregrine, Remedy, OpenAI, Anthropic, Verkada, BlackBerry, Google Workspace, Cursor, Slack, LinkedIn, ChatGPT, Claude Sonnet, Claude Opus, TypeScript ## Video description Jake Stauch, founder and CEO of Serval, is building a ServiceNow for the AI era. His most contrarian bet is that the product should look like boring old enterprise software, but with unlimited intelligence. Serval's architecture splits work between two agents: an admin agent that uses code generation to spin up workflows from natural language, and a help desk agent that can only act through the tools admins explicitly approve. Jake explains why his team uses OpenAI models for end-user interaction and Anthropic models for code generation, why new model releases sometimes have to be rolled back when prompt tuning breaks, and why he's not worried the foundation labs will come downmarket. He also makes the case for "fewer, better" hiring as the only durable moat in a world where products may need to be rebuilt every six months. Hosted by Pat Grady, Sequoia Capital [Source](https://pscrb.fm/rss/p/traffic.megaphone.fm/CPUAI4526751506.mp3)

[0:00] Fred Luddy: 建立在数据库之上的工作流（workflows on top of a database） [3:30] Jake Stauch: 要想在企业内真正推行自动化，构建自动化的过程必须与被自动化的工作本身一样简单，甚至要更加简单。 [8:30] Jake Stauch: 当新的更强模型发布时，你必须是由衷感到高兴的。 [8:30] Jake Stauch: 产品本身即是边界与管控（The product is the boundaries. The product is the controls） [13:25] Jake Stauch: 去花更多的钱，用最好的模型 [21:07] Jake Stauch: 把所有事情都搬到 Serval 上跑 [26:38] Jake Stauch: 打造一套希望能用上 6 个月的软件，一旦范式转移、市场巨变，你就必须做好将其彻底推倒重建的准备。 [30:00] Jake Stauch: 看，我们现在是这样解决这个问题的；顺便提一句，这跟三个月前我们的做法已经完全不一样了，因为我们有了全新的工具，不过别担心，我们会替你们搞定这一切。 [33:45] Jake Stauch: 精简、卓越（Fewer, Better） [35:45] Jake Stauch: 为人们解锁真正有意义的工作（Unlock meaningful work for people） [35:45] Jake Stauch: Serval 让人们的工作生活变得美好了太多。

[20:00] Jake Stauch: I am in this ancient ticketing system helping somebody else at the company get access to a really cool AI tool. And my tools are still stuck in the past... With Serval, they get to use the cool stuff. [25:00] Jake Stauch: There's going to be less of this idea of like, 'I am building a software that's going to last for 20 years' and more 'I'm going to build software that hopefully will last six months and then I might have to rebuild it once the paradigm shifts.' [35:00] Jake Stauch: We want to be the tool that actually closes the gap between what you think your job is going to be and what your job actually is.

[0:00] You know, I think that there's always a gap between the idealized vision of what you think your job is going to be and then what your job actually is. I think it's true for every profession. You idealize and kids do this the most, right? When they're like, want to be a firefighter, an astronaut, what that job looks like. And then you get in that job and you realize, oh, there's actually a lot in this that I don't like. And we want to be the tool that actually closes the gap between what you think your job is going to be and what your job actually is. All right, I'm here with Jake, the founder and CEO of Serval. Jake, welcome to the show. Thank you so much. Great to be here. We're going to start with a high-level question. You guys are building kind of the next generation service now, like the AI native service now, so to speak. That is right. Why does the world need an AI native service now? Yeah, employees need help at work. That's kind of the idea here is we are a platform for employee support. The technical term is enterprise service management but what it really means is getting help at work And the ideal way to get help at work is you ask for something and you get it instantly automatically You don have to wait on somebody to track down a ticket and assign a ticket to somebody You just get help immediately That requires you to have some kind of automated support. And that automation is best built with AI. So we think about this from first principles. How do we support employees? You automate all the requests. How do you automate all those requests? AI is really a good tool to bring that automation to employees. Awesome. Let's say more about that. So I remember back in the day when we first met Fred Luddy, who is the founder of ServiceNow in like 2007, 2008 sort of timeframe. And at that time, people thought that ServiceNow was amazing because it was this big step function change over Peregrine and Remedy. And the key thing that they got right was to think about enterprise software as an abstraction is just workflows on top of a database, right? So they built kind of this flexible workflow configuration engine on top of a database. And at the time that was amazing. And, you know, IT people loved it and they were off to the races. What I'm hearing you say is that that's not enough with AI. There's kind of a new generation of automation that can be done Can you just say more about the thing that ServiceNow built and the thing that you guys have built and kind of the side by side like what is truly different this time around They got it right We also built workflows on top of databases and that is the right abstraction that those are the right primitives. The problem with their workflows and databases is that they require a lot of manual effort to build and maintain. So building those workflows often requires dedicated development resources to put those together. And while that sounds fine, you invest those resources, then you get a beautiful automation on the end of it. That can take weeks to months. And in an era where business processes are changing very rapidly, by the time you get that workflow implemented, your business may have changed and moved on and you want a different workflow. And so your automation kind of runs behind where you want it to be. And that's more true now than ever before. Same with the database. If you need to manually update those entries and look at your IT assets and make sure they're up to date in those systems, that's going to be very, very painful to have to bring in consultants or internal developers to update. We took this unique approach of let's keep those primitives, workflows on top of databases, but allow you to use AI to build the workflows and use AI to update the databases And the way we do that is this code gen engine where you describe the workflow that you want all the different steps and permissions and approvals and logic and we take your natural language description and we turn that into code And so your workflow appears instantaneously There practically zero time to develop those workflows And the same thing goes for our databases. You can describe exactly what data you want to take from which sources. And our system will actually generate the code to fetch that data and keep it up to date without you having to do any kind of manual intervention. I remember you said months ago, this is one of the things you said when we were first getting to know each other that really piqued my interest, something along the lines of, if you really want to drive enterprise automation, you have to make the process of building the automation just as simple, if not simpler, as the workflow being automated. Do you still believe that? Is that still true? I still believe that. And that insight came from just putting yourself in the shoes of someone in IT or another function, and you're presented with a task, somebody asks you to reset their password, and you've got two options. You can go into Google workspace, find the user, hit a button that says reset password, or you can open up a workflow builder, and you can drag the trigger, and then you can drag the response, and then you can build out this custom workflow. When you're presented with that choice, you're just going to reset the password. You're going to do the manual thing. [5:00] But if it were actually easier to build the automation, you would build the automation because it's just why wouldn't you? And I think that it comes down to that. People in the moment have to make that decision. And you want that decision to be very, very easy to opt for the automation, not opt for the manual step. Now, is there is there such a thing as being too simple to automate? Like, is there people talk about the vibe coding and all the slop that it produces? Is there such a thing as slop automation? Yeah, it is. It's real. And we've had to build some really interesting things around that. Because, yeah, when you make it so easy to automate, somebody might build the 20th password reset workflow this week. Yeah. And it's basically the same as the 19 that came before it. And now you've got all these duplicate workflows and the AI gets confused on which one to run. Yeah. How do you guys manage that? We built a new agent basically on top of Serval that we're really excited about that has full contextual awareness of all the workflows you've ever built before, how they work, what they're going to do. So when you say, hey, I want this workflow that does X, Y, and Z, it says, hey, actually, you've got 19 that already do that. I could modify one of these, but here's what I think you should do. I think you should actually delete 10 of them, separate these remaining nine into these different categories, add these approval steps. And so it actually walks you through the system and is kind of your assistant that an expert in our product to help you translate the business requirements into the actual product implementation Speaking of the product so you a product guy And one of the things that we've heard about you consistently from every possible source is that you're extremely customer focused and like really good at listening to the customers and figuring out what they need. Do you have a North Star metric that you rely on that just tells you the product is getting better and more useful? Or is it more you collect all the anecdotes, you synthesize them, you kind of have an intuitive sense. Like, is there a number that you can look at? I think it's the latter. Like I try to be embedded with the customers, like full immersion. I am in every single customer Slack channel. I think most of our customers will get a Slack for me and that channel every single day. And that is a huge, maybe. And just to set the context, a listener might think like, okay, you probably have four customers. How many customers do you have? No, over a hundred customers and a lot of large enterprises. And it is overwhelming at times to be in all those conversations all the time. And sometimes I feel like, oh man, am I wasting my time? But I feel like I really understand what's going well, what's not going well, and I just have my finger on the pulse. And there's just no substitute for that, especially when a lot of the implementation work has gotten very fast More and more of the moat for any startup is the customer insight the empathy of actually understanding what they want And if we can have a differentiated advantage around the customer insight that going to be much more valuable than having a product advantage, which is copyable overnight. Let's talk more about that because this has been a hot topic for a few years now. ChatGPT comes out in November of 2022 and immediately people start deriding application layer companies as wrappers on top of a foundation model, right? And what you just said kind of plays directly into this theme of there's always a school of thought that says, well, the foundation models can just do everything. And then there's a school of thought that says, sure, but you can build a company on top to close the gap between raw capabilities and like actual customer problems. How do you view your role running an application layer company versus the role of the foundation models, like where do you think the motes form around your business over time? Basically, to the extent somebody listening is interested in, like, how do you build an application layer company in this era? What are your thoughts on that? I think you have to be happy when the new models come out. And that is that is kind of the guiding principle that we have is how do we make sure whatever we building is actually not made obsolete by whatever the labs and hyperscalers come out with but actually is made better What a good example For us we think the product is the boundaries The product is the controls. The product is actually what limits the capabilities of the model. Because the question now is not, can Opus, can GPT 5.5 do these amazing things? Can they do the things I want to do in my enterprise environment, the capabilities are practically unlimited. The limitation now is how do I get comfortable as a large enterprise that cares about security and deploying this company-wide without elevating my security risk? And so we think about it from the boundaries. And so that means really boring old school enterprise software things around permissions and approvals and limiting the scope of your API integrations and having visibility into that, having audits and reporting and logs and alerts and just all of the things that make you feel comfortable letting the models run wild in your environment. And so one of the fundamental things we did from an architecture perspective is kind of divide the agents into two parts. So our customers, when they experience Serval, there's really two agents they work with. One is the admin agent that helps build [10:00] all of these tools and skills that configure how the help desk, what things that the help desk agent can do and what it knows about. And so it's the admins that build that. And then there's a help desk agent that end users talk to that resolves their problems. The help desk agent can only use the tools and skills that have been expressly built, published with approvals and permissions and all of that by the admins. And that architecture, that kind of like two-pronged architecture ends up being really, really powerful because you can let the help desk agent run wild, right? Because the end user can ask it anything and it can use its reasoning ability and its full intelligence to be able to solve user problems, but it can only use the tools that the IT admin has expressly said are okay to use. And those may have approvals attached, permissions that gate certain users from doing certain things. All of that is done on the admin side, but then you get like kind of the full ability and intelligence of the help desk agent to use those tools appropriately. What's under the hood? Is there anything you can say about which models you guys are having luck with and maybe how that's evolved over time? Yeah we use open AI and anthropic models today always experimenting with the latest models from all providers to make sure that we on the cutting edge running eval suites on everything that we do Today it still OpenAI and Anthropic models We find different models are better at different applications. So for the interaction with the end user, we're seeing the most luck with OpenAI models. And that has remained consistent for quite a long time. that actually calling the correct tools and responding to the user in the appropriate way, that's still we're having a lot of success with various GPT models and always keeping those up to date depending on the latest release. But on the automation side, which is mostly co-gen automation, having the most success with the Anthropik model. So continue to use those, Sonnet, Opus, and tons of trade-offs between the different models. And I think what's interesting in recent times is the new releases oftentimes are not just like plug and play. You know, sometimes you get some advantages and some things that were working really well don't work as well anymore. So that's become an interesting challenge as things go. Actually, yeah, how do you guys manage that? Like how long does it take to incorporate new models into the production version of your product? How much of that process is like automated in some fashion? How much of that is somebody just has to sit down and figure it out Like how do you manage that It not as automated as I like We have the evals automated but then in every situation when we have a new model that we testing some things get better and some things get worse And a lot of things that get worse not necessarily the model got worse, but we built a lot of prompt tuning and a lot of infrastructure around the known quirks or behaviors of that model. And those make less and less sense when the new model comes out or where you're swapping models. And so that's where a lot of the adjustments have to be made. And then you kind of run it through the evals and then you do a slow release across customers. So we're getting better at this, but I think there's certain cases where the trade-offs have not been worth it, where we've actually upgraded models and then downgraded the models and said, you know what, the old models are, maybe they're a little bit faster or maybe they're reliable in a way that the new models are. And so maybe the new models are a little bit smarter, but they misbehave in ways that are less predictable. and we have less predictable guardrails to prevent against. And so we're like, Hey, this model might not be as smart, but we know it's going to behave the right way for these customers. So, um, it's been an interesting challenge and it's changed over time. How much are you guys, um, factoring costs into the equation right now? Because I think, you know step one you got to make sure the product does something magical step two Okay now let make sure we got a business you know exactly And we can you know we can extract an an appropriate amount of value for this functionality Do you guys think much about cost at this point Or we kind of know where that's going over time. Let's make sure the product is magical and we'll figure out the cost element later. It's the latter. And I think one of the reasons that give us this flexibility is that our unit economics end up looking much better than a lot of AI companies because we are not in the business of reselling tokens. the way that our product works is that you build these automations, which are basically TypeScript. And once they're built, you don't have to rebuild that. And so every time the end user asks for a password reset, it's not going and regenerating code to reset a password. It's actually just running the code that's already been generated. Over time, users have to generate less and less actual code because we have a growing library of automations that cover the very long tail of things that you might want to do. And so there's not as much, especially in the kind of very expensive cogen token consumption, there's not as much as you'd expect. And so the United Kingdoms are very strong, even though we haven't done a lot of optimizations around that. So I tried to tell the team, spend more money, use the best possible product. We know long-term where this is going. We know that there are all kinds of optimizations we can make down the line. [15:00] So that's been our focus to date. I think that though, where it starts to get more interesting is as we explore more and more applications of like background agents, long running agents that are not just responding to help desk requests or not just building quick scripts for you, but investigating all of your historical tickets or investigating logs from devices and doing all this work in the background and maybe generating solutions to problems you didn't know you had. That's where it becomes a little bit more interesting where maybe the costs become more relevant. So that's where we'll probably start to think about costs a little bit earlier in the journey, because those could run away pretty quickly if you're not keeping an eye on it. Yeah, that makes sense. Let's say somebody at OpenAI or Anthropic wakes up tomorrow and they're like, wait a minute, I found this company called ServiceNow. And it seems to be like a major system of record, major center of gravity inside the enterprise. I think we should build as a first party product, you know, the OpenAI ServiceNow or the Anthropic ServiceNow. If they set their sights on you and come after you directly or come after your category directly, what would that mean for Serval? Yeah. I mean this is always a really tough question because on the one hand any response to like okay this company with infinite money and the best engineering talent and AGI wants to do what you do how are you better It kind of like any response that is going to sound pretty naive like, well, we're just going to beat them. But I think the history of startups tells us that often the smaller company does beat them. I mean, the existence of OpenAI and Anthropic are kind of proof that you can beat the entrenched incumbent with infinite resources. And I think it comes down to, you know, maybe divine providence favoring startups or maybe like a lack of focus is often what makes it hard to execute. And so, you know, when I was starting my first company in the whole, you know, every VC would ask me, won't Google just do this? And yes, Google will do a lot of those things, but it actually is very hard to do a lot of different things really, really well. And it's hard to divert your focus into all these categories. And I don't think ITSM makes the most sense as a focus area. One reason is that I think in the past couple of months, Anthropic has added more ARR than ServiceNow has in the past 20 years. Good point. And so does it really make sense for them to take their best and brightest people to throw them at this problem that even if they are very successful, it would take them years to get what they could get out of the rest of their product portfolio in a matter of months And so I don think they going they probably look at this category I wouldn be surprised if they built some kind of simple version maybe a more mid or SMB focused version but to really devote the time and energy to master the complexities of enterprise service management, not to say they couldn't, but the focus that would require, I think would be a bad use and bad prioritization of their resources. And I don't think that that's going to happen. Yeah, I think you're right. Let's talk about your customers for a minute. So you got a bunch of the kind of really nice AI native logos, and you're also starting to have some kind of big enterprises. How do the needs differ from the AI native crowd to the big enterprise crowd? And if you had to pick from each of those, what's the nicest thing that they would have to say about you? You know, Serval is amazing because what would they say? Yeah, I think what's been the biggest learning is how similar they are relative to how different. And I expected them to be much more different. But the pain points and the problems end up looking remarkably alike from the AI native to the large enterprises. We work with companies as small as a few hundred employees up to companies as large as a few hundred thousand employees. The difference ends up being how many people it takes to make a decision. And that what actually makes things really challenging is because It more of a go thing It a go It an implementation thing more than that Yeah So if you working with a company with a few hundred employees there probably an IT leader that can say this is how we going to do things This is how onboarding works. This is how we're going to reset passwords. If you're working with a company with a few hundred thousand employees, no one even knows who that person is, if that person exists. And so you end up in all these kind of committees trying to figure out what should we do here. And that's actually what makes it very, very challenging. And I think you see that in these labs building out these consulting businesses and more and more services and deployment resources because that ends up being a lot of the rate-limiting step in adoption is coordinating all these folks. So what would the nice things they say about me? I think – or about Serval. In the AI native early-stage companies, we often just – we take an IT person that's passionate about technology and we let them spend their time building. They got into IT because they love technology. And so much of their job before Serval, they weren't really getting to experience technology. My favorite example of this is a customer we had that spent a lot of their day fielding ServiceNow requests to provision someone's access to Cursor. Yeah. And that juxtaposition was just so sad. I'm like, I am in this like ancient ticketing system helping somebody else at the company get [20:00] access to a really cool AI tool. And my tools are still stuck in the past and I don't get to use the cool stuff. And with Servo, they get to use the cool stuff. Like there's actually an AI tool for IT built for them. And so that's, I think, what we see on the AI native side. I think in the large enterprise, you know, generally they're thinking about it at just a higher level of business transformation. And we hear a lot more about the end employee experience because at a small company, even if your IT processes aren't perfect, no one's waiting weeks to get a response back from IT. But a large organization, like you could send a ticket into, you know, into the abyss and just have no idea where it's at, if it's being worked on. So then you'll send another ticket and then there's confusion on the other side because now you've got two tickets from the same person. And there's actually people that are blocked for weeks from getting back to the thing they're trying to do. And so I think in a larger enterprise, we actually change the employee experience and what it feels like to be an employee and, and have this more broad impact because the problems are actually a lot deeper in those big organizations. What is a delightful or a surprising use of Serval at Serval? How do you guys use it? Oh man I forced the team to use it for everything Um so every time I see So where do they really push the boundaries of like what they can can do Yes exactly I mean obviously things like office requests like snacks like all of that has to go through Serval But I think one of the coolest things we do for Serval is one, we have a channel called Dream Team Draft. We take this very person first approach to recruiting where we want to identify the best people in the world and we want to bring them to Serval versus just cast a wide funnel, host an open tryout and see who makes it. And so people put the best people they've ever worked with in this channel. They post to LinkedIn. That's a Serval channel. So Serval will take that profile and then run a series of automations. One, it'll run into all of our outbounding campaigns, our nurture campaigns. It'll also do a lot of things that my marketing team won't let me talk about of like making sure that they are seeing Serval everywhere they go. And Serval becomes very top of mind for them. And we basically warm this audience to make sure that they know about Serval. And we're playing the long game because these are generally not people that are going to leave their job tomorrow, but people that we'd love to work with one day. And so I love the idea of going in and saying like, hey, all I have to do as an employee is just like, I love this person. They're great. And I'm done. And the talent team will be able to through Serval have all these automations that kind of get them into the system. That is very cool What the best reason to work at Serval Like why do people join your team I think it is the greatest group of people I ever worked with I think when you walk into our office and you meet our team it just a group of so you know people that are so kind and so talented and so fun to be around. And I think that that's, what's really unique is, is I didn't even know I was selecting for this when we started the company, but something candidates started telling me is that, wow, your team is so nice and they're so fun to be around. And like I walked in the office and the energy was just contagious and I wanted to work there. And obviously there's really interesting technical problems, you know, building these really complex enterprise automations, getting to touch HR, legal, finance, IT security. Like it's kind of a training ground. We often think about this as a training ground for anyone who wants to do anything in AI. You get to like touch all these different departments, build all these cool workflows. But I think the, If I'm being honest, the reason you join Serval is because you meet the team and you realize this is the place for you. Yeah, very cool. We heard some of the words that you use to describe your culture, fun and nice and high energy people. What is it not? It is not a good place for, let's say, a lot of training or mentorship. So everyone is kind but everyone doing their job and there is not a lot of hey you going to be onboarded through this program and you going to learn how to do these things and we going to train you really well and we going to pair you with some resources and coaching and mentorship. And there are great companies that do that really well. We are not one of them. So we hire people to come in and basically be productive on day one and who like that ambiguity of I've got to show up and figure out what I'm supposed to do and then do it really, really well. Um, so it's, it's not a place for coaching mentorship. It's not a place for very clearly defined career paths. We don't know where a lot of these functions are going to go. So there's not going to be this clear progression up the org chart. There's not really an org chart. I don't actually know who reports to me at the company. Um, I, I am like blissfully unaware of who technically reports to me versus other people because we try to keep everything as flat as possible. And, and so if you're looking for that kind of like natural progression, you know, it's just not going to be a good place for you. Yeah. Yeah. As far as one of the big topics that we've had a lot of conversations on recently, just amongst founders and folks, is this idea of living in the future. And not only the product that you build needs to be AI native, but the way that you build it and the way that you manage your organization needs to be AI native beyond. [25:00] using Serval itself. What does that mean for you guys? How has the way that you operate changed this time around versus Verkata or your prior companies? In so many ways. So one is we are questioning everyone's role, every department. We're wondering if it needs to exist anymore and if it still makes sense. And oftentimes it does. We relearn the necessity of some departments that we thought maybe we didn't need. But we start with the the assumption that maybe this doesn't need a person anymore. Maybe this could be AI. So AI almost gets like the right of first refusal for every job or every department of like, Hey, maybe we don't need this at all. And maybe this can be much smaller than maybe this is a good example of something that fully went to AI. Solutions engineering. So we don't have SEs. We also don't have SDRs, but I think that's been, that's less of a controversial take over the past few years, but we don't have SDRs and we don't have a solution engineers. our reps are not necessarily more technical than reps in past generations have been, but they have access to Serval. And so any question they have about how the product works or that a customer comes up with a prospect, Serval is going to give them an instant answer to that question. Serval can even build them decks build them one and quick battle cards and comparison sheets like all of that on the fly in the middle of a call So we expect more out of our AEs and they not going to have the SE resource. We do have four deployed engineers that assist with the actual pilot implementation, but that's been one example where we didn't need that. We also delayed hiring in a lot of domains, and sometimes not by choice, just by the slowness of our hiring, but we've discovered how far we can get. On the enablement side, we have someone in product marketing who's done an incredible job of building out enablement and all these automated resources and scaled that quite far. And we definitely need more help there. But a lot of times you get further than you think with these AI tools. RevOps is another one where we've gotten pretty far without a RevOps hire, but then discovering like, actually, you do need somebody eventually. And so there's a lot of these things where you delay it a little bit and you're like, actually, we need somebody, but maybe this department is a little bit smaller than we thought it was going to be. Company is about two and a half years old. They're about two years old, two years old. Okay. In the last, and you guys have grown like crazy, more people, more customers, all that good stuff. How has your job changed in the last two years In the very early days I felt very useless honestly My CTO is building the product and it very clear what we need to build There so much to build and I trying desperately to hire and to set up customer calls and maybe try to sell this thing It's just not working. And so I think in the early days, it was kind of like trying to figure out how I can be most useful when we don't really have a business yet. And then over time it switches and it becomes a business and stops being me kind of pushing the boulder up the hill and more of the business dragging me along. I think what hasn't changed, I'm still very involved with customers, both in the sales side, but also in like the long term success and talking to customers every day. I'm still very involved in recruiting. What I'm not as involved in that I'd like to be is a lot of product. In the early days, I am thinking nonstop about the product direction. And now it feels like the product direction is kind of emerging from our customers through our four deployed engineers and going right into the product. And which is in many ways great because you have this kind of nice closed loop of customers talking to forward deployed engineers and then the products getting implemented and getting better all the time. You know, I've often referred to this as like gradient descent for product improvements because our forward deployed engineers are just swarmed with all these you know all this feedback from customers And they like oh I fix this I make this better I change this And like you fast forward a week and like wow the product is a lot better than it was a week ago And it keeps going that way But I get to spend a lot less time thinking about the future and where we want to be And I think that something that I need to spend more time on because this stuff is changing so quick to your question earlier about, you know, how are we different as an organization and an AI native organization? I think a big difference is you have to be willing to reinvent yourself so much faster and disrupt yourself so much faster. Like we are thinking about just uprooting things that we were convinced were true months ago and going in completely different directions and all these different ways. And we have to have that flexibility. We're going to be renaming parts of the product. We're going to be completely shifting how we do certain things in the product. and we have to be willing to do that over and over and over again. And there's going to be less of this idea of like, I am building a software that's going to last for 20 years and more I'm going to build software that hopefully will last six months and then I might have to rebuild it once the paradigm shift and the markets have changed. Yeah, and let me ask you about that because there's a foundation model on one side or a set of foundation models and capabilities. There's a customer on the other and there's serval in the middle. and these capabilities are changing at a very rapid pace. This customer [30:00] is probably not changing all that fast. And so you guys in the middle are kind of this buffer that is trying to take all these capabilities and put them to work for the customer. So the question is really, it's kind of a change management question. Like how do you keep the customer from drowning on this downpour of capabilities coming out of the foundation models? I think that's exactly the right way to think about it. We are kind of that translation layer. Yeah. And we have to meet customers where they are. I mean, I think we very much have to understand their business problems. And that's what really helps with the forward deployed engineers is we are starting with their business problems. What are they trying to solve for? And then we are helping them discover how those solutions are implemented in Serval. We are on the other side, figuring out how to take in the latest advances in AI to be able to deliver those solutions. And so that is kind of what role we serve. And then we're often educating them of like, hey, here's how we do this. And by the way, it's changed since how we would have done this three months ago. And we have these new tools at play, but we will be the ones to help figure this out for you. And one of the things we're working on is how can we bridge that gap a little bit more succinctly? So how can we make an agent available to the end user that kind of says OK what are your business problems Cool Here what we going to do Here going to solve them So you don really have to think about the latest advances Serval just kind of takes care of that for you and you just have to focus on what are your problems What are you trying to achieve? What's your most contrarian take on the world of AI? So one take that I have, which I don't know how contrarian this is, but I think there's this big gap emerging between who wants autonomy and who wants control of these agents. And the individuals in an enterprise, they want autonomy. They want their clawed agent to do everything for them and have access to everything. The organization itself doesn't want their employees, agents to have all this autonomy. And there is this interesting tension emerging between, and I often see this in consumer versus enterprise products, where the consumer products obviously are built for a world where you want it to do everything. And the enterprise products are built more with this control layer. And what's happening in the enterprise is that the individuals are adopting these tools and wanting it to be able to do more. And the security organization, the IT organization is very worried about this and for good reason. And I think that's something interesting to track is this tension between autonomy. Like do organizations actually want autonomy or do just individuals want autonomy And how do you navigate that tension And that where we thinking a lot about the Servo product and how we help solve that It reminds me of shadow IT back in the day when consumers started to adopt iPhones and enterprises still had BlackBerrys because they could lock down the BlackBerry. And the iPhone started to show up with work information and then work applications. and they're kind of sneaking their way into the enterprise. And the instinct of most CISOs was, you know, protect, protect, protect. And then I think eventually they realized, well, wait a minute, this is kind of the leading indicator on what my employees need to be productive. And they started to embrace it. Yep. Right. And it feels like the same thing's happening now with AI where employees kind of, a lot of them kind of know what they need to be productive. And as long as you can just kind of systematically follow those signals and embrace it, you're more likely to end up on the right side of history. Yeah. And I think the companies that basically say yes as the default are going to be way ahead of the companies that say no as a default. And we're seeing this with the companies that just embrace it. They will also kind of be leading the charge and face a lot of the consequences of there are going to be security incidents. There are going to be problems And we going to learn a lot from those But I think that that is what we going to see is the companies that take those risks are going to get ahead But those risks are real And they're also going to be some of the ones that suffer some of the consequences on the security incidents. What's your biggest issue at the moment? Our biggest issue is hiring still. Every AI company I talk to is in the same situation. Even though AI is allegedly supposed to automate all this work and take away all these jobs, we're all still hiring more than ever before. And it's still like our number one priority and our number one concern. And so but I think people remain the biggest moat you can have. And having better people in the room is really the only thing that will keep you ahead of the competition. But it's the only moat that's left is the people in your organization. So hiring and scaling and keeping the bar incredibly high as we hire are the things that keep me up at night and worry me, especially as the business grows so much that I have I'm less involved. You know, there's a lot of people that I only meet in their interview and they're onboarding, but not have probably a lot of one-on-one interactions after that. Yeah. The talent density point, I think is a good one. And we think about that a lot too, because we're sort of in this world where cost goes down, capabilities go up. The result is accelerating change. If the world is changing quickly around you, you have to optimize for agility. Yes. The best way to optimize for agility as an organization is to have the small, [35:00] number of the best possible people. Right. And so I feel like the returns to talent density have never been higher than they are today. And so you guys could go hire a million people, but like doing so with the sort of quality and culture, culture fit that you need, you know, that's, that's tricky. And to your point, it makes it harder to sear the, to turn the ship. Yeah. And so our mantra on hiring is fewer, better, fewer, better. Like we say it over and over again, fewer, better. Like how can we make this department fewer and better? Yeah. And and that's going to be really important because, again, I think we're going to have to reinvent ourselves more frequently than companies have ever had to do this before. And I can imagine a future version of Serval where it's unrecognizable from what we do today because we just had to adapt so quickly. And that's much easier to do with a small, agile team than if you scale very rapidly, you become thousands and thousands of employees. And you say, hey, by the way, we're changing everything about our go to market. We're changing everything about what our product does. Yeah. You know, we're making some big changes to the product and it's nice to have a relatively small organization that can embrace that shift almost overnight. I can't imagine what we do if we had to convince thousands of people that this is the new direction. Yeah. Let's assume, and obviously this is not something we can take for granted, but just for fun, let's assume. Let's assume that Serval becomes a monster company. You know, gazillion customers and employees and revenue and market cap and free cash flow and all that great stuff. Let's assume you become a monster company. At that point, what would you want people to say about you? What else would you want to be true that is not contained in one of those traditional metrics of scale or success? I think I would want the impact of Serval to be very clear in terms of like what it did for the world The impact I think is most important of what we do today is we unlock meaningful work for people You know I think that there always a gap between the idealized vision of what you think your job is going to be and then what your job actually is. I think that's true for every profession. You idealize, and kids do this the most, right, when they're like, want to be a firefighter or an astronaut, what that job looks like. And then you get in that job and you realize, oh, there's actually a lot in this that I don't like. And we want to be the tool that actually closes the gap between what you think your job is going to be and what your job actually is. And we do that by automating away all this repetitive, menial work that you don't want to do and that is not productive and is not part of the reason you took this job. And we've done that in many ways for IT. And I think as we unlock automation for the entire organization, that's what we do for people is we get them back to the work that they actually signed up for and the work they actually enjoy. And so I would hope that there is clarity that that was the impact that we had. Yeah. And it wasn't just like, oh, Serval automated away a bunch of IT jobs. It's like, now I want people to feel like Serval made people's work lives a lot better. Awesome. That feels like a great place to end it. Jake, thank you so much for joining us today. Thank you so much for having me. This is a blast. Thank you.