Decagon Shifts 90% of AI Workloads to Fine-Tuned Open Source Models

Decagon 将 90% 的 AI 工作负载迁移至微调开源模型 基于专业开源模型而非庞大的前沿 API 构建的企业级 AI 智能体，表现更优、运行更快且成本更低。 Decagon 联合创始人 Jesse Zhang 和 Ashwin Sreenivas 概述了其公司如何从依赖前沿 API 转向将 90% 的智能体工作负载运行在微调开源模型上，以解决延迟、控制力和性能受限的问题。他们反驳了基础模型实验室将吞并整个软件层的说法，认为领域专业化、企业治理和上下文管理应属于应用平台的范畴。对话还详细介绍了 Decagon 如何将前置部署工程产品化，从支持类智能体拓展至主动式 AI 礼宾服务，以及如何应对国际业务增长和杰文斯悖论所推动的劳动力动态演变。 Decagon 将其 90% 的工作负载转移至微调开源模型，原因是大型通用前沿 API 无法在企业级规模下满足亚秒级延迟的要求。 (1:07) 为特定任务选择较小模型并非一种真正的妥协；针对窄领域任务微调小型开源模型，不仅能让其表现超越庞大的前沿模型，还能降低延迟和运营成本。 (5:00) Decagon 将 Decagon Labs 作为内部模型工厂来运营，以持续微调、评估和部署迅速演进的开源模型。 (9:26) 认为基础模型实验室是‘最后的初创企业’的说法是有缺陷的，因为企业需要专门的垂直应用层来管理工作流、合规性以及企业系统集成。 (14:45) 领域行为被微调进模型中，而特定公司的运营政策则通过上下文注入，以便在无需重新训练模型的情况下适应频繁的政策变动。 (14:45)

Decagon co-founders Jesse Zhang and Ashwin Sreenivas argue that enterprise AI agents succeed not by relying exclusively on frontier models, but by pairing fine-tuned open-source models with dedicated workflow, compliance, and orchestration software. They contest expectations that foundation model labs will consume the software ecosystem or that automated agents will trigger permanent structural unemployment. Specializing Small Models for Low-Latency Execution (5:00) Decagon shifted 90% of its production workload to fine-tuned open-source models after sub-second latency constraints made large frontier models impractical for conversational scale and real-time voice agents. Ashwin Sreenivas dismisses the perceived compromise between cheap small models and capable frontier models as a 'false trade-off.' When small models are stripped of unneeded general capabilities like complex coding or mathematics and tuned for narrow micro-tasks such as intent classification and guardrails, they consistently outperform general-purpose frontier models on speed, cost, and task accuracy. Frontier models remain central to Decagon's stack for open-ended, complex reasoning. The company uses frontier APIs to power Duet Autopilot, an auxiliary meta-agent that reviews thousands of production transcripts, flags weak topics, and generates simulation test suites to refine core agent operating procedures (AOPs). Despite utilizing smaller models, Decagon's token consumption per interaction has grown as the architecture runs parallel inference calls and automated verifications to maximize reliability. The Enterprise Governance Moat Against Foundation Labs (14:45) Addressing industry predictions that frontier model labs like OpenAI and Anthropic will eliminate the application layer, Jesse Zhang argues that enterprise value resides in workflow execution rather than raw model intelligence. Enterprise business logic and policies change constantly, meaning specific company procedures must be supplied in-context rather than permanently fine-tuned into base models. Application platforms are still required to integrate into legacy enterprise stacks, execute multi-step business logic, run compliance checks, and manage edge-case failures. Sreenivas adds that even human-level intelligence requires structured systems of record and databases to store state and pull knowledge. A natural market convergence is occurring: while foundation labs build end-user applications to capture return on investment, vertical application companies are becoming specialized model labs. Decagon expects enterprise adoption of self-trained open-source models to proceed slowly due to corporate governance, legal reviews, and evaluation overhead, leaving third-party orchestration platforms to bridge the gap. Productizing Forward-Deployed Engineering to Scale (21:21) While early-stage AI startups frequently rely on Forward-Deployed Engineers (FDEs) to establish new operational workflows with enterprise clients, the founders warn that unmonitored human deployment turns software companies into low-margin consultancies. Decagon adopts the operational thesis that forward-deployed teams must convert client friction into scalable product features. Historical company milestones—such as moving from hardcoded integrations to plain-text AOPs and automating onboarding via Duet—originated as manual FDE tasks that engineering productized. The founders contrast Decagon's configurable 'glass box' architecture with competitors like Sierra. Sreenivas notes that an enterprise customer switched to Decagon after finding Sierra's heavy reliance on external FDEs created an opaque 'black box' that delivered only three operational workflows over a full year, whereas Decagon's platform enabled the client's internal non-technical staff to deploy seven new journeys in a single month. The AI Concierge and Labor's Jevons Paradox (47:55) Improved model instruction-following has allowed Decagon to expand from reactive customer support into an 'AI Concierge' handling inbound sales, lead routing, and proactive outreach. Zhang predicts enterprise software will consolidate around horizontal platforms rather than niche vertical tools, mirroring the historical trajectories of Salesforce and Zendesk. Ashwin Sreenivas emphasizes that traditional CRMs will not vanish; rather, they will function as underlying databases pinged via APIs by AI agents that deliver high-touch service for pennies per interaction. Rejecting predictions of widespread technological unemployment, the founders point to Jevons paradox in enterprise service delivery. Lowering support costs by 30% does not prompt immediate mass layoffs; instead, enterprises unlock latent demand by deploying real-time support across all product tiers and digital touchpoints. Sreenivas contends that AI automates repetitive tasks while preserving careers, as high-growth companies hold support headcount flat while scaling user bases or pivot staff toward higher-value, proactive customer care. Decagon identifies talent acquisition rather than model context or voice latency as its core operational bottleneck. The founders acknowledge that global enterprise expansion faces challenges, including stringent local data residency laws, corporate evaluation delays, and the managerial challenge of maintaining high-intensity cultural alignment across international hubs.

Decagon联合创始人Jesse Zhang与Ashwin Sreenivas指出，基础模型实验室不会吞噬应用层软件，Decagon通过将90%的工作负载迁移至微调开源模型攻克亚秒级延迟瓶颈，同时将前沿大模型限定用于元代理构建与质检。他们认为，AI应用企业的核心壁垒在于企业级控制中枢、将现场部署工程经验快速转化为标准化软件的能力，以及通过压降边际成本释放未被满足的服务与商业潜能。 微调开源与前沿模型的双层分工架构 (5:00) Decagon创始人反驳了“采用小模型必然妥协生成质量”的假说，将其称为非此即彼的错误权衡。Ashwin Sreenivas指出，当开源小模型剥离高阶编程或复杂数学等冗余能力，专门针对意图分类、安全护栏和对话路由等微任务进行微调时，其执行特定任务的表现持续优于庞大且通用的前沿基座模型，同时大幅降低运行成本并达成实时语音所需的亚秒级延迟。为此，Decagon成立了内部模型工厂Decagon Labs，依托自建的端到端真实业务评估集持续训练与轮换最新的开源模型。 与此同时，OpenAI与Anthropic等前沿模型被专门用于非结构化与高推理深度的离线元任务。Decagon研发了名为Duet及其Autopilot特性的元代理，负责消化历史对话记录、自动撰写代理操作规程（AOPs）、生成仿真测试套件并向一线模型起草优化方案。此外，为保障输出准确度，Decagon系统在单次对话中执行了大量并行调用与自动化校验，导致单次对话所消耗的Token总量实际上随时间稳步增加。 破除大模型垄断与现场工程产品化 (14:45) 针对2026年流行的“基础模型实验室将吞噬一切软件、应用层仅为薄壳包装”的悲观论调，创始人以企业实际激励机制予以拆解。Jesse Zhang解释称，大型企业内部业务逻辑与流程政策变更频繁，这类程序规范必须通过上下文动态注入，而不可能通过反复微调模型来实现；Decagon的价值在于跨数百家客户沉淀通用的领域合规、测试框架及遗留系统集成层。Ashwin补充表示，即使未来实现人工通用智能（AGI），系统依然需要结构化环境、CRM及数据库来存储状态与调取知识。 面对业内激增的现场部署工程师（FDE）模式，团队警告过度依赖人工将沦落为“美化版IT咨询公司”。Decagon要求将FDE在客户现场踩坑获得的定制工作流沉淀为通用软件特性，推动硬编码逻辑逐步演进为纯文本操作规程（AOPs）和Duet自动化工具。在与竞品Sierra的竞争中，Decagon强调自身的“透明玻璃盒”平台模式，使客户非技术人员也能自主维护工作流，而无需依赖外部FDE黑盒，从而实现更快的上线周期（例如某转投客户单月内便上线7条新客户旅程，而在竞品处一年仅构建3条）。 全能AI门面与水平软件平台优势 (47:55) 随着基础模型指令遵循能力的质变，Decagon从起初狭窄的售后工单处理，逐步拓展为统一承接获客咨询、意向挖掘及主动运营的“AI礼宾员（AI Concierge）”。Ashwin Sreenivas认为，AI代理将极具个性化的高触感专属服务成本从数百美元直接拉低至约10美分，使普罗大众也能享受到原本仅服务于高净值客户的服务体验。在此演变下，CRM等传统记录系统不会消亡，但其图形交互界面的核心地位将让位于AI代理，演变为由智能体通过API频繁读写的底层数据仓库。 在商业架构路径上，Jesse Zhang坚信横向AI平台将最终战胜垂直点状工具，重现历史软件巨头（如Salesforce与Zendesk）跨行业整合的规律。面对银行、航司与电信等高度监管行业，Decagon在市场推广中采取模块化分步部署策略，优先上线一至两个核心场景以迅速促成签约。为确保战略敏捷并倒逼研发迭代，CEO Jesse将约80%的工作时间直接投入到一线销售中。 杰文斯悖论下的劳动重构与增长瓶颈 (74:45) 针对AI引发大规模失业的社会担忧，Ashwin Sreenivas援引杰文斯悖论指出，当客户服务成本下降约30%时，企业往往不会直接裁员60%，而是会发现原本被高昂成本所压抑的潜在服务需求。例如一家每月处理约5万张工单的企业在部署Decagon后，选择将即时帮助窗口布满所有产品页面，甚至向免费用户全面开放实时支持，以极低边际成本换取更高的转化率与用户留存。创始人强调“AI会消灭重复任务，但不会消灭职业”，机械式的跨屏点击被替代后，人工团队将被重新引导至复杂的边缘个案、深度客户关怀以及创收型业务中。 关于初创企业运营，创始人破除了“单人独角兽”的行业迷思，指出AI工具带来的效率跃升只是拉高了市场竞争基准，促使企业开发三倍数量的产品而非裁减核心人员。Decagon目前的扩张瓶颈主要集中在顶尖跨界人才的招募与跨国分支机构的高密度协作文化维护，而非模型上下文长度或推理延迟等技术指标。 Decagon证明了通过自主模型工厂与微调开源架构可以摆脱对前沿API的完全依赖，在低延迟与严控成本下构建企业级壁垒。然而，其横向平台的长期扩张仍面临跨国数据驻留法规的约束、国际属地化竞争对手的阻击，以及能否在全球扩张中持续将高强度现场工程转化为标准化产品的现实考验。

## Background 该内容由知名风险投资机构 a16z 于 2026 年 8 月 3 日发布在 YouTube 平台上。节目由 a16z 合伙人 Sarah Wang 和 Kimberly Tan 主持，邀请了企业级 AI Agent 初创公司 Decagon 的两位联合创始人 Jesse Zhang 与 Ashwin Sreenivas 展开对谈。视频重点探讨了企业级 AI 系统的工程落地、Decagon 将 90% 生产工作流迁移至开源模型的实战经验，以及应用层公司如何在大模型时代立足与构建真实壁垒。 ## TL;DR Decagon 创始人系统反驳了“基础模型实验室将终结所有应用层软件”的宿命论，揭示了通过微调垂直开源小模型实现高准确率、极低延迟与低成本的三重胜利。针对业界对前线部署工程师（FDE）的追捧，团队警示初创公司切忌沦为“披着高科技外衣的外包咨询大篷车”，并演示了如何借助二阶智能体 Duet Autopilot 将定制交付体力活彻底沉淀为通用软件产品。在与 Sierra 等对手的竞争中，Decagon 凭借自主可控的“明箱”产品模式与极细颗粒度的合规部署路线图快速拿下财富百强客户，并推动 Agent 从单一客服向主动式“AI 礼宾”演进。面对 AI 替代人工的恐慌，他们援引真实数据指出客服领域正在经历“杰文斯悖论”，服务成本断崖式下跌激发出海量潜在业务需求，AI 会消灭单调的打卡工单，但人类职业生涯绝不会因此消亡。 ## Atmosphere & style 对谈散发着极度硬核、清醒且直面一线泥潭的实战工程气质，毫无社交网络上常见的浮夸与“奋斗表演”。两位技术出身的年轻创始人兼具工程师的严谨与顶级销售的敏锐，面对投资人关于 AGI 降维打击与商业护城河的尖锐追问应对自如、见解深刻。主持与嘉宾之间的碰撞既有高密度的行业思想交锋，穿插着关于反阿谀 Prompt 和创业心路的幽默调侃，给听众带来一种身处硅谷最前线、既被澎湃技术浪潮冲击又保持绝对理智的深度沉浸感。 ## Bulletin - [01:07](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=67s) Decagon 目前有 90% 的生产工作流已从前沿闭源 API 迁移至开源微调小模型；在特定垂直任务中，小模型凭借更低延迟和更高定制自由度，综合表现反超昂贵的通用大模型。 - [30:08](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1808s) Decagon 构建了内部“模型工厂”Decagon Labs 与二阶 Agent“Duet Autopilot”，通过前沿大模型全自动复盘数百万真实对话、生成 AOP 业务规范及评测集，将前线工程（FDE）的体力劳动完全产品化。 - [37:02](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2222s) 企业级 AI 竞争呈现“明箱（Glass Box）”与“黑箱顾问”路线之争：Decagon 凭借让企业非技术人员自主构建业务旅程的产品化平台，成功替代了重度依赖 FDE 定制交付的 Sierra。 - [01:14:45](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=4485s) 在客户支持领域出现的“杰文斯悖论”证实，AI 大幅降低单次服务成本并未导致企业大规模裁员，反而激活了此前被压制的潜在服务需求，促使客服体系由被动成本中心向主动创收节点转型。 ## Key takeaways - [05:00](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=300s) “智能 vs 成本”是虚假权衡：微调特定开源小模型能够剔除通用智力的冗余干扰，在准确率、低延迟与推理成本三方面同时取得压倒性优势。 - [07:17](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=437s) 开源模型后训练的核心门槛不是通用基准测试，而是企业必须针对自身业务结果从零构建端到端评测体系（Eval）。 - [08:44](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=524s) Decagon Labs 被定位为高敏捷度的“模型工厂”，其使命是压缩从外部前沿开源底座发布到输出针对客服行为微调完成的高可用模型之间的时间差。 - [15:07](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=907s) 破除前沿实验室是“最后初创”的迷思：企业客户的真实业务流程与规则不适合硬编码进权重，应用层的核心壁垒在于捕获、编排业务逻辑的工程软件栈与遗留系统集成。 - [21:21](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1281s) 防范“咨询大篷车”陷阱：前线部署工程师（FDE）的使命是“吞咽痛苦，排出产品”，必须将一线摸索出的非标工作流沉淀为通用核心产品，否则初创公司将沦为无法规模化的现代外包咨询公司。 - [28:15](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1695s) AGI 时代职业依然存在：现代大多数工作都是建立在重重抽象层之上的人为建构，只要人类还需要为彼此提供服务与体验，协作与职业形态就不会消亡。 - [35:22](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2122s) 企业 AI 落地的真实护城河不仅是模型智能，更在于围绕模型构建的护栏、合规评测、多部门协作及海量会话治理等生产级基础设施。 - [44:17](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2657s) 创始人必须将大量时间（如 80%）投入一线销售：在大客户推进中通过“化整为零”战术快速拿下 1-2 个核心场景的首胜，并死守一线与模型能力断层的真实反馈闭环。 - [47:55](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2875s) 从单纯客户支持进化为企业“AI 礼宾（Concierge）”：得益于现代模型指令遵循（Instruction Following）能力的跃迁，AI Agent 能够自如应对非线性的入站销售线索挖掘与主动干预型运营工作流。 - [53:23](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3203s) 大模型普及并未催生“一人独角兽”：效率工具将开发周期缩短至三分之一后，企业选择在同等时间内交付三倍产品以应对行业竞速，导致顶尖工程与商业化人才需求不减反增。 - [01:02:37](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3757s) 横向平台将最终赢得企业级 AI 市场：规模效应与产品深度所积累的通用架构壁垒远高于细分垂直或区域玩家的局部定制价值，历史 SaaS 的整合规律依然适用。 - [01:03:44](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3824s) SaaS 与 CRM 并未消亡而是“退居幕后”：AI 礼宾将高阶专属服务的边际成本压至 10 美分，传统 CRM 则转型为供 Agent 密集 API 读写的无头化“事实真理来源（Source of Truth）”数据库。 - [01:14:45](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=4485s) 客服领域的杰文斯悖论显示，AI 降本激活了全站即时支持等沉睡的潜在服务需求，推动团队从机械应答转向客户成功与增销创收。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=0s) 开篇引言：AI Agent 与大模型范式的交锋 在节目的开篇片段中，Decagon 联合创始人 Jesse Zhang 与 Ashwin Sreenivas，以及 a16z 合伙人 Sarah Wang 和 Kimberly Tan 抛出了一系列引发行业深思的洞见。Jesse 提出，AI Agent 应当成为所有企业的“前台大门”（front door），不论是响应式的客户咨询还是主动式的客户互动，未来都应由 AI 全面接管。然而，2026 年上半年市场上充斥着一种主流叙事——认为 Anthropic 和 OpenAI 等前沿基础模型实验室将成为“最后的创业公司”，它们会凭借通用大模型横扫一切软件生态。 对此，Decagon 团队给出了截然相反的实战判断：即便通用人工智能（AGI）真正实现，智能体依然需要底层架构来存储工作状态、提取企业上下文并执行复杂推理，传统软件系统根本不会以任何实质性方式消亡。更关键的是，虽然前沿模型实验室也推出了各自的小型模型，但企业无法真正对其进行精细控制与定制。如今，Decagon 平台上有 90% 的生产工作流已经迁移并运行在开源模型之上。在垂直特定任务上，经过微调的小型模型不仅成本更低、速度更快，其表现甚至超越了最聪明的顶尖闭源大模型。 --- ### [01:07](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=67s) 走出前沿 API：Decagon 向 90% 开源模型迁移的实战历程 访谈正式开场后，Sarah Wang 提到 Jesse 最近撰写的一篇在行业内广泛传播的长文，该文恰逢开源模型（如 DeepSeek 等开源基座）集中爆发的窗口期，引发了关于“企业在 AI 时代如何掌控自身命运”的大讨论。面对这一话题，Jesse 回顾了 Decagon 从最初依赖闭源 API 到全面拥抱开源的技术演进。在创业初期，团队的首要目标是快速验证产品价值、尽快让系统运转起来，因此直接调用 OpenAI 和 Anthropic 的前沿旗舰模型是顺理成章的选择，两家大模型实验室当时也正处于性能“你追我赶”的白热化竞争中。 随着 Decagon 的业务规模极速扩张，服务的企业客户体量越来越庞大，需要并发应对数以百万计的终端用户。尤其是在 Decagon 推出实时语音智能体（Voice Agent）之后，系统的响应延迟（Latency）成为了决定生死的核心指标。要想让语音对话自然流畅，AI 必须以极快的速度吐出回答，而唯一能够将延迟压缩至极限并让智能体行为完全符合业务预期的手段，就是使用更小尺寸的模型。然而，前沿实验室的小模型如同黑盒，团队无法按需深度改造；加之未经调整的小模型开箱表现往往达不到要求，Decagon 大约在一年多前果断转向开源生态，建立起一支由顶尖研究员组成的实验室团队，对开源小模型进行专项微调。 ```mermaid flowchart TD accTitle: Decagon 模型架构分流图 accDescr: 展示用户请求如何在开源小模型与前沿闭源大模型之间流转分工 subgraph UserInteraction ["终端用户交互层"] Req["客户请求 (文本 / 实时语音)"] end subgraph OpenSourceEngine ["90% 核心工作流：开源微调小模型"] Router["意图识别 / 话题分类"] Security["恶意攻击与违规行为检测"] TaskExec["业务流程执行 (如改签、理赔)"] end subgraph FrontierEngine ["10% 辅助与探索层：前沿闭源大模型"] Autopilot["Duet Autopilot (复盘百万对话/自动优化)"] Research["新型产品探索与开放式复杂推理"] end Req --> Router Router --> Security Security --> TaskExec TaskExec -.-> Autopilot Req -.-> Research ``` - **三维权衡极限**：在工程实践中评估任何模型都可以归结为三个维度——成本（Cost）、智力水平（Intelligence）以及延迟（Latency）。由于单个对话拆解步骤并不需要处理编程或高等数学等通用能力，Decagon 主动收缩对通用智力的冗余要求，从而换取了决定性的延迟优势。 - **开源占比与成效**：目前开源模型已承载 Decagon 90% 的业务流，语音智能体的拟真度、发音节奏与响应体验均实现质的飞跃，同时始终保持了极高的准确率。 --- ### [05:00](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=300s) 破除“智能 vs 成本”的虚假权衡：微调小模型的三重胜利 针对社交媒体上常见的争论——“究竟是多花钱用最聪明的模型，还是牺牲一点智能换取更便宜的小模型”，Ashwin 明确指出这是一个典型的“虚假权衡”（false trade-off）。在真正的落地场景中，微调所谓“没那么聪明”的小模型，并不代表最终交付的效果打折扣；相反，正是因为小模型去除了泛化能力的干扰，在专注于特定业务任务时，其实战表现反而能够彻底超越那些庞大、昂贵的通用前沿大模型。 通过针对性的后训练与微调，Decagon 成功实现了工程上的三重兼得：**在特定任务上准确率更高、推理成本显著降低、响应速度大幅提升**。当被问及 Decagon 是否完全不再需要前沿闭源模型时，Ashwin 解释称前沿模型依然在体系中扮演着极其重要的角色，主要用于各类开放式的辅助与元任务（Auxiliary Tasks）。例如，Decagon 最近推出的产品“Duet Autopilot”（用于优化核心对话智能体的智能体），需要一次性复盘数百万场刚刚发生的真实客诉对话，归纳潜在模式与趋势，并自动生成主模型的多个变体进行 A/B 测试。这种高度复杂、发散式的探索工作，正是前沿顶级模型发挥通用推理长处的绝佳舞台。 --- ### [07:17](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=437s) 企业后训练的技术门槛与开源落地的现实冷思考 面对企业未来是否会普遍具备自行后训练（Post-training）开源模型能力的问题，Jesse 表达了相对谨慎的态度。尽管 Decagon 拥有专职的 Decagon Labs 研究团队并将其深度融入工程文化，但对绝大多数传统企业而言，微调模型绝非“换个开源模型跑一下”那么简单。实现高质量后训练的核心难点不仅在于清洗和处理私有数据，更在于建立专属于自身业务场景的评估体系（Evals）。通用的公开基准测试在垂直企业任务面前毫无参考价值，企业必须从零构建属于自己的 Benchmark。 Jesse 分析指出，当某项业务场景已经彻底固化、进入规模化生产阶段，且智能体的行为模式与系统架构完全明朗时，迁移至开源模型在技术和经济上是绝对占优的，既能压缩延迟，又能附带享受大幅削减推理成本的红利。然而，对于探索性、实验性质的新场景，调用前沿模型的 API 依然是性价比最高、工程负担最轻的方式。正因如此，虽然业内对开源的讨论热度空前，但目前许多企业在实际新增工作流中，开源推理的即时占比甚至可能因为大量处于 PoC（概念验证）阶段的新项目涌入而暂时被稀释。 ### [08:44](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=524s) 开源模型的企业落地与 Decagon Labs “模型工厂” 在探索企业 AI 落地的路径时，团队通常会先依赖前沿大模型（Frontier Models）快速搭建 PoC 并验证新场景的可行性。然而，一旦某些场景通过验证、企业决定正式大规模上线推向生产环境，转向开源模型的动力就会变得极其强烈——开源方案在推理延迟和运行成本上具备压倒性优势。不过，这一迁移在大型企业内部往往推进得较为缓慢：企业虽有强烈意愿，但由于模型风险治理（Model Risk Governance）、严格的安全审查以及组织惯性的存在，一次通常只能推进有限的几个场景。 ```mermaid flowchart TD accTitle: Decagon Labs 模型工厂运作流程 accDescr: 展示从开源前沿模型发布到生产环境微调部署的循环迭代机制 subgraph Ingestion ["模型引入与评估"] A["前沿开源底座发布"] --> B["识别高频重复任务"] end subgraph Factory ["Decagon Labs 模型工厂"] B --> C["针对客服行为微调"] C --> D["端到端业务评测"] D --> E["淘汰过时旧模型"] end subgraph Production ["生产部署"] D --> F["多模型协同调度"] F --> G["最终客户对话交付"] end ``` 这种动态环境直接催生了 Decagon 的内部架构创新。模型生态并非“微调一组开源模型后便可高枕无忧两三年”，前沿开源能力的迭代极为迅速。随着模型原生能力的增强，原本需要复杂工程处理的场景可能会被全新底座轻松覆盖，从而涌现出新的自动化切入点。Decagon 发现团队必须处于持续训练新模型、同时果断废弃陈旧模型的循环中。 为此，Decagon Labs 被定位为一个标准化的“模型工厂”（Model Factory）。其核心使命是极度压缩从外部新模型发布到输出针对特定任务微调完毕的高可用模型之间的时间差。这种敏捷工业化微调的能力，成为应对底层技术剧烈变动的核心支撑。 --- ### [10:50](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=650s) 自研还是外购：以客户结果为核心的评测与工具链 面对当前市场上繁杂的 AI 开发者生态（例如各类强化学习 RL 即服务、第三方评估平台等），Decagon 建立了一套清晰的自研与采购边界准则：**任何与具体业务场景高度耦合的核心环节，必须坚决自研；通用性高的基础环节，则积极采购外部成熟工具**。 团队在实践中发现，开源模型的微调如果仅仅依赖学术界或通用基础设施常见的指标（如在单一隔离任务上的 Loss 曲线下降），往往无法反映真实业务表现。在复杂的生产环境中，单一模型并非孤立运行，而是需要与其他多个模型协同工作。Decagon 的评测体系（Eval）直接锚定在最终交付给客户的业务结果上（Customer Outcomes），评估整个系统的端到端表现。由于这种协同机制与自身场景高度绑定，Decagon 选择自主研发专属的训练与评测基础设施。 - **坚决自研**：端到端系统级评测工具、多模型协同调度框架、客服垂直领域的行为微调管线。 - **采购外部服务**：通用数据标注服务、训练数据集多样性度量等跨行业标准化工具，以此换取最快的投产速度。 - **核心北极星指标**：“我们唯一在意的，就是如何以最快速度将最好的模型推向生产环境。” --- ### [12:25](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=745s) 走出 Tokenomics 焦虑：以性能与延迟为核心的增长逻辑 针对目前技术社区对“Token 经济学”（Tokenomics）和推理成本的高频讨论，Decagon 展现了截然不同的务实态度。在实际生产中，驱动他们决策的核心要素始终是**延迟（Latency）与准确率（Accuracy）**，成本反而是顺带获得的副产品。他们惊喜地发现，在垂直任务上微调小体积开源模型打破了常规的商业权衡，实现了性能、速度与低成本的兼得，无需为了省钱而牺牲质量。 对于一家高速成长的初创企业而言，客户并不在乎后台调用耗费了多少成本或多少 Token，他们衡量的唯一交付单位是“对话解决质量”。事实上，随着系统架构演进，Decagon 在单次对话中消耗的 Token 数量反而在增加——为了保证极致的可靠性，系统并行触发了更多模型调用来进行校验、审核与护栏拦截。 > “社交网络上关于 Tokenomics 的激烈争论，本质上困扰的是那些依然 100% 依赖商业前沿模型 API 的公司；当你已经跨过鸿沟，掌握了任务解构与开源模型快速微调部署的能力时，成本问题瞬间就不再那么紧迫了。” --- ### [15:07](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=907s) 破除“大模型实验室是最后初创”迷思：垂直应用的真实护城河 针对科技创投界一度盛行的“前沿大模型实验室（OpenAI、Anthropic 等）将成为最后的初创公司，应用层只是包裹着人力实施的外包薄壳 UI”这一论调，Decagon 站在企业级客户的实际诉求上给出了有力反驳。这种将基础设施与应用对立的二元视角忽略了企业落地当中的纵深复杂度。 面对 Fortune 100 级别的超大型企业，自研或是直接找基础模型实验室往往面临巨大的机会成本障碍。大众对于微调存在严重误解，误以为微调是为了让模型“学习特定客户的私有数据与业务流程”。实际上，Decagon 所做的大量微调，是在打磨**客服任务本身的底层行为与判断模式**（如准确理解意图、在对话流中精准选择分支主题）。 企业客户真正独特的业务流程与内部规章，并不适合通过微调硬编码进权重，而是应当在推理阶段通过上下文（In-context）动态提供。对于财富 100 强企业而言，将内部宝贵的顶级 AI 研究资源消耗在调优基础客服行为模型上完全不符合 ROI；而对于像 Decagon 这样聚合了成百上千家客户通用诉求的应用平台，在任务层做深做透才是其难以被基础模型侵蚀的坚固壁垒。 ### [17:43](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1063s) 应用层的护城河：业务逻辑与垂直深耕 在企业应用落地过程中，如果每次修改业务流程都需要工程师去重写底层逻辑，系统根本无法维系。一个常见的典型场景是：企业上线了 AI Agent，第二天审查对话记录时发现有三处逻辑需要调整。如果每一次迭代都依赖工程团队手动修改代码，这种持续不断的工程负担将迅速拖垮项目。Jesse Zhang 与 Ashwin Sreenivas 强调，当客户场景需要一个更广泛的平台时，他们更愿意与应用层软件公司合作。企业采购的核心价值，在于 Decagon 在基础模型之上构建的专用微调能力和软件技术栈——这套用于捕获并编排业务逻辑的系统，与底层模型本身并没有直接关系。 ```mermaid flowchart TD accTitle: 业务逻辑与模型层的解耦架构 accDescr: 展示现实复杂业务逻辑如何通过应用层系统与底层模型解耦运行 subgraph AppLayer ["应用层软件栈（Decagon 核心壁垒）"] BizLogic["业务逻辑编排与规则捕获<br/>（如航班取消、多人批量改签等复杂场景）"] OpsTooling["运营与管控工具栈<br/>（自动化 QA、会话审查、实验/AB 测试、合规监控）"] SysIntegrations["底层系统深度集成<br/>（CRM、内部数据库、工单系统）"] end subgraph ModelLayer ["模型与推理层"] Finetuned["垂直领域微调小模型<br/>（高性价比、低延迟、针对性强化）"] Frontier["通用前沿基础大模型<br/>（泛化能力强，处理边缘情况）"] end BizLogic --> OpsTooling OpsTooling --> SysIntegrations SysIntegrations --> Finetuned SysIntegrations --> Frontier ``` 例如，当一位乘客打进客服电话，说因为航班被取消而需要同时为同行三人改签，如何优雅地处理这种现实生活中的复杂突发情况，纯粹是必须固化在应用系统中的业务逻辑，而非基础大模型与生俱来的能力。虽然前沿模型实验室（Frontier AI Labs）也会尝试向应用层扩展并提供一定的通用能力，但往往停留在非常泛化的 Agent 层面。而 Decagon 坚守的核心假设是：在诸如企业级客服这样的核心垂直赛道中，必须向下深潜——提供极其深入的系统集成能力、捕获业务逻辑的机制、会话审查与 QA 测试工具，以及供企业合规团队持续监控系统的完整管理套件。 - 模型实验室与应用层软件正在双向渗透（Convergence）：实验室构建应用来提升企业用量并证明 ROI；应用层公司则通过自建微调模型来压榨极致的延迟、性能并大幅降低推理成本。 - 软件公司不会因 AGI 到来而灭绝：人类本身即是一种通用智能（AGI），但人类依然需要使用数据库存放信息、使用 CRM 跟踪业务。哪怕未来全部由智能体接管工作，它们同样需要底层软件来存储上下文与调用数据。 - 长期来看，部分纯粹用于给人工操作界面打工的 SaaS 公司可能会遭遇严峻挑战，但垂直深耕的应用层企业很可能会演变成针对特定垂直领域的专业“模型实验室（Vertical Labs）”。 --- ### [21:21](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1281s) 前线部署陷阱：产品化 vs 咨询皮卡车 近期硅谷与 Tech Twitter（科技推特）上重新掀起了一股鼓吹“前线部署工程师（Forward Deployed Engineer，简称 FDE）”的狂热风潮，很多初创企业都在大规模招募 FDE 甚至宣称要回到定制化服务模式。Ashwin 对此提出了更尖锐的观点：盲目依赖 FDE 实际上是一个极其危险的“陷阱”。在五年前构建传统 SaaS 产品时，工作流早已被行业充分探索，工程师很清楚用户在设计软件或 CRM 中想达成什么目的；但现在的 AI 场景中，没有任何人此前真正使用过这些前沿技术，客户和软件公司同样一头雾水。在早期阶段，FDE 的唯一价值在于“一边看着火车往哪开，一边顺着方向给客户铺设铁轨”，即亲自下场与客户深度绑定、学习并摸索全新工作流。 然而，长期的终局绝不能停留在做定制服务。如果一家 AI 创业团队摸清了工作流之后，无法将其抽象沉淀为标准产品，那他们实际上只是在做一辆“披着高科技外衣的咨询大篷车（Glorified Consulting Truck）”。Decagon 在三年前切入 AI 客服赛道时就面临双重偏见：起初有人嘲讽他们只是一个简单的“GPT 套壳（GPT wrapper）”；随后当他们决定不只做纯软件平台、而是深入客户一线直接落地自动化时，行业还未形成“AI Agent”或“Agent 产品经理（Agent PM）”的标准化认知。 ```mermaid flowchart LR accTitle: 前线部署反馈循环与产品化飞轮 accDescr: 展示 FDE 与 Agent PM 从客户痛点到沉淀核心产品功能的正向反馈飞轮 subgraph FieldWork ["一线现场沉浸"] Customer["大型企业客户"] FDE["FDE / Agent PM<br/>（深入业务流、挖掘破损点）"] Customer <--> FDE end subgraph ProductLoop ["产品沉淀闭环"] CoreProduct["核心通用产品架构<br/>（通用抽象，非单点定制）"] ProcessEngine["企业迁移流程规范化<br/>（AI 组织转型指南与工具）"] end subgraph ValueRealization ["规模化红利"] NextCustomers["后续数十家企业客户<br/>（直接开箱即用，零边际适配成本）"] end FDE -->|"吞咽痛苦，排出产品"| CoreProduct FDE --> ProcessEngine CoreProduct --> NextCustomers ProcessEngine --> NextCustomers ``` - Decagon 的 FDE 工作模式：所有 FDE 本质上都属于核心产品研发团队。他们在企业现场发现现有产品缺失的能力后，输出的绝非仅服务于单一客户的临时定制脚本，而是直接合并入核心产品库中，使得“随后的 10 个客户一旦提出类似诉求，就能零成本免费直接享受该功能”。 - Agent PM 的职责重心：深入探查企业现场的系统破损点（Broken），研究如何让 Agent 真正安全可靠地在复杂企业环境中投入生产，并将推动超大型企业向 AI 转型过程中涉及的组织变更与流程演进沉淀为标准工具与方法论。 - 对 Palantir 模式的解毒：Ashwin 曾担任 Palantir 的部署战略专家（Deployment Strategist），他援引 Palantir 联合创始人兼 CTO Shyam Sankar 的名言指出——真正的前线部署工程师职责是“吞咽痛苦，排出产品（Eat pain and excrete product）”。 - 行业错觉的破灭：极少有企业能复制 Palantir 的商业奇迹（起手即签下天价大单以支撑庞大的定制化工程开销）。打着超前线部署旗号、声称能承接企业任意 AI 需求的初创公司，如果迟迟无法完成向可扩展软件产品的转型，最终都将不可避免地撞上商业天花板。 ### [26:44](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1604s) 拒绝成为“现代埃森哲”：用产品驱动而非咨询外包实现规模化 Jesse 明确指出了当前许多 AI 初创公司正在陷入的误区：外界很多团队打着热门 AI 软件公司的旗号，本质上却只是在雇佣大量全职员工（FTE）做定制化交付，不知不觉做成了“现代版埃森哲（Accenture）”。如果创始人打一开始就想做外包咨询，那无可厚非；但如果将咨询交付当成了核心产品战略，业务就彻底无法规模化（scale）。 从创立第一天起，Decagon 就坚定地将自己定位为一家“以产品为核心”（product-led）的公司。尽管团队规模不断扩大，但公司的目标绝不是只要客户抛出一个随机需求，就组建团队去为每个具体场景量身定做孤立的外包代码。每一个前线需求，最终都必须抽象、沉淀到通用的核心产品中去。 与纯粹的产品驱动相对照，Jesse 也补充道，Decagon 同时也是一家“销售导向”（sales-led）的公司。团队不是闭门造车凭空想象产品功能，而是通过前线部署工程师（Forward Deployed Engineers, FDE）深入客户一线。FDE 的核心职责不是给客户当“随叫随到的外包小工”去随意拼凑临时用例——虽然短期内满足客户的所有散装诉求能更快拿下大单，但长期来看将陷入难以维系的泥潭。FDE 的真正任务，是将销售和交付一线获得的真实痛点全面回流，快速迭代出业内最顶尖、通用性最强的核心产品。 --- ### [28:15](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1695s) AGI 时代还有职业吗？Decagon 的现实主义视角 a16z 的投资人抛出了一个生动的内部插曲：近期她曾劝说团队中的一位成员不要离开 a16z 去顶尖的前沿模型实验室（Frontier Lab），并试图以“长期职业生涯前景”挽留对方。然而对方的回答让她哑口无言：“我们很快就会实现 AGI 了，人类长期来看根本不需要什么职业生涯。”带着这份被“AGI 药丸”（AGI-pilled）震撼后的困惑，投资人向每天在企业泥潭中实操交付的 Decagon 询问对 AGI 落地与职业终局的真实看法。 Jesse 听后笑称，他百分之百确信“AGI 之后人类依然会有职业生涯”。他的逻辑非常朴素却犀利： - 现实社会中，绝大多数现代工作（除了极少数基础基建、农牧种植等实物生产）本质上都是“凭空发明出来的”（made up）。 - 大多数岗位都是建立在重重抽象层（layers of abstraction）之上的社会分工。即便它们是人为建构的，但对人与人之间的协作依然极具价值。 - AGI 的到来无疑会深刻重塑工作形态，但只要人类还需要为其他人类提供服务和创造体验，工作和职业就永远不会彻底消失，人们绝不会只是无所事事地坐在那里。 --- ### [30:08](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1808s) Duet 与 Duet Autopilot：“制造 Agent 的 Agent” 回归到产品本身，Jesse 讲述了产品迭代中最具冲击力的“恍然大悟时刻”（Aha moment）——内部称之为 **Duet** 的系统进化。在 Decagon 创业早期，团队倾尽全力打造的是直接面向企业客户的“第一代核心 Agent”，用以自动化处理客服、提升满意度并削减运营成本。但在幕后，要让这个 Agent 真正稳定跑通，团队需要付出巨大的繁重劳动： 1. **编写 AOP（Agent Operating Procedures，Agent 操作规范）**：定义专属的流程规范，手把手教会 AI 如何做判断和做动作； 2. **打通底层系统与 API**：写出适配不同企业复杂系统的集成工具； 3. **构建完备的测试与仿真环境**：模拟各种边界情况以防 Agent 在真实对话中翻车； 4. **人工监视线上会话**：Agent 投产后，工程师不得不肉眼通读上千条真实对话来排查问题。 ```mermaid flowchart TD accTitle: Duet 自动化工作流示意图 accDescr: 展示 Duet 如何从原始资料生成流程并全自动进行仿真测试与会话监控闭环 subgraph Input["输入资产"] A["历史客服对话记录"] B["企业内部知识库与文档"] end subgraph DuetSystem["Duet / Duet Autopilot"] C["全自动挖掘并编写 AOP 规范"] D["自动构建测试用例与仿真环境"] E["生产环境会话质量巡检与归因"] F["主动生成优化补丁与改进建议"] end subgraph Output["交付产物"] G["高可靠生产级 Agent"] end A --> C B --> C C --> D D --> G G --> E E --> F F --> C ``` 为了彻底摆脱人工瓶颈，Decagon 构建了 **Duet**——一个“制造 Agent 的 Agent”。Duet 是一个体积更大、推理更深、耗时略长，但极其智能的二阶 Agent： - 用户只需要扔给它一堆客服录音文本和几篇企业文档，Duet 就能自动梳理出最优的业务流程并编写出成套的 AOP； - 它会自动配套编写好针对这些操作流程的测试集与仿真用例； - 当核心 Agent 上线后，Duet 会日夜不休地自动审查成千上万条对话，一旦发现薄弱环节，它不仅会主动预警（例如：“我审查了最近 1,000 场对话，发现我们在某一特定退款问题上表现很差”），还会顺手起草出改进该流程的具体补丁。 Jesse 感叹，在公司创立初期这完全是天方夜谭；唯有随着 Anthropic 和 OpenAI 等机构的强推理模型（Reasoning Models）相继涌现，这种级别的通用编排能力才得以变为现实。基座模型虽然从未针对 Decagon 的私有 AOP 语法进行过定向训练，却展现出了惊人的泛化推理与任务执行能力。 --- ### [33:20](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2000s) 飞轮闭环：将前线工程（FDE）的体力活彻底产品化 Ashwin 进一步阐明了 Decagon 内部产品演进的根本逻辑：**所有伟大的产品功能，都脱胎于前线部署工程师（FDE）做过的“体力活”**。Decagon 的产品研发并不是在真空中构想出来的，而是一场由前线痛点驱动的产品化革命： - **AOP 的诞生**：最开始，业务流程必须由 FDE 逐行写死在业务代码中；后来团队意识到写代码交付成本太高，于是发明了用纯自然语言编写的 AOP 规范，将代码层面的定制转化为了产品化协议。 - **Duet 的诞生**：有了 AOP 之后，FDE 仍然需要耗费海量时间手动编写这些流程，于是团队打造了能自动阅读文档并编写 AOP 的 Duet。 - **Duet Autopilot 的诞生**：Duet 解决了冷启动配置问题，但线上监控、复盘和微调仍需 FDE 长期跟进，于是团队再次将“对话质检与改进提议”这套运维动作完全产品化为 Duet Autopilot。 Decagon 内部衡量产品与组织效率的终极准则就是：前线团队（工程师或客户支持人员）今天在干什么繁琐的重复劳动，明天就必须把它彻底产品化，将团队从重度参与中彻底解放出来。 --- ### [34:45](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2085s) 尖锐追问：当基座模型全知全能时，Decagon 的护城河何在？ 既然 Decagon 自己也惊叹于基座模型性能的几何级飞跃，投资人直接抛出了一个最露骨、最具挑战性的核心问题： > “如果长期来看我们真的实现了 AGI，基座模型实验室的模型能力远远超出我们今天的想象，连各种复杂编排都能轻易搞定，那么 Decagon 最终的护城河究竟是什么？十年之后，Decagon 凭什么还能继续存在于市场上？” 这直接触及了所有 AI Agent 平台面临的“上帝之问”——在通用人工智能的降维打击下，垂直应用层软件赖以生存的底牌到底在哪里。Jesse 与 Ashwin 随之从短期现实与长期价值壁垒的角度展开了正面回应。 ### [35:22](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2122s) 企业级 AI 部署的护城河：不仅是模型能力，而是软件与工作流基础设施 Ashwin Sreenivas 深入探讨了企业部署 AI 的核心瓶颈。当前基础模型的能力其实远超它们在企业内部实际被应用的深度。很多人的误区在于，以为只要给模型授予企业所有数据的访问权限，它就能“搞定一切”，但这在生产实践中是完全不切实际的。即便假设模型永远不犯错误，要让其在企业中平稳落地，仍需围绕它构建庞大而严密的基础设施与配套软件： ```mermaid flowchart TD accTitle: 企业级 AI 落地基础设施架构 accDescr: 展示从基础模型到企业实际生产可用所需的护城河层级，包括合规风控、协同配置、测试审计与洞察分析。 subgraph EnterpriseInfra["企业级配套软件与治理层"] A["护栏与权限约束<br/>（防止灾难性违规）"] --> B["跨部门多人协同平台<br/>（业务专家定义行为）"] B --> C["合规与风险评测体系<br/>（满足监管合规测试）"] C --> D["数百万对话分析管道<br/>（为其他业务提取洞察）"] end Model["基础大模型"] --> EnterpriseInfra Legacy["企业传统遗留系统"] --> EnterpriseInfra EnterpriseInfra --> Production["生产环境稳定上线运转"] ``` 要实现安全部署，企业必须能够： - 严格限定模型的行动边界，杜绝任何“灾难性错误”发生的可能； - 允许多个业务部门的数百名非技术专家协同配置模型行为； - 建立详尽的合规与风险测试框架，确保不踩监管红线； - 持续监控数百万条真实对话，向其他业务团队反哺有价值的洞察，并与老旧复杂的遗留系统实现对接。 Ashwin 强调，未来几年这种围绕模型打造的工程与软件基础设施将是 AI 落地的关键所在。至于三五年后这些能力是否会被能够动态自我构建的 Agent 彻底商品化，目前尚无定论。 --- ### [37:02](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2222s) 双雄争霸：Decagon 与 Sierra 的“明箱”对“黑箱”路线之争 投资人 Sarah Wang 指出，企业软件领域的传统销售周期极为漫长，通常耗时一到两年，但 Decagon 却展现出了惊人的成交速度，在与 Sierra 等资金雄厚的对手竞争中，将大客户争夺演变成了一场双雄对决。她好奇两位极度技术背景的创始人，是如何在大型企业采购中脱颖而出并迅速拿下大额订单的。 Jesse Zhang 坦言他们非常尊重 Sierra 及其优秀的团队，但近期有一家大型企业客户直接停用 Sierra 并全面迁移到了 Decagon。客户迁移的核心原因在于交付模式的根本分歧： - **Sierra 的“黑箱”顾问模式**：主要高度依赖前向部署工程师（FDEs），客户所有的新增旅程（Journey）设计、对话分析或细微调整都必须排队通过 FDE 才能完成。随着时间推移，FDE 人力被分配至其他项目，客户陷入了严重的“交付拖延”（drag）。在一整年时间里，该客户在 Sierra 平台上仅上线了 3 个业务旅程。 - **Decagon 的“明箱”（Glass Box）产品化模式**：虽然 Decagon 也派遣 FDE 提供协助，但 FDE 的目标是赋能客户自己使用核心产品。平台具备高可见度与低门槛，让企业内部的非技术人员能够轻松看懂对话走向、自主调控并快速迭代。 该客户切换至 Decagon 后，仅用了一个月左右的时间，就自主搭建并上线了 7 条全新的业务旅程。这种自主可控性与迭代速度，成为 Decagon 赢得头部大客户的关键分水岭。 --- ### [40:32](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2432s) 创始人销售基因与“从第一天到100%全量上线”的确定性交付 谈到为何能快速完成企业级大单，Jesse 和 Ashwin 透露，他们之前从未做过 Enterprise 销售，但两人本能地对销售过程感到兴奋。由于当前 AI 赛道极为火热，销售团队不需要说服客户“为什么要买 AI”，核心任务变成了“证明自己的方案是最佳选择”。因此，深入理解客户组织的政治结构、共情客户的真正顾虑，成为了攻坚重点。 Decagon 在早期就坚持“销售驱动（Sales-led）”的理念，让一线的市场反馈反哺产品开发。他们组建了一支战斗力极强的早期销售团队，其中包括不少非传统销售背景的人才（甚至包括名校常春藤联盟的运动员背景）。这种坚韧的文化让公司自上而下对销售执行力保持高度一致。 Ashwin 补充道，促成大单快速关闭的另一关键因素在于“将企业部署流程彻底产品化”： - **拒绝抛砖不管**：传统模式要么交付很慢，要么甩一套软件给客户让他们自己摸索一年；而在面对强监管行业（如金融服务业）时，客户最大的焦虑不仅是“这东西管不管用”，更是“这东西在我们复杂的审批架构下到底能不能上线”。 - **细颗粒度全流程推演**：Decagon 在第一次拜访客户时，就能拿出极其细致的端到端推进路线图。他们会明确拆解：客户所处阶段的模型风险管理审查（Model Risk Process）怎么过、测试流程如何走、小规模试点如何开展、线上遇到偶发问题如何拦截修补并确保永不再犯，直到实现 100% 全量上线。 这种能够为大型企业梳理上线全流程、提供极强交付确定性的能力，往往是多数技术型初创公司在向大型企业销售时所忽视的致命盲区。 ### [44:17](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2657s) 创始人为何要花80%的时间做销售：大客户落地与棋局博弈 Sarah Wang 谈到，很多企业决策者选择 Decagon 的一个核心原因，是对两位创始人的押注。在这个每周甚至每天都在变化的快速演进市场中，客户深信 Decagon 的创始团队动作最快，能够审时度势下好每一步关键棋子。当被问及创始人究竟投入了多少时间在销售上时，Jesse Zhang 透露自己大概将 80% 的时间都花在销售上。 Jesse 解释道，客户非常希望直接见到创始人，但更关键的是创始人需要在现场扮演推动团队和合作方加速前进的核心力量。目前 Decagon 的客户包括全球大型银行、航空公司以及电信运营商，这些庞然大物的采购流程极其冗长。为了打破僵局，创始人必须深度介入，采用“化整为零（piecemeal）”的战术：绝不在初期就试图一次性覆盖所有业务场景和业务面，而是精准挑选一到两个最顶级的核心用例快速拿下首胜。这种产品化、流程化与组织架构上的巧妙设计，只能由能够通盘负责全局战略与产品迭代的创始人来决定，而不能单靠销售代表去琢磨。 ```mermaid flowchart TD accTitle: 创始人驱动的大客户销售策略 accDescr: 创始人通过快速首胜策略化解大型企业采购周期长的瓶颈并获取一线模型反馈 subgraph Strategy["大客户落地策略"] A["大型企业客户（银行、航司、电信）"] --> B["传统全面推进：流程冗长壁垒高"] B --> C["创始人战略拆解：化整为零"] C --> D["锁定 1-2 个核心场景快速拿下一期胜利"] end subgraph FeedbackLoop["一线反馈机制"] D --> E["高频直面客户与潜在买家"] E --> F["捕获前沿模型能力与需求落差"] F --> G["驱动产品敏捷迭代"] end ``` - 销售团队的主要职责是维护组织内部关系、建立企业内部拥护者（Champions）并推进商业流程，而创始人则负责动态调整合作路径与产品切入点。 - 创始人常驻销售一线还为了死守关键反馈闭环（Feedback Loop）：随着基础模型能力日新月异，客户经常会看到令人兴奋的新功能并提问“为什么你们还没做这个”，高频交流能确保公司立刻察觉盲区并快速补齐。 ### [47:55](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2875s) 从纯客服到全能 AI 礼宾（Concierge）：指令遵循能力的质变 在创业之初，Decagon 的所有落地场景几乎全集中在客户支持（Customer Support）。这不仅因为它是早期客户最痛的痛点，也是当时模型能力的物理边界所致。如今，这一界限已被彻底打破，Decagon 正在拓展为企业的“AI 礼宾（AI Concierge）”。 客户开始意识到，既然 Decagon 的模型已经通过客服深入掌握了产品特性、系统能力以及品牌沟通调性，完全没有必要在其他环节另起炉灶。客户主动提出让 Decagon 接手“入站销售（Inbound Sales）”——负责解答售前疑问、进行需求挖掘与潜客资格审查（Discovery & Lead Qualification），若遇到大单再无缝流转给相应的大客户销售代表；还有客户利用其进行“主动式运营工作流（Operational Workflows）”，一旦检测到账户出现异常便自主发起外联沟通。Ashwin Sreenivas 指出，Decagon 从一开始就不是单纯针对客服开发 Agent，而是打造一个“能够精准执行业务流程的通用 Agent”；无论是回答支持工单、做销售线索筛选还是处理内部运营，底层逻辑都是在遵循业务流程。 模型之所以能够承接如此复杂的拓展，最核心的底层技术突破在于**模型遵循指令的能力（Instruction Following）发生了质的跃迁**： | 对比维度 | 几年前的基础模型 | 现代先进模型 | |:--- |:--- |:--- | | **指令输入方式** | 极其严苛、狭窄的细节引导，不可有任何偏差 | 宽泛的指导方针与宏观目标，容错与理解能力强 | | **对话走向与形态** | 机械执行既定脚本，单一线性分支 | 能够自如应对交错迂回（Bob and Weave）的开放式对话 | | **业务应用场景** | 仅适用于路径高度固定的工单型客户支持 | 能够主导非线性的入站销售线索挖掘与主动干预型运营流程 | | **缺失信息处理** | 极易陷入死循环或幻觉错误 | 具备类似人类的常识与同理心，能够自主补全上下文空白 | 关于长期产品路线图，Jesse 坦言在如今飞速演进的 AI 时代，制定一份刻板严格的 12 个月路线图并不现实。如果一个方向极其明确，团队会立刻直接构建出来，而不是排入长线日程。Decagon 的终极愿景非常清晰：打造企业与品牌的“统一大门（Front Door）”，无论是被动响应还是主动交互，客户的所有接触点都应由具备上下文感知的 AI Agent 承载。 ### [51:58](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3118s) 真正的增长瓶颈并非模型能力，而是人才与审美决策 当主持人问及目前最大的瓶颈是否在于持久记忆（Persistent Memory）或模型能力缺陷时，两位创始人不假思索且半开玩笑地给出了唯一的答案：“招人（Hiring）”。 虽然团队消耗了海量的 Token，Token 账单高得惊人，但目前最紧缺的依然是顶尖人才。面对“为什么不用 AI Agent 来干自己的活”的追问，Ashwin 坦言，现阶段的 AI Agent 确实能够外包很多具体的代码与执行步骤，但它们还远远无法胜任“决策什么该做、什么不该做”的产品判断力，更缺乏衡量“这件作品到底做好了没有”的设计审美（Taste）。能够做顶层架构取舍、定义完成度的人性判断，依然是 AI 无法替代的核心壁垒。 ### [53:23](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3203s) 模型提效下的招聘悖论：为何“一人独角兽”并未出现 对于业内热议的“大模型能力跃升将催生一人独角兽公司”这一论调，Decagon 创始人给出了完全相反的观察。最直接的反例便是那些 AI 编程初创公司本身——作为这批模型最专业、最深度的使用者，他们反而都在疯狂招人。究其原因，核心在于生产工具的普惠性：既然竞争对手同样拥有这些工具并能借助它们开发出更多功能，那么为了保持竞争力，自己也必须加速产出。如果一个团队原本的路线图需要一年完成，而借助 AI 工具可以在三分之一的时间内搞定，团队绝不会选择就此停招，而是会以此推导出“我们现在能在同样的时间里做三倍多的东西”。最终每家公司的算盘都是相同的：大家一边以前所未有的速度招募更多人才，一边以更高的吞吐量交付产品。 ```mermaid flowchart TD accTitle: AI 提效下的杰文斯悖论逻辑 accDescr: 展示 AI 提效后企业为何不仅没有缩减编制，反而加速招聘以扩大交付规模。 subgraph Efficiency ["生产效率提升"] A["引入 AI 编程与工作流工具"] --> B["路线图交付时间缩短 2/3"] end subgraph CompetitiveDynamics ["竞争与决策"] B --> C{"面对提效的战略选择"} C -->|"消极假设：缩减编制"| D["停止招聘 / 维持原产能"] C -->|"现实决策：交付扩大 3 倍"| E["开发 3 倍产品 / 加速迭代"] E --> F["同行竞争加剧<br/>竞品同步提速"] end subgraph Outcome ["最终组织形态"] F --> G["疯狂招募工程与商业化人才"] G --> H["组织交付规模全面膨胀"] end ``` 从技术演进角度来看，尽管 Decagon 依然密切关注端到端语音大模型（voice-to-voice models）的研究进展，以及出厂即具备更强通用能力的小模型，但就当下企业的商业成败而言，技术模型的微小差异早已不是主要瓶颈，最关键的挑战在于“你建立这家公司的速度究竟有多快”。 - **“一人独角兽”的证伪**：拥有最高 AI 利用率的初创公司（如 AI 编程工具团队）在招聘市场上最为激进，并未因代码自动生成而收缩团队规模。 - **交付预期的膨胀**：效率工具将研发周期缩减至原先的三分之一后，企业非但没有缩编，反而将开发目标扩大了三倍。 - **技术与商业的重心转移**：虽然端到端语音延迟与小型模型性能仍有待底层研究突破，但当前 AI 应用公司的核心胜负手在于组织扩张与商业化推进的执行力。 --- ### [55:06](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3306s) 告别“奋斗表演”：无边界协作与极高密度的办公室文化 社交网络 X 上近年来充斥着针对初创公司“奋斗表演”（grind slop）的嘲讽，Decagon 虽以每周在办公室工作六到七天而闻名，但两位创始人明确表示从未在网络上发过任何推销刻苦人设的内容。团队之所以全身心投入，并非为了“内卷”本身，而是出于一种单纯的认知：眼下正处于人生的黄金期，大家都希望将自身的才华与潜力变现，不愿白白浪费。公司的核心始终是“打造优秀产品并在这个赛道中胜出”，高强度的工作节奏只是追求这一终极目标自然产生的结果。公司从不强制员工周末必须到岗，也不监控工时，全员聚集在办公室内纯粹是为了“最大化沟通效率”。当身边的同事全都抱有高度的野心并全力以赴时，高强度的工作就会变成一种常态。 Ashwin 强调，Decagon 的运作模式本质上是一项“团队运动”（team sport）。各部门之间几乎没有硬性壁垒：研发工程师经常会直接出现在早期的销售电话会议中；销售人员会亲自上手排查产品底层代码的问题；APM 团队更是纵贯整个业务光谱。当跨职能团队高度紧密地协作时，面对面的办公室环境变得不可或缺——所有人聚在一起碰撞思路，共同攻坚同一个极其明确的目标，无论是在大客户签约前赶工完成定制功能，还是确保全新模块如期上线。这种“所有人同舟共济推进交付”的氛围，让高压工作本身也充满了成就感与乐趣。 - **拒绝形式主义**：团队从未在社交媒体上参与“奋斗表演”（grind slop）营销，高工时源于业务需求与自我驱动，而非行政强制。 - **打破职能隔阂**：工程师下场跑销售、销售人员协助调试产品 Bug、产品运营贯穿前后端，呈现极强的跨职能混合协作。 - **办公室的真正价值**：全员到岗的意义在于消除沟通损耗，让不同部门为了特定交付成果快速同步信息、联合决策。 --- ### [58:25](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3505s) 走向全球化：多中心扩张下的文化复制与海外客户拉力 伴随着业务规模爆发，Decagon 迅速在纽约、伦敦以及澳大利亚开设了新办公室。对于如何从旧金山总部向跨国站点辐射公司文化，创始人坦言这并非一个完全被解决的课题，每次公司跨入新阶段都必须建立新的沟通与高问责机制。在公司规模不足百人时，团队依靠扁平的日常接触即可维系认同；但当团队快速膨胀时，愿景与文化必须被清晰传达。正如 a16z 联合创始人 Ben Horowitz 此前给他们的建议，企业文化必须高度建立在“行动导向”（action-oriented）之上，绝不能流于表面空洞的口号（fluffy stuff）。 为了避免海外团队与核心价值脱节，Decagon 建立了一套沉浸式机制：所有新入职的海外员工都会被送到旧金山总部生活两周，彻底浸润在最初的“文化原汤”之中；而在开拓全新区域办公室时，成熟枢纽的核心老员工会被外派进驻几个月，直到新据点成长到能够自发孕育并稳固原有文化为止。 与此同时，前 VMware 首席执行官 Raghu Raghuram 去年作为投资人加入后，重点协助 Decagon 搭建跨国扩张能力。AI 初创公司在成立极早期就被国际客户强烈拉动（customer pull），这种扩张速度远超传统 SaaS。其背后有两大关键驱动力： | 驱动要素 | 传统软件时代的壁垒 | AI 时代的变化与现状 | |:--- |:--- |:--- | | **企业高层驱动力** | 需漫长周期自下而上验证，海外企业决策慢 | 全球各类公司的高管与董事会都已试用过 ChatGPT，自上而下承受推进 AI 落地的迫切压力；编码助手与客户服务是无可争议的首选切入点。 | | **产品本地化门槛** | 软件往往受限于语言支持，跨语言适配需大量工程重构 | 大语言模型在跨语言理解与生成上天生具备泛化能力，多语言应用适配成本被断崖式拉低。 | 在享受海外需求红利的同时，Decagon 也保持着战略克制，避免战线拉得过长。团队只在已有自然客户基础的成熟市场进行重度资源投入，因为跨国扩张不仅涉及本地人员招聘，还必须严肃应对数据本地化合规（data residency）以及熟悉本土环境的本地竞争对手所带来的复杂挑战。 - **入职浸润机制**：所有新员工在入职初期均须前往旧金山总部受训数周，建立对核心文化的体感。 - **老兵拓荒模式**：在新设站点前期，从旧金山或成熟中心派驻骨干驻留数月，以防止海外分支文化异化。 - **出海拉力的源头**：董事会迫切的 AI 落地诉求（以客服场景为主）与大模型自带的多语言优势，共同助推了国际化进程。 - **重度投资的准则**：仅在通过本土自然转化跑出早期订单的市场设立实体办公室，谨慎平衡数据驻留合规与本地竞品防御。 ### [01:02:37](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3757s) 横向扩张与垂直整合：企业级 AI 赛道的终局之争 对于大模型应用赛道是否会给特定区域或细分垂直领域的本土竞争者留下生存空间，Decagon 的两位联合创始人给出了非常明确的判断。尽管不同垂直领域、不同市场层级或特定地理区域总会涌现出寻找生态位（niche）的玩家，但从长期来看，软件行业不可避免地会走向整合。Decagon 之所以选择打造通用、横向（horizontal）的产品架构，是因为他们坚信在自身所处的企业级客服与工作流自动化领域，最终的胜出者必然是横向平台，历史上诸如 Salesforce 和 Zendesk 的崛起正是这一规律的有力佐证。 在企业级市场中，一家纯垂直化的解决方案很难单凭特定行业的特性建立起持久壁垒。横向产品通过规模化积累所带来的稳健架构、深度功能体系以及广泛适配性，其价值远远超过了那些单纯针对垂直行业定制的边缘功能。当然，横向平台在发展成熟后也会逐步向下延展、补充行业特化模块。因此，无论从行业垂直维度还是整体市场竞争维度来看，最终都将不可逆转地走向大整合。 - **横向平台优势**：规模效应与产品深度赋予的底层通用能力，远高于纯垂直场景的定制价值。 - **历史镜鉴**：Salesforce、Zendesk 等 SaaS 巨头的成功印证了企业交互与记录系统天然倾向于横向统一。 --- ### [01:03:44](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3824s) AI 礼宾与 CRM 的未来：SaaS 未死，只是退居数据幕后 随着 AI 礼宾（AI Concierge）逐渐演化为企业与终端客户交互的核心前台界面，传统 CRM 作为关键核心记录系统（System of Record）的地位是否会受到颠覆？联合创始人兼总裁 Ashwin Sreenivas 认为，这并不是一个非此即彼的替代关系，AI 礼宾的本质是将高端的“礼宾服务普及化”。在传统商业模式下，只有年消费高达 10 万美元的超级 VIP 客户才能享受到极具个性化的专属服务——商家甚至愿意“为你关门清场歇业”，完全掌握客户的个人偏好与需求；而对于一个只消费 10 美元的普通客户，并非商家不愿提供同等水准的关怀，而是经济模型（unit economics）根本无法支撑。AI Agent 将这类高品质服务的边际成本直接拉低到了 10 美分级别，彻底释放了这种商业需求。 即使由 AI Agent 全面接管客户沟通，CRM 也绝对不会消亡。就像人类专属礼宾人员必须在 CRM 中记录客户档案一样，AI Agent 同样需要把交互沉淀的上下文和事实数据存放在底层系统中。首席执行官 Jesse Zhang 进一步补充，CRM 在未来可能会迎来极具潜力的发展形态：它们退化为纯粹的“事实真理来源”（Source of Truth）数据库。过去用户对 CRM 的核心抱怨往往集中在臃肿繁琐的图形交互界面（GUI）上，而在 Agentic 时代，人类甚至不再需要亲自点击界面，而是由 AI Agent 频繁通过 API 接口直接调用与写入数据。对于 Decagon 自身而言，团队对重新制造轮子去开发一套 CRM 毫无兴趣，他们的战略重心将始终牢牢钉死在具备最高附加值的 Agent 逻辑层。 ```mermaid flowchart LR accTitle: AI 礼宾与系统层级架构 accDescr: 展示终端客户通过 AI 礼宾层交互并最终沉淀数据到底层 CRM 记录系统的双层架构 subgraph UserInteraction["交互前台"] Customer["终端消费者"] end subgraph AgenticLayer["Decagon 核心层"] Agent["AI 礼宾 Agent<br/>（高交互、低成本）"] end subgraph SystemOfRecord["数据持久层"] CRM["底层 CRM 记录系统<br/>（无头数据库 / Source of Truth）"] end Customer <-->|"极度个性化服务<br/>（成本降至 10 美分）"| Agent Agent <-->|"无头化 API 读写<br/>（免去繁琐 GUI 操作）"| CRM ``` - **单客服务成本剧降**：将原本针对高净值用户的专属人工礼宾体验，从单次极高的人力成本降至约 10 美分，实现商业可行性。 - **软件形态演进**：SaaS 并未消亡，CRM 从人工操作的复杂交互软件演变为面向 Agent 密集调用的核心事实数据库。 - **产品边界选择**：Decagon 明确表示对自建 CRM 毫无欲望，专注于深耕 Agentic Layer。 --- ### [01:06:56](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=4016s) “数字分身”与反阿谀 Prompt：创始人用 AI 破除决策孤独 在讨论如何利用 AI 赋能日常工作时，Ashwin 分享了自己构建个人专属 Agent 的深度实验。他观察到，当前大语言模型虽然极其聪明且善于头脑风暴，但在实际商业应用中最大的瓶颈在于“商业上下文”（Business Context）的缺失——如果每次对话都要向 AI 费力灌输当前的业务限制、战略目标或组织背景，效率就会大打折扣。为此，Ashwin 专门为自己打造了一个常态化“在背后凝视”的 Agent，持续捕捉公司的招聘现状、待招岗位、跟进中的销售大单以及当下面临的痛点挑战。当需要面试新候选人或复盘交易时，该 Agent 能自动调取以往两名相似候选人的能力缺陷进行对比推理，提醒管理团队避免招聘技能重合的人才，或者警示当前某笔交易正走入之前未及早验证的陷阱中。Sarah 幽默地调侃这听起来就像是 Ashwin 为自己克隆了一个“数字 Jesse”，Ashwin 也笑称如果能把需要海量上下文的决策工作外包给模型，自己就能“更快让自己下岗”。 两位创始人回忆起曾经各自作为独立创始人（Solo Founder）的艰辛经历：独自创业时没有可以碰撞思路的搭档，得出正确结论的速度极其缓慢；而拥有联合创始人则能迅速通过口头交流完成推演。现在的 AI 在某种程度上已经能够扮演这个思维碰撞者的角色，前提是要打破早期模型常见的“阿谀奉承”（sycophants）倾向。Ashwin 提到硅谷知名投资人 Marc Andreessen 曾公开过一份专门用于 Claude 的提示词指令，核心要求模型“极其尖锐地反对我、直接指出我的谬误”。Ashwin 尝试后体验极佳，甚至把这套提示词推荐给了妻子，结果妻子使用一天后向他大倒苦水，抱怨“Claude 一整天都对我极其刻薄，一直在粗暴地否定我”，以至于不得不把它关掉，引发现场一阵欢笑。 - **上下文获取瓶颈**：大模型泛化智力极高，但缺乏特定企业运作的约束、历史经验与即时背景信息。 - **决策辅助落地**：通过自动化 Agent 沉淀招聘与交易全貌，实现横向比对候选人互补性与复发性商业风险。 - **提示词实验**：通过设定对抗性 Prompt 消除模型的迎合倾向，将其转化为客观且具备批判视角的合伙人式思维工具。 --- ### [01:10:18](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=4218s) 跨越“AI 废话”风波：从 LinkedIn 阵地到 X 舆论风向标 随着近期关于 Airbnb 创始人 Brian Chesky 陷入“AI 生成废话”（AI slop）公关风波的讨论持续发酵，主持人将话题引向了创始人的个人声量构建与内容创作策略。Jesse 此前在社交平台上撰写的多篇行业深度观点文章，由于精准击中了行业正在激烈探讨的时代精神（zeitgeist）与关键认知盲区，凭借独到且差异化的视角引发了广泛共鸣。主持人随即询问创始人是否在写作中重度依赖 AI，并提出了一个更底层的元问题：X（原 Twitter）及其社区情绪对企业发展到底有多重要？ Jesse 坦言，在 Decagon 创业早期，团队的核心精力主要聚焦于 LinkedIn。当时的基本逻辑非常务实：B2B 企业级软件的目标客户和企业决策者普遍活跃在 LinkedIn 上，很少有大客户会因为在 Twitter 上看到一条推文而直接签下一份企业级合同。然而，随着公司不断演进，他们对 X 的价值定位产生了新的认知与反思。在科技与 AI 行业中，X 实际上构成了整个行业思想演进的“公共时间线”（timeline），代表了行业顶层认知与舆论趋势的最前线阵地。 ### [01:11:41](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=4301s) 社交媒体策略：X 与 LinkedIn 的分化及生态影响力 Jesse 与 Ashwin 探讨了初创企业在不同社交媒体平台上的定位逻辑。Jesse 强调，如果在 X（Twitter）上只是纯粹推销自家公司，绝对不会获得任何关注和传播。X 的独特之处在于它拥有一个“所有行业核心人物都在刷的全局时间线”，就像是在某种程度上控制着行业思想的聚焦点。Jesse 引用了 Jeremy Giffon 在 Patrick O'Shaughnessy 的播客节目中提出的观点：过去的社会顶级地位象征是亿万富翁，他们如同“祭司阶层”（priest class）；但现在的顶级亿万富翁们反而渴望成为 X 上的影响力博主（X influencers），因为这些人真正掌握着设定全球公共议题与思维走向的实权。 因此，Jesse 表示自己发帖时很少直接推销 Decagon 本身，而是分享对行业大趋势、技术发展及事件的洞察与思考。尽管利用 AI 辅助头脑风暴能激发灵感，但内容必须由创始人亲自撰写。团队在实践中发现 LinkedIn 与 X 的运作逻辑存在鲜明割裂，不能一套内容通发： ```mermaid flowchart TD accTitle: 社交媒体传播策略对比 accDescr: 对比 Decagon 在 LinkedIn 和 X 平台上的定位与衍生影响力路径。 subgraph LI["LinkedIn 策略"] LI_A["经典企业动态"] --> LI_B["产品更新与融资公告"] LI_B --> LI_C["触达企业客户与传统受众"] end subgraph X_Platform["X 平台策略"] X_A["行业思考与趋势见解"] --> X_B["占据全局时间线心智"] X_B --> X_C["辐射 AI 研究员与顶级开发者"] X_B --> X_D["衍生二级效应：播客讨论与主流媒体报道"] end ``` - **平台功能定位对比**：LinkedIn 适用于发布经典企业动态、产品更新、官宣融资等官方内容；X 则是通过输出行业思考，将自己嵌入到核心受众的头脑中。 - **CIO 与大企业客户触达路径**：针对“企业级 CIO 是否会看 X”的疑问，Jesse 指出大企业决策者可能不会整天刷推特，但 X 具备巨大的“二级涟漪效应”。当创始人观点在 X 产生讨论后，会引发 *All-In Podcast* 等主流科技播客的讨论，并吸引主流媒体记者的采访（例如 Ashwin 最近就因为开源讨论接受了《纽约时报》的采访），这些二级传播渠道最终都会精准触达企业决策层。 --- ### [01:14:45](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=4485s) 自动化与就业：客服领域的杰文斯悖论 讨论切入到全行业热议的核心敏感议题——AI 对人类工作岗位的冲击。主持人指出，客服（Customer Support）可能是第一个被 AI 全流程端到端自动化（end-to-end）接管的场景，这与从一开始就作为“结对编程”（pair programming）辅助工具的代码生成大不相同。这引发了一个尖锐的问题：究竟人们是会因此大批失业，还是会被 AI 赋能并得到职业提升（upleveling）？ Jesse 和 Ashwin 从企业客户的真实业务数据出发打破了这一恐慌论调。他们发现，对于绝大多数企业来说，客服领域并不是“需求固定”的零和博弈，而是长期处于“需求严重大于供给”的压制状态。当 AI 让单次客服成本下降 30% 时，大多数企业的第一反应不是解雇 60% 的员工，而是利用这一成本优势去承接原本被忽视的海量潜在需求： - **早期客户案例**：在两年前（约 2022 年底至 2023 年初），某早期客户每月在原有入口下只能处理约 50,000 张工单。接入 Decagon 降低处理成本后，企业发现用户实际上积压了大量未解决的问题。于是他们将原本隐藏在深层帮助面板中的客服入口扩展到了“全站每一个页面”，并在用户极易卡壳的环节高亮提示，甚至面向“全量免费用户”开放即时支持，而不再局限于付费用户。 - **杰文斯悖论（Jevons Paradox）**：降低单次支持的服务成本，反而刺激了全业务支持总需求的爆炸式爆发，使沉睡的“潜在需求”（latent demand）被彻底激活。 --- ### [01:17:48](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=4668s) 杀死岗位，而非杀死职业：从成本中心转向创收 Jesse 总结道：“AI 会杀死具体的工作岗位，但不会杀死人类的职业生涯（AI will kill jobs, but not careers）。”目前客服人员处理的很多工作本质上极其单调无聊——反复接听电话、机械地点击屏幕并提供标准答案。这类超高频且重复性的低价值事务理应由 AI 接管；与此同时，让客户满意、提供个性化关怀的潜在途径是无限的，人类员工将因此转型到更高阶、更具体温与创造力的工作中。 谈及跨国业务流程外包（BPO）的实际影响时，Jesse 阐明了三种不同的企业现状： 1. **直接替代**：部分企业确实缩减了对传统 BPO 的依赖甚至停止采购。 2. **支撑快速扩张（平抑运营成本曲线）**：许多高速增长的业务不希望客服团队的人力规模随着业务量呈 1:1 的线性膨胀，借助 Decagon 可以将团队规模保持在平缓水平，避免盲目堆砌人工。 3. **向创收职能转型（Revenue-generating）**：企业保留客服员工，但将他们的精力从机械的售后答疑引导至客户成功、关系维护与增销促成等能直接带来收入的场景。 Jesse 强调，Decagon 自身的产品演进路径也遵从这一逻辑：AI 赋能的第一步是先从“削减成本”的降本场景切入，因为这是最容易量化且切入点明确的刚需；但随着系统与模型能力日趋成熟，AI 驱动的对话界面接下来将全面渗透到“创收型”（revenue-generating）的商业场景中，为企业创造更深层次的增量价值。 ## Notable quotes > [00:00](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=0s) 在垂直特定任务上，经过微调的小型模型不仅成本更低、速度更快，其表现甚至超越了最聪明的顶尖闭源大模型。 — Jesse Zhang > [10:50](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=650s) 我们唯一在意的，就是如何以最快速度将最好的模型推向生产环境。 — Ashwin Sreenivas > [12:25](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=745s) 社交网络上关于 Tokenomics 的激烈争论，本质上困扰的是那些依然 100% 依赖商业前沿模型 API 的公司；当你已经跨过鸿沟，掌握了任务解构与开源模型快速微调部署的能力时，成本问题瞬间就不再那么紧迫了。 — Jesse Zhang > [21:21](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1281s) 吞咽痛苦，排出产品（Eat pain and excrete product） — Shyam Sankar > [28:15](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=1695s) 我们很快就会实现 AGI 了，人类长期来看根本不需要什么职业生涯。 > [34:45](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=2085s) 如果长期来看我们真的实现了 AGI，基座模型实验室的模型能力远远超出我们今天的想象，连各种复杂编排都能轻易搞定，那么 Decagon 最终的护城河究竟是什么？十年之后，Decagon 凭什么还能继续存在于市场上？ — Sarah Wang > [51:58](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=3118s) 招人（Hiring） — Jesse Zhang > [01:17:48](https://www.youtube.com/watch?v=cO1f2wOxSH4&t=4668s) AI 会杀死具体的工作岗位，但不会杀死人类的职业生涯（AI will kill jobs, but not careers）。 — Jesse Zhang ## Mentioned Decagon, Jesse Zhang, Ashwin Sreenivas, Sarah Wang, Kimberly Tan, a16z, Anthropic, OpenAI, DeepSeek, Duet Autopilot, Decagon Labs, Palantir, Shyam Sankar, Sierra, Salesforce, Zendesk, Ben Horowitz, Raghu Raghuram, VMware, Marc Andreessen, Brian Chesky, Airbnb, Jeremy Giffon, Patrick O'Shaughnessy, All-In Podcast, 纽约时报 (The New York Times) ## Video description Sarah Wang and Kimberly Tan are joined by Jesse Zhang and Ashwin Sreenivas, co-founders of Decagon, to discuss the evolution of enterprise AI agents, why the company increasingly relies on open-source models, and how it is helping some of the world’s largest companies deploy AI in production. Decagon has become one of the fastest-growing AI companies by building agents that automate customer support, sales, and operational workflows. Jesse, Decagon’s CEO, and Ashwin, its president, explain how the company is building enterprise AI at scale. They unpack why Decagon moved most of its inference to open-source models, how latency, evaluation, and fine-tuning shape production AI systems, and why enterprise AI requires far more than simply plugging into frontier models. The conversation also explores forward-deployed engineering, enterprise sales, AI’s impact on jobs, and why application companies will continue to thrive alongside the foundation model labs. Timestamps: 00:00 - Intro 01:07 - Decagon's Journey from Frontier APIs to 90% Open-Source 05:00 - The False Trade-off: Why Fine-Tuned Small Models Win 09:26 - Decagon Labs as a Model Factory 15:07 - Are Frontier AI Labs the Last Startups? 21:21 - The Forward Deployed Trap: Product vs Consulting Truck 28:36 - Duet Autopilot: The Agent That Builds the Agent 37:02 - Winning Enterprise: Glass Box vs Black Box (and Beating Sierra) 47:55 - From Customer Support to AI Concierge 01:14:45 - Will AI Kill Jobs? Jevons Paradox in Customer Support Resources: Follow Jesse Zhang on X: https://x.com/thejessezhang Follow Ashwin Sreenivas on X: https://x.com/AshwinSreenivas Follow Sarah Wang on X: https://x.com/sarahdingwang Follow Kimberly Tan on X: https://x.com/kimberlywtan Stay Updated: If you enjoyed this episode, be sure to like, subscribe, and share with your friends! Find a16z on X: https://twitter.com/a16z Find a16z on LinkedIn: https://www.linkedin.com/company/a16z Listen to the a16z Podcast on Spotify: https://open.spotify.com/show/5bC65RDvs3oxnLyqqvkUYX Listen to the a16z Podcast on Apple Podcasts: https://podcasts.apple.com/us/podcast/a16z-podcast/id842818711 Follow our host: https://x.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see http://a16z.com/disclosures. [Source](https://www.youtube.com/watch?v=cO1f2wOxSH4)

[0:00] Jesse Zhang: 在垂直特定任务上，经过微调的小型模型不仅成本更低、速度更快，其表现甚至超越了最聪明的顶尖闭源大模型。 [10:50] Ashwin Sreenivas: 我们唯一在意的，就是如何以最快速度将最好的模型推向生产环境。 [12:25] Jesse Zhang: 社交网络上关于 Tokenomics 的激烈争论，本质上困扰的是那些依然 100% 依赖商业前沿模型 API 的公司；当你已经跨过鸿沟，掌握了任务解构与开源模型快速微调部署的能力时，成本问题瞬间就不再那么紧迫了。 [21:21] Shyam Sankar: 吞咽痛苦，排出产品（Eat pain and excrete product） [28:15] 我们很快就会实现 AGI 了，人类长期来看根本不需要什么职业生涯。 [34:45] Sarah Wang: 如果长期来看我们真的实现了 AGI，基座模型实验室的模型能力远远超出我们今天的想象，连各种复杂编排都能轻易搞定，那么 Decagon 最终的护城河究竟是什么？十年之后，Decagon 凭什么还能继续存在于市场上？ [51:58] Jesse Zhang: 招人（Hiring） [77:48] Jesse Zhang: AI 会杀死具体的工作岗位，但不会杀死人类的职业生涯（AI will kill jobs, but not careers）。

[5:00] Ashwin Sreenivas: When we fine-tune smaller, dumber models, it's that they're just not as general purpose, but on the specific task we want them to do, they actually outperform the large, smart, state-of-the-art models. [21:21] Shyam Sankar: Forward-deployed engineers eat pain and excrete product. [28:16] a16z colleague: We'll have AGI, we don't need careers in the long term. [28:40] Jesse Zhang: most of our jobs are kind of made up to begin with [30:10] Jesse Zhang: It's like a second agent that's much bigger, much slower, but its job is to do all the tasks I just described... it just feels very magical because you can just literally tell it like, 'Hey, I've nothing built yet so far, but here's a bunch of transcripts I have and here's some documentation. Go figure out the best way to do all these procedures.' [37:02] Sarah Wang: When they worked with Sierra it was mostly FDEs and it just felt like a black box... over the course of the year they maybe built out, I think they said three. Within basically a month they spun up like seven new journeys on Decagon. [66:56] Jesse Zhang's wife: Claude was being so mean to me all day. [77:48] Ashwin Sreenivas: AI will kill jobs, but not careers.

[0:00] An AI agent should just be the front [0:01] door of your business. And every [0:03] interaction, whether it's like reactive [0:05] or proactive with a customer, should be [0:06] handled by AI. [0:07] >> This narrative dominated the first half [0:09] of 2026, which is that anthropic open [0:12] AAI. They're the last startups. They're [0:14] going to take over everything. [0:15] >> Even once you have AGI, agents are going [0:18] to need somewhere to store work and pull [0:20] information from and reason about [0:22] things. I don't think software as a [0:24] whole in any meaningful way is going [0:26] away. Unfortunately, the Frontier Labs, [0:28] they do have small models, but you can't [0:30] really control them in the way that you [0:31] want. So, today 90% of our workflow is [0:34] on open source [0:35] >> on the specific task we want them to do. [0:37] They actually outperform the large smart [0:40] state-of-the-art model. [0:42] >> The thing that we built was not an agent [0:44] that does customer support well, but [0:45] rather an agent that follows business [0:48] process. Well, [0:49] >> instead of us having to write these [0:51] AOPs, do just does all of that. Let's [0:53] say like we hit AGI and the models can [0:55] do all sorts of things we can't even [0:56] imagine [music] today. What's Decagon's [0:58] emote and like why does Decagon like 10 [1:00] years from now still have a right to [1:01] exist? [1:07] >> Hey guys, welcome back to the studio. [1:09] >> Thanks for having us. [1:10] >> Yeah, good to see you. [1:11] >> Thank you for being here. Before we get [1:13] into customer support, um I actually [1:16] wanted to widen out a bit. Um, and uh, [1:19] Jesse, I'm going to actually um, mention [1:22] a piece that you wrote recently that [1:24] went pretty viral because it's right in [1:26] the middle of the zeitgeist of [1:28] conversation right now on open source [1:30] versus closed source models. then [1:32] thinking machines um Kimk 3 you know [1:34] some of some very interesting open [1:36] source models came out sort of right [1:38] after um and there's this really [1:39] interesting debate going on around [1:42] what does it mean to own your destiny [1:45] when it comes to AI especially in the [1:47] enterprise um and what does that [1:49] evolution look like by use case um so [1:52] actually since that's a pretty live [1:53] topic right now why don't we start there [1:55] >> sounds good um so I'm gonna talk about [1:56] our journey first uh just to make it [1:58] very concrete for people so when we [2:00] started the any uh the goal was just to [2:02] get something working, right? So if when [2:03] you get something when you're the goal [2:04] is to get something working, of course [2:06] you're just going to use the frontier [2:07] models because you want to get something [2:10] out there and have actually deliver [2:12] value. And so we were using opening [2:13] anthropic at that time they were kind of [2:15] like one uping each other in terms of [2:16] how the how the models performed. And [2:18] then at some point as we got to larger [2:20] scale and we started working with larger [2:22] and larger companies and they had you [2:23] know millions of customers and then we [2:26] we also have uh we also launched our [2:28] voice agent right so a big factor became [2:30] latency so it wasn't just like can you [2:32] deliver good responses you have to [2:34] deliver them really fast and uh the only [2:37] way to get latency down um but also kind [2:40] of you make our agent operate the way we [2:42] want it to is to use smaller models and [2:45] when [clears throat] you want to go to [2:46] smaller models unfortunately the the [2:48] Frontier labs, they do have small [2:50] models, but you you can't really control [2:51] them in the way the way that you want [2:54] and most small models out of the box are [2:55] not going to be good enough at the task [2:57] that we want them to do. So, you have to [2:59] fine-tune them, you have to change them. [3:00] And so, that's when we started looking [3:02] at open source. So, this was about year [3:04] plus ago. And um it worked really well [3:09] because if you think about it in the [3:10] agent, right? So, in our agent, our [3:12] agent's job is to have conversations. [3:14] So, it needs to do a lot of things at [3:16] once, right? And like one one the first [3:18] step it might do is like hm what topic [3:20] is this person talking about or and [3:21] something else it might do is oh is this [3:23] person a bad actor that's coming in and [3:25] trying to mess things up. There's all [3:27] these like tasks it has to do. Each [3:29] individual task doesn't need all of the [3:31] intelligence of a big model. So you know [3:34] all the frontier models are obviously [3:35] very smart but they can do a bunch of [3:36] different things. Like they can do math [3:38] they can do coding. Like you just need [3:40] them to be good at that one task. And so [3:42] that's why you can use a smaller model [3:44] and if you fine-tune it to be really [3:45] good at that task and can be just as [3:47] good or better than the big models, [3:48] right? So that was that was step one for [3:50] us. You know, about a year ago, we were [3:52] like, okay, let's start using these open [3:53] source models. Uh we we we took the [3:55] small ones and then um you know, that's [3:57] why we have now a uh a research team and [4:00] it's a very expensive team, but it's we [4:02] we have it because, you know, we need [4:04] people that are really good at taking [4:05] these open source models and and tuning [4:07] them and and so on. So today 90% of our [4:09] workflow is on open source and um you [4:13] know again the main reason was for [4:15] latency to really optimize our voice [4:16] agents and um I think we've just over [4:19] the last year we've seen tremendous [4:20] improvement in like how how it sounds [4:22] how it feels and but still also like [4:24] keeping the accuracy high um and then [4:26] the remaining 10% of course we're still [4:27] using the uh the closed source models [4:29] and the frontier models for a lot of you [4:30] know new new projects or new products [4:34] and uh I think that's just where the [4:35] industry is moving to. So if you kind of [4:37] were to generalize this every model you [4:40] can kind of evaluate along three [4:42] dimensions. It's you know cost [4:44] intelligence and latency and depending [4:47] on what you need you want to kind of be [4:49] at the limit of those three and [4:50] sometimes you can trade off right so in [4:52] our case we knew that we actually pull [4:54] back on intelligence because we all had [4:56] to do was that one task but now we get [4:58] these latency advantages. I want to push [5:00] a tiny bit on that point actually [5:02] because um often times you know when you [5:05] see these debates being had on Twitter [5:07] the the trade-off tends to be oh do we [5:10] want uh you know the smartest model that [5:13] is very expensive or can we like dumb it [5:16] down a little bit and get it cheaper. I [5:18] actually think that is a false [5:19] trade-off, [5:20] >> right? Because what we've seen in [5:22] practice is even if you have a quote [5:24] dumber model, you can get it, and we've [5:27] seen this in practice, you can get it to [5:28] higher performance on that specific [5:31] task. So when we fine-tune smaller, [5:34] dumber models, it's that they're just [5:37] not as general purpose, but on the [5:39] specific task we want them to do, they [5:41] actually outperform the large, smart, [5:44] state-of-the-art models, [5:45] >> right? So we end up getting all three [5:47] things. It is better at the toss. It is [5:50] cheaper and it is faster. [5:51] >> And so do you feel like today like you [5:53] need the most Frontier models for really [5:55] anything at Decagon because your [5:57] performance is very good already. So [5:59] >> we we do and we often need them we often [6:02] end up needing them for auxiliary tasks, [6:04] right? Where when you have uh when you [6:07] sort of have auxiliary models to our [6:09] sort of primary conversational flow, [6:11] right? you have an agent and it's [6:13] helping a customer with their rebooking [6:16] or it's helping them with a process in [6:19] healthcare then these are like [6:21] well-defined pots. So we have smart bos [6:24] models to do that but we've for instance [6:27] recently launched do autopilot right [6:29] which is our agent that improves the [6:31] core conversational agent. Now, for [6:33] something like autopilot, it is doing a [6:35] very complicated job, right? It's [6:37] saying, I'm going to go and review a [6:39] million conversations that just [6:40] happened. I'm going to try and find [6:41] trends. I'm going to create variants of [6:43] the primary model and see which of those [6:46] variants does better. So, now this is a [6:47] much more broad open-ended exploratory [6:50] task. So, we think for jobs like that, [6:53] frontier models that are very smart, [6:55] that can try out a lot of things make a [6:56] lot of sense. H do you think that um I [7:00] mean you guys obviously and you [7:02] referenced it um Jesse that you have a [7:04] research team right you guys launched [7:05] Decagon Labs but even before the formal [7:07] launch it's always been a part of your [7:09] culture um do you think that enterprises [7:11] will get there as well on post training [7:14] open source models oh okay interesting [7:16] what's the timeline [7:17] >> yeah I think I think they'll get there [7:19] but it'll probably take longer than [7:20] people think because you know even with [7:22] our team fine-tuning these models is [7:25] non-trivial it's not just like oh you [7:27] And it's like all right, we made the [7:28] decision to use open source. Like let's [7:30] just use open source. Like you have to [7:31] get the data. And then more importantly, [7:33] you have to like have good eval. Um and [7:35] if you think about our evals, right, our [7:36] evals are very specific to us. You can't [7:38] just like use some public eval set and [7:40] like that that just does the job. It's [7:42] like we're testing it on our task and so [7:44] we have to generate our own benchmarks [7:46] and evals. Uh but I think the point is [7:48] that um at a certain point it's strictly [7:53] better to use open source models because [7:55] when your use case is solidified and [7:58] you're in production at scale and you're [8:00] pretty sure this is the the sort of [8:02] shape of the agent then there's no [8:03] reason not to use open source because [8:05] you you get these latency benefits and [8:07] at the same time you get the cost [8:08] benefits. I mean again we didn't do [8:10] these for cost benefits but that's like [8:11] a nice side effect right [8:12] >> and once you're there it's like why why [8:14] use Frontier for that? But for [8:16] everything that's new and sort of [8:18] experimental or you're as Asha was [8:20] saying what or like kind of these [8:21] products where you really need the [8:23] intelligence you're still going to use [8:24] frontier models and it's just so much [8:26] easier to use frontier models you know [8:28] they're worrying about the infra you [8:29] just like like they just um you just use [8:31] the APIs and I think that's why in [8:34] enterprises right now even though [8:36] there's there's a lot of hype for open [8:37] source the sort of share of of open [8:39] source inference is actually going down [8:41] right now because people are spinning up [8:42] all these new use cases and if you're [8:44] spinning up new use caseas is of course [8:45] you're going to use the frontier models [8:46] until until they're working. [8:48] >> Yeah. [8:48] >> But of those use cases, you know, some [8:50] might die off, but like some might like [8:52] the enterprises are like, "Okay, great. [8:53] We want to keep shipping this and like [8:54] roll it out." [8:55] >> Once it's at that point, they're heavily [8:57] incentivized to use open source. It's [8:58] way cheaper and faster. [9:00] >> At that point, they'll maybe they can do [9:02] it in house or maybe they'll need help [9:03] uh from people to to help them fine-tune [9:06] it. But that that will eventually [9:08] happen. I just think it'll be kind of [9:09] slow. Even right now in our experience [9:11] >> like enterprises have a lot of desire to [9:13] move but they can only do so many use [9:15] cases at once. You know they there is [9:17] inertia there and they have to you have [9:20] to go through all the you know model [9:21] risk governance and all the security [9:22] things and so um I think it'll take time [9:25] but it will get there. [9:26] >> Yeah. the the the other reason I think [9:27] it makes a lot of sense for uh [9:30] enterprises to kind of build their you [9:32] know cool bundle of labs is that the [9:36] shape of these models is changing [9:38] constantly right we don't just build our [9:40] set of open source models and then you [9:42] know it's done we can move on to our [9:44] next thing and maybe we'll revisit this [9:46] in two years [9:46] >> you often need to train new models all [9:50] the time [9:50] >> because [9:52] >> as the frontier changes as the [9:54] capability of the models changes [9:57] you come up with new use cases for them. [9:59] You find new places where you're like, [10:01] "Oh, this task seems to be getting [10:03] repeated a lot because now I have this [10:05] totally new like, you know, frontier [10:07] model or open source model that now has [10:09] this capability that they didn't have [10:10] before, right? So we find ourselves [10:13] constantly training net new models and [10:15] deprecating old ones that are no longer [10:17] relevant because you know maybe the [10:19] frontier has advanced a lot. The open [10:21] source frontier has advanced a lot and [10:22] you know the model out of the box can do [10:24] a lot of things that it couldn't do [10:25] before. So we [10:27] >> because the model landscape is changing [10:28] so quickly. [10:30] >> Uh Dagon Labs is in a way a model [10:33] factory of sorts, right? We really built [10:36] it to um like uh compress the time [10:40] between new model coming out and you [10:43] know useful fine-tuned to our task model [10:45] kind of popping out the other end. [10:47] >> Yeah. [10:48] >> Just because happens all the time. [10:50] >> How do you guys think about what to [10:53] inhouse from a talent perspective versus [10:56] there's also a pretty broad ecosystem [10:58] right now that is you know could be RL [11:01] as a service eval etc. like how do you [11:04] guys what's your framework for hey this [11:06] is mission critical and we need to do [11:08] this best versus yes it'd be great to [11:11] you know outsource this. Um you know in [11:14] practice we've seen that so many things [11:17] uh relevant to model training are so [11:19] tightly coupled to the use case that we [11:22] have [11:23] >> right that we find that we end up [11:25] needing to build a lot of tooling [11:26] internally when we have um open-source [11:29] uh open source models that we want to [11:30] fine-tune we find that if we can clearly [11:34] tailor our eval to customer outcomes [11:38] it's way better than just looking at [11:39] like loss curves over time right we're [11:41] not just saying oh can I do this one [11:43] specific task. We're measuring the [11:45] entire system end to end. We're not just [11:47] saying is this model good at this task. [11:48] We're saying is this model working in [11:50] concert with all these other models [11:52] delivering the end customer outcome that [11:54] we care about. And because that is so [11:57] unique to our setup, we've found that in [11:59] practice, we've needed to build a lot of [12:02] uh a lot of the infrastructure that we [12:04] need to train these models and evaluate [12:05] them. Now, for other things like getting [12:08] labeled data and measuring the diversity [12:10] of our data sets, we're like, "Yep, [12:12] these are tasks that are common across [12:13] fossil companies." In which case, we [12:15] want to buy things from other vendors [12:17] because that'll just help us get those [12:19] models to production faster. Ultimately, [12:21] the only thing that we care about is how [12:22] can we get the best model to production [12:24] as quickly as we can. [12:25] >> And so, it sounds like, you know, [12:26] there's a lot of talk right now about [12:27] like tokconomics and how expensive it is [12:29] to actually run a lot of these models. [12:31] Based on this conversation, it doesn't [12:32] sound like you guys spend that much time [12:35] actually thinking about the cost of [12:37] these models. Is that correct? It's [12:39] really about the performance for you. [12:40] >> Performance uh latency and accuracy is [12:45] definitely the driver factor for most of [12:47] this, right? Cost is a nice benefit in [12:50] that, you know, uh surprisingly this is [12:53] one of the few like tasks where you kind [12:55] of get all the things for free, right? [12:57] like we we don't actually have to trade [12:58] off cost and latency and performance and [13:01] so just by optimizing for the driver is [13:03] actually latency and performance and we [13:05] just get cost as a nice side benefit [13:07] >> and do you think that's like something [13:08] that's unique to the way Decagon is run [13:11] or do you think there's something about [13:12] like this conversation about tokconomics [13:14] that for some reason just doesn't affect [13:16] you guys in the same way? No, I think if [13:18] you're a growth stage company, then [13:20] you're honestly like obviously we have [13:23] to be responsible with our costs, but [13:24] that's not the highest priority, right? [13:26] The highest priority is just growing. [13:28] And when you're talking to a customer, [13:31] they don't really care what your costs [13:32] are. They just care about how well your [13:34] agent performs. [13:35] >> So that's um that that's the main thing. [13:37] So actually, if you look at like our [13:39] unit of output of our agent, which is in [13:42] our case a conversation, um that's [13:44] really what our customers care about. [13:45] They don't really care about how much [13:46] that conversation costs to us or how [13:48] many tokens are in it. And actually over [13:49] time, the number of tokens we're using [13:51] per conversation has gone up because [13:53] we're actually doing more model calls to [13:55] make the quality better, to do more [13:56] checks, to um paralyze more things. And [14:01] that's just the stage we're in right [14:02] now. Like eventually, you know, if we've [14:04] won the market, then like that's when [14:06] it's like, okay, yeah, you know, now [14:07] it's time to look at our cost and see if [14:09] we can optimize further. But it's just [14:11] not the top priority. [14:12] >> Yeah. I also think we as a company are [14:15] at a different stage than a lot of [14:17] people that are talking about [14:19] tokconomics uh on on on X right because [14:23] the tokconomic debate really is around [14:26] uh hey I'm on a frontier model today [14:29] should I like how do I analyze my cost [14:31] and should I move to open source right [14:33] and there I actually think it makes [14:35] complete sense if we ran our entire [14:38] business exclusively on frontier models [14:41] I would care a lot about cost and I [14:43] would think a lot about that but once [14:45] you're already once you've already made [14:47] the jump to saying okay now now we know [14:49] how to think about open source models [14:50] and we know how to decompose a problem [14:52] we know how to uh build train and deploy [14:54] these models very very quickly all of a [14:56] sudden that the cost aspect becomes a [14:59] lot less pressing um but if you're still [15:01] in the world where you're using frontier [15:02] models for everything then I do thinking [15:05] about toolics makes makes a lot of sense [15:07] >> I just want to make this meta [15:08] observation that a lot of the [15:10] conversation even just now has in about [15:12] things like training models, right? Uh [15:15] we're talking about reinforcement [15:16] learning and um it really does blow away [15:20] what I think is, you know, a lingering [15:23] misperception about what an AI [15:24] application is. Um and just to get into [15:28] that debate a little bit because I think [15:29] it's sort of this narrative that [15:32] dominated the first half of 2026, which [15:34] is that anthropic open AI, they're the [15:37] last startups. They're going to take [15:38] over everything. applications, their [15:41] thin UIs with FTEEs, you know, with [15:44] implementation attached to it. Um, you [15:46] know, we talked a little bit about Deck [15:48] Gun Labs, but can you guys just share [15:49] what is your like how do you think about [15:52] this potentially false dichotomy of app [15:55] versus infrastructure company? Um, [15:57] clearly you guys are so much more than [16:00] the UI or the implementation. Um and uh [16:04] you know does agent lab you know popular [16:06] uh description um floating around the [16:08] last couple of weeks like does that [16:10] describe it like how do you guys think [16:11] of decagon? [16:12] >> Um so I'll give a quick perspective just [16:15] like from the from the POV of like an [16:18] enterprise and then maybe we can talk [16:19] about like broader the industry. So [16:21] let's say I'm like a Fortune 100 [16:23] company, right? and I'm looking out [16:24] there on all my use cases and I have a [16:27] choice of partnering [clears throat] [16:28] with an application company or uh sort [16:31] of using the labs and building from [16:33] scratch. Um I think there is a lot of [16:35] merit to partnering with the labs in [16:36] certain cases. I think if you look at [16:38] our case right like we we just talked [16:40] about all this fine-tuning stuff. I [16:42] think a common misconception that people [16:43] have is you know fine-tuning is is a way [16:46] to like customize it for that customer. [16:49] In fact, most of the fine tetuning we do [16:50] is like customizing it for our use case, [16:53] like the customer service use case. [16:54] >> Yeah. [16:55] >> And it's worth it for us to do it [16:56] because that's all we do, right? We do [16:58] these agents across all of these [17:00] different customers. And so it is worth [17:01] it for us to put in a ton of time and [17:03] research into like how do you tune this [17:05] one model to be good at selecting [17:07] customer service topics. But if you're [17:10] the enterprise, is [clears throat] it [17:11] really worth your valuable research [17:13] resources to like tune a model for these [17:16] like customer service behaviors? [17:17] Probably not, right? So that that's like [17:19] that's one reason why people um partner [17:21] with applications. Another reason is [17:24] >> let's say I do put in the engineering [17:25] effort to build like a some agent myself [17:28] using the frontier models. Um and you [17:31] know to my earlier point you know I'm [17:32] not fine-tuning for behavior but I'm I'm [17:35] sort of teaching the AI my own [17:36] procedures. And again that doesn't [17:38] happen through finetuning that that [17:39] happens like in context because if you [17:41] were to fine-tune on that you would have [17:43] to reverse it every single time you you [17:45] change your procedures which doesn't [17:46] make sense. And so you kind of build out [17:47] your logic and you're building your [17:49] business logic in well then you launch [17:51] the agent and then the second day you [17:52] look at your conversations and you're [17:54] like oh well actually I need to change [17:55] these three things [17:57] >> and now it's more engineering effort to [17:58] do that and it's like constantly [17:59] engineering effort. I think people will [18:01] partner with applications when the use [18:03] case calls for a broader platform where [18:06] there's a lot of value in using you know [18:08] the stuff that we've fine-tuned and [18:09] using the the software stack we've built [18:11] on top of the models to capture business [18:13] logic and that stuff has nothing to do [18:15] with the models right like how how the [18:17] business logic gets captured by this AI [18:19] like how do you handle someone calling [18:22] in because you know their flight was [18:24] canceled and they need to rebook three [18:26] people at once it's like that is [18:28] business logic that the AI needs to and [18:30] you're encoding that, but that has [18:31] nothing to do with the models [18:32] themselves. And so that that has to [18:34] exist in the application layer. I think [18:36] that's where applications will still [18:38] shine because you still need the [18:40] application there and it's not so much [18:41] the models. And the labs themselves will [18:44] have more application capabilities, but [18:47] those will be fairly general. Like [18:49] they're you can maybe build general [18:50] agents that can do this thing or that [18:52] thing. But [18:53] >> for a lot of these like core verticals [18:54] like ours, our our our thesis is that, [18:57] you know, you're going to need something [18:57] that's like very deep and has all the [18:59] integrations, has all the ability to [19:01] capture business logic, has the ability [19:02] to run, you know, tests and experiments [19:05] and then review the conversations and [19:07] run QA and like, you know, have tooling [19:08] for your compliance team to monitor like [19:10] what's happening. So that that's our [19:13] thesis on it. And so it's kind of it's [19:15] it's not black and white like there will [19:16] be some use cases where it does make [19:18] sense to use the the frontier models but [19:19] there will be these like core verticals [19:21] where going super deep makes sense. [19:23] >> Yeah. I also think you know everyone is [19:27] kind of bleeding into everybody else's [19:28] space a little bit right like [19:30] >> that's a convergence [19:31] >> all the all the labs are building [19:34] applications on top of it because [19:36] rightly so they're saying this is how [19:38] the enterprises do us more right and [19:40] this is how the enterprises see ROI from [19:42] using our products uh us on the [19:45] application layer we're realizing that [19:47] hey we can squeeze out a lot more [19:49] performance and latency and cost for the [19:52] use cases that we care about by building [19:54] our own models, right? Which and and I [19:56] think this uh this split this kind of [19:59] bleed over makes sense and I think it'll [20:01] continue. I'm not as bought into the the [20:06] labs are less startup view of the world [20:07] though and I think this is true both for [20:10] SAS companies and for the new AI [20:12] startups because in a way we human [20:15] beings are kind of AGI right and human [20:17] beings have needed to use software for [20:18] lots of things you know you need [20:20] databases to put stuff in you need CRM [20:23] to track things and I think even once [20:25] you have AGI all our AGI agents are [20:29] going to need somewhere to store work [20:32] and pull information from and reason [20:34] about things. So I think you know a [20:36] certain class of SAS companies that were [20:38] solely built for people to do work might [20:41] face a bit of heat but I I don't think [20:44] software as a whole in any meaningful [20:46] way is going away and I still think you [20:48] know on the application layer [20:51] >> there's so many different kinds of work [20:53] that that need to be done that can be [20:55] done faster more efficiently more [20:58] cheaply uh so I think there will always [21:00] be a space for application layer [21:03] companies maybe in the long term [21:04] application layer companies just become [21:06] labs for specific verticals, you know, [21:08] because your primary product ends up [21:10] being the models that are just really [21:12] good at doing those specific tasks. But [21:14] I think the application layer is [21:15] probably here to stay. [21:16] >> Uh I also want to kind of pick on [21:18] another thing that you kind of said in [21:19] tossing. [21:20] >> Yeah, please. [21:21] >> And maybe this is like a a spicier take [21:24] of oh are application layer companies [21:27] just for deployed companies that are [21:29] kind of doing the last mile of work. [21:30] >> Yes. Right. Well, well, I was saying [21:32] that's a misperception, but I think it [21:34] is a common one. Yeah, [21:35] >> I think it's a really hot thing. Also, [21:37] again, not to pick on tech Twitter to be [21:39] like, oh, like, you know, we need to [21:41] bring back the four deployed engineer [21:42] and you know, every company is hiring [21:44] tons of four deployed engineers. Uh, I [21:47] think this is a trap [21:48] >> actually. [21:49] >> Oh, same more. Okay. My my view on this [21:53] is that for deployed engineers are [21:56] necessary [21:58] or newly necessary for early stage AI [22:01] companies because the workflows are new, [22:04] right? If you're building a SAS company [22:07] 5 years ago, most SAS products are [22:10] pretty well explored, right? like you [22:12] roughly know what the user is trying to [22:13] do and your job is maybe come with a [22:15] slightly cleaner workflows but broadly [22:17] you know what the user is trying to do [22:19] with a design app or a CRM or something [22:21] like that because those workflows have [22:23] been explored with AI products nobody [22:27] knows what the workflows are because [22:28] nobody's used these things before so a [22:31] for deployed engineer in this case is [22:33] honestly just embedding with the [22:35] customer to learn the workflow for the [22:37] first time as the customer learns the [22:39] workflow for the first time and they're [22:41] kind you know, kind of paving the road [22:44] like you they're kind of laying out the [22:45] track as they see which way the train is [22:47] going in a way. [22:48] >> Uh but long term, [22:51] I think they should just be building [22:53] product, right? Like once you know what [22:55] the workflow is, you should not be [22:57] relying on four deployed engineers [22:58] anymore because once you know what the [23:00] workflow is, if you can productize it, [23:02] you should productize it and then [23:04] become, you know, typical company with [23:06] these scaling properties of a tech [23:07] company. [23:08] >> Yeah. And if you can't do that, then [23:10] you're just building a glorified [23:11] consulting truck. [23:12] >> Well, I'd love to dig into this more [23:14] because I know when we started working [23:15] together, probably almost exactly three [23:16] years ago, and you guys landed on this [23:18] idea, there were two things that were [23:20] relatively contrarian that now feel kind [23:23] of standard. The first was when you [23:25] started an AI customer service, a lot of [23:26] people were like, that's a G GPT rapper. [23:28] And we talked a lot about like why [23:29] that's not the case. And then the second [23:30] thing you did was say like, hey, we [23:32] actually want to do the work ourselves, [23:33] like we don't want to just be a software [23:35] platform. And now we have the term for [23:36] that. That's like AI agents and [23:37] everything. and you've popularized agent [23:40] PMs and forward deployed as a new type [23:42] of role or more common type of role um [23:45] in Silicon Valley, but your like agent [23:47] PM/forward deployed team has actually [23:49] evolved a lot since you first got [23:51] started to now and so would love to talk [23:53] about that like in the early days what [23:54] did it actually look like and then as [23:56] you started to learn about these [23:57] workflows and were able to productize [23:59] them better um how has that function [24:02] actually evolved for you guys? Yeah, if [24:04] you look at a lot of our four deployed [24:06] teams, [24:08] they are building product in one way or [24:11] another, right? So all of our for [24:14] deployed engineers for instance build [24:16] core product, right? Their job is to go [24:19] in and understand as we're working with [24:21] an enterprise, what are the things that [24:23] they need that the product does not do [24:24] today, but the output of that is not a [24:28] one-off thing that is just built for [24:29] that customer. It is something that is [24:31] contributed to core product in a way [24:33] that the next 10 customers that ask [24:36] about the same thing get it for free. [24:38] >> Right? Uh similarly our agent PMs are [24:41] working with our customers to understand [24:43] you know how is the product broken [24:47] today? How can this actually be [24:49] deployable within an enterprise? What [24:51] are the new things that we need to build [24:53] to our core product to make it [24:54] deployable within an enterprise? Uh so [24:57] at the end of the day all of this boils [25:00] out boils down into product improvements [25:03] either through actual product [25:04] improvements or through honestly process [25:07] improvements right like we work with [25:08] very very large enterprises and we help [25:11] them through the journey to go from okay [25:14] this is what your or looks like today [25:16] here is how we can take you through [25:19] changing your processes through [25:20] implementing new technology into this [25:22] world where AI agents are doing a lot of [25:24] work for you. So a lot of their product [25:26] work is also processizing a lot of you [25:29] know how we make that how we help a [25:31] company through that transition. [25:32] >> And also you used to be a deployment [25:34] strategist at Palunteer. So you're very [25:36] familiar with the forward deployed model [25:37] that Palunteer popularized. How [25:39] different is that at what you did at [25:41] Palanteer versus the way you [25:42] conceptualize this role at Deagon. So I [25:44] do think people use the term FD very [25:46] loosely at Silicon Valley. [25:47] >> Yeah. And I think it's it's dangerous to [25:49] mix the two of free consulting work [25:52] versus actually doing product. Uh you [25:54] know Sham um who's the CTF founder today [25:56] had had a phrase um internal I think now [26:00] it's been written about a ton. He would [26:02] say uh forward deployed engineers eat [26:05] pain and excrete product. [laughter] [26:08] No, that was kind of [26:10] >> Yeah, I think it's a it's like a massive [26:12] misconception because people are like, [26:13] "Oh, Palunteer is such a hot company and [26:14] like they're doing so well and like this [26:16] is like a cool take on how to implement [26:18] stuff." But first of all, very few [26:21] companies, if any, can do what Palanteer [26:23] does, which is like close massive deals [26:25] off the bat and like it's kind of worth [26:26] it to spend all that effort. So I think [26:29] a lot of the [26:32] uh you know people that are doing this [26:33] like super forward deployed strategy and [26:35] like hey we'll do any AI use case for [26:37] you um they will eventually have to [26:40] reckon with like okay can we find a [26:42] product that's scalable otherwise you [26:44] are just building like a a modern like [26:47] accent or something which yeah could be [26:49] could be good if if that's what you want [26:51] to do but I think people kind of [26:52] conflate the two it's like hey I'm [26:53] building a hot like software company and [26:56] you know we also have FTEES and like [26:57] that's our big strategy [26:58] So that's something that we've generally [27:00] been very mindful about from the [27:01] beginning is that we really view [27:03] ourselves uh in our core it's a it's a [27:06] productled company right um in in the [27:08] sense of you know we're building a a [27:11] core product that everyone can use and [27:13] we're not just here to even though we [27:14] have a large team now just like build [27:16] whatever use case that pops up because [27:18] you know ultimately everything has to go [27:19] into the core product otherwise you [27:21] can't scale essentially [27:23] >> um at the same time of course you know I [27:26] should say we also kind of salesled in [27:27] sense of like the product is informed by [27:30] sales. So we're not sitting there and [27:32] just you know coming up with product to [27:33] build and so you kind of have this [27:34] system where as a was saying we have all [27:37] these people that are you know for [27:38] deployed in the sense of they work very [27:40] closely with our customers but their job [27:42] isn't just to spin up like random new [27:44] use cases here and there and like just [27:46] doing whatever the customer wants [27:48] because in the short term that it could [27:49] actually lead to like larger contracts [27:51] and you can kind of hunt for wherever [27:52] the the pain is but then long term it's [27:54] just very difficult to scale. So their [27:56] job is to kind of compile all of those [27:57] learnings from sales into a core [27:59] product. And the goal at the end of the [28:02] day is like we should have the best [28:03] product out there and like be able to [28:05] iterate on that faster than anyone else. [28:07] And that's in our space at least our our [28:10] vision of like hey the the winner in [28:12] this space is going to be very product [28:14] driven. [28:15] >> I actually want to pull on this thread [28:16] of you know that you talked about where [28:18] your FDs are actually approving the [28:20] product. You know Decon is a very [28:21] product driven company. Um, so just to [28:24] kick off with a very small seemingly [28:26] unrelated anecdote, but um I was just [28:29] trying to convince uh someone on the [28:32] broader team to not leave a 16Z for a [28:35] Frontier Lab. And one of my arguments [28:38] was that [28:39] there was a good long-term career here. [28:41] And the response uh that this person [28:43] gave me was we'll have AGI, we don't [28:46] need careers in the long term. Um, and [28:49] it really hit me because I thought I was [28:50] AGI pill, but I had really not thought [28:52] about from that perspective. Um, and I'm [28:55] curious, you know, we talk about the [28:57] product improving, right? Can you make [29:00] that concrete for us? Like what are some [29:03] of the oh moments as you improve [29:05] your product for your customer either [29:07] from your end or your customer's end if [29:09] you can share on like, oh my god, I [29:12] didn't realize AI could do that. And [29:13] then of course I'm going to ask you your [29:16] thoughts on AGI and what that timeline [29:18] looks like because you're in the [29:19] nitty-gritty trenches of the enterprises [29:21] using AI. So you may have a different [29:23] perspective than you know we do. [29:24] >> The first thing I want to say is uh I'm [29:26] like certain there will be careers after [29:29] agi. [laughter] The reason for that is [29:32] >> like most of our jobs [29:35] >> for sure are for jobs are kind of like [29:37] made up to begin. Most jobs are made [29:40] selfless. A very real job [29:42] >> unless you're like building [29:43] infrastructure or like growing [snorts] [29:45] food or something. It's like [laughter] [29:47] like most jobs are kind of like layers [29:49] of abstraction built on top of like [29:51] other stuff, right? And that that isn't [29:52] to say like the jobs aren't valuable. [29:54] It's just they're kind of made up. So [29:56] when AGI is here, like it'll change [29:58] people's jobs, but every people sell [30:00] jobs because you're still going to do [30:01] things for other humans and and [30:03] whatever. So I I don't really believe [30:04] that careers will be gone after AGI. I [30:06] don't think people are just going to be [30:07] sitting around. I'll say one observation [30:08] which is like for me it was definitely [30:10] um duet so early days when we're [30:12] building the product right like the the [30:14] core problem we're solving again being [30:16] back to salesled is we talked to a bunch [30:17] of customers and they're like yeah the [30:19] value we want to get out of what you're [30:21] building for us is that we can put it in [30:23] front of customers they can have [30:24] conversations and it's giving them much [30:27] better experience and also it's like you [30:28] know way easier for us operationally [30:30] right it's like you're saving cost and [30:32] you're making customers happier so [30:34] that's that's like the first agent that [30:35] we built and that was like the core [30:37] agent we we worked on for the first like [30:39] year year to two years and the agent on [30:43] our end when we were building it [30:45] consisted of a ton of stuff like we [30:47] would have to um you know write these [30:49] procedures and we kind of create our own [30:51] format of procedures we call them agent [30:52] operating procedures that teach the AI [30:54] how to do things we had to write these [30:56] tools that the procedures can use to [30:58] access systems and pull APIs and [31:00] whatever and then after that we need to [31:02] like create all these tests to make sure [31:04] that this thing is working well and that [31:05] you can kind of simulate all these [31:06] different sit situations and afterwards [31:09] once they're in production like we would [31:10] manually be reading conversations, [31:11] right? There's like a ton of work that [31:13] goes into it even though the core [31:15] product we're building is is itself an [31:16] agent. And so what duet is is it's kind [31:19] of a separate agent. It's like a second [31:20] agent that's much bigger, much slower, [31:23] but its job is to do all the tasks I [31:25] just described. So now instead of us [31:27] having to write these AOPs and write [31:31] these integrations and tools into their [31:33] systems and write these tests and [31:35] monitor the conversations, do just does [31:37] all of that, right? So it's like a it's [31:38] a second agent that is smart enough to [31:41] do all these things and um it's it just [31:44] feels very magical because you can just [31:45] literally tell it like hey I've nothing [31:48] built yet so far, but here's a bunch of [31:50] transcripts I have and here's some [31:52] documentation. like you go figure out [31:53] the best way to like do these all these [31:55] procedures I want [31:56] >> and it'll go do it and then of its own [31:59] accord it'll also write the tests and [32:01] simulations that go along with those and [32:04] once you're done with that and you [32:05] actually put in front of customers it'll [32:07] be the one that's monitoring all the [32:08] conversations and it'll flag things [32:09] where things are going well or poorly [32:11] and it'll say like yeah I read you know [32:12] these thousand conversations and [32:14] actually there's this one topic that we [32:16] do really poorly on [32:17] >> and I've noticed that and I've also [32:19] drafted these improvements for you so [32:21] it's like [32:21] >> wow It's like one agent that can do all [32:23] of that. And so that that's very magical [32:26] because well first of all it was not [32:27] possible when we first started the [32:28] company. It only became possible when [32:31] all the reasoning models got better and [32:34] of course anthropic open are making [32:35] these reasoning models mostly for like [32:37] the cloud codes of the world but they [32:40] are also really good for like duet for [32:42] example and that was kind of like a [32:45] moment where it's like oh wow like first [32:47] of all you can just see the improvement [32:50] over time of the models. Yeah. [32:51] >> And two, it can do all these tasks where [32:54] it just would not be able we would not [32:55] have expected AI to be able to do all [32:57] these tasks at once, but it can do them [33:00] very well. And um I think that's that [33:04] was like a very visceral moment of like, [33:05] okay, wow, the models are getting a lot [33:06] better and they're becoming like very [33:08] generalized, you know, like they can do [33:10] all these things. Like clearly the [33:11] models were not trained on like our [33:13] specific task, which is you writing [33:15] these procedures and and writing these [33:16] tests, but they're still good at it. And [33:18] also um to your other question of how [33:21] you know how did we come up with all of [33:24] this and how how did the product improve [33:26] every single thing that Jesse just [33:28] talked about was the result of four [33:31] deployed people doing things and us [33:32] figuring out how to productize it right [33:34] so for instance um we realized that hey [33:37] when we go into a new customer we need [33:39] to spend all this time writing up the [33:41] AOPs manually and we're like wow this is [33:43] quite a lot of time how do we productize [33:45] this and we built that into duet and [33:47] then the Second part which we called [33:49] duet autopilot was uh once we built duet [33:52] you know people were using duet to write [33:54] things up and then we're like oh wow [33:55] there's still a lot of time that goes [33:56] into iterating upon the agent right once [33:58] it goes live like reviewing [33:59] conversations figuring out how to [34:01] improve it and we're like great let's [34:02] productize that as det autopilot in fact [34:05] AOPs themselves were a result of this [34:08] exact scenario because before AOPS [34:11] >> you would have to write all these [34:12] procedures in code [34:14] >> and then we found that oh it's taking a [34:16] lot of for deployed engineering work to [34:18] write all these things in code. Wow, [34:19] wouldn't it be so much easier and [34:20] efficient if we could productize it by [34:23] writing it in plain text, [34:24] >> right? [34:25] >> So the way we think about like product [34:27] improvements for deployed engineering [34:29] investment, everything is built around [34:32] what can we productize from forward [34:34] deployed work so that engineers and any [34:38] kind of customerf facing resources on [34:40] our team don't need to be kind of as [34:43] heavily involved. H can I ask you as [34:45] like kind of a blunt question on this [34:47] line of thinking? So I know we've [34:49] already talked about like why open Aan [34:50] anthropic won't be the last startups and [34:52] you've talked about like why there's [34:54] room to have like much more specific use [34:56] cases and specific companies but you [34:58] know you you you've also got had like oh [35:00] moments where you're like these [35:01] labs are getting so much better and the [35:02] models are getting so much better. Um [35:05] and so long term let's say like we we [35:07] hit AGI and the LA the models can do all [35:09] sorts of things we can't even imagine [35:11] today. What's decagon's moat at the end [35:14] of the day after all of that and like [35:15] why does decagon like 10 years from now [35:17] still have a right to exist? I think in [35:19] the short term actually it is the [35:22] ability to work with enterprise [35:24] resources and what I mean by this is [35:26] that the capability of models today is [35:30] far greater than they are being used for [35:33] within the enterprise right by which you [35:37] can't just take a model and say I'm just [35:39] going to give this model access to [35:41] everything within the enterprise and [35:44] I'll it'll just figure everything out [35:46] right like that's practically not how [35:47] these things So to make models like this [35:51] deployable within the enterprise, right? [35:52] Like let's assume that every model is [35:54] like just perfect and makes no mistakes. [35:56] But to make something like this [35:57] deployable within the enterprise, you [35:59] need to say, okay, I need a way to be [36:01] able to tell the model what it can and [36:03] cannot do and make sure that it cannot [36:04] do anything like catastrophically wrong. [36:06] Then I need a way to make sure that, you [36:08] know, hundreds of people within the [36:10] enterprise can collaborate to make sure [36:12] that the agent is behaving as expected [36:14] in the use cases in which they are [36:15] experts. Then I need a way to be able to [36:18] test this model and make sure that it [36:20] doesn't cross any like regulatory lines [36:22] that I have and test it, make sure it [36:24] works well. Then I need a way to, you [36:26] know, look over the, you know, millions [36:28] of conversations that happen for me to [36:30] extract insights for the rest of my [36:31] teams, right? Right. So there's a lot of [36:34] just infrastructure and software that [36:36] you need to build around these models to [36:39] make them deployable within an [36:41] enterprise to make them be uh work with [36:43] all the legacy systems that these [36:45] companies have. And so I think for the [36:48] next few years that's probably going to [36:50] be a you know the primary thing that [36:53] these models need to be able to work. uh [36:56] now once that gets commoditized because [36:57] the agents can build that on the fly [36:59] that I don't know and we'll figure out [37:01] in three years from now [37:02] >> by the way I think just listening to you [37:04] guys it's very clear that you guys [37:06] deeply understand how to sell AI to the [37:09] enterprise and I don't just mean you [37:12] know mid-market newly IPOed companies [37:15] I'm talking about some of the largest [37:16] companies in the world um and I think [37:18] this is particularly interesting because [37:20] you you both are very very technical but [37:22] also go to market animals Um, so I want [37:25] to talk a little bit about that. Um, but [37:27] you know, it just feels like you've [37:29] turned what maybe started as feeling [37:31] more like a David and Goliath with [37:34] multiple Goliaths. Um, uh, market [37:37] dynamic to really a two- horse race [37:40] between you and Sierra. Um, so share a [37:42] little bit more about why some of the [37:45] largest enterprises in the world are [37:46] buying from you guys. And I think what's [37:48] really remarkable to us as people have, [37:50] you know, studied application software [37:52] for, you know, over a decade, the sales [37:54] cycles are crazy fast. I mean, I'm sure [37:57] you guys with urgency want them to be [37:59] faster, but like usually you don't sell [38:01] contracts that big to enterprises that [38:03] big, right? That takes two years [38:04] sometimes. So, um, maybe just share a [38:07] little bit more on this is a long [38:08] question, but like how did you grow that [38:10] commercial? did you come with that into [38:13] founding the business and what's [38:15] resonating with these large companies [38:18] that enables you to get in and move so [38:20] quickly? [38:20] >> Yeah, I mean we we have a lot of respect [38:22] for for Sierra and also just you know [38:23] other folks in the space generally the [38:25] big platforms like they all I think the [38:28] platforms themselves move a bit slower [38:29] but I think that we've we met a lot of [38:31] those teams they're very competent teams [38:32] they're optimizing for a lot of [38:34] different things at once. uh Decon [38:36] versus Sierra. I mean our our most [38:37] recent customer actually uh turned off [38:39] of Sierra to come to Dekagon and sort of [38:41] the reasoning if when we asked them was [38:44] um [clears throat] it was this kind of [38:46] goes back to this like deployment model. [38:47] It's like you know when when they worked [38:49] with Sierra it was mostly FDES and it [38:52] just felt like a black box where you [38:54] know the the FDs were good but they had [38:56] to go through the FDS for everything. So [38:57] to build new journeys or to uh even get [39:00] like a deeper understanding of what was [39:01] happening in the conversations and then [39:04] over time that that kind of just created [39:06] a lot of drag on how quickly they could [39:08] move right so in the initial deployment [39:10] that was good but then over time maybe [39:11] the FDES were staffed other things and [39:13] it just took them a while uh to get [39:16] insight into what was happening and then [39:18] build out new journeys right so over [39:19] over the course of the year they maybe [39:21] built out uh I think they said three [39:23] >> um and so the reason they came to us is [39:26] because they they had that frustration [39:27] and they wanted to kind of have a [39:29] different model where it was a lot more [39:30] productized, right? Back to us being [39:32] like very product driven in our vision. [39:34] It's they should have a a core product [39:36] that even if we're there helping them, [39:38] even if we are forward deployed, it is [39:40] like a [39:42] in in service of helping them build a [39:44] product that they can use themselves and [39:46] iterate really fast and and kind of have [39:48] everything in their control, right? So, [39:50] we we like to call this like a glass box [39:52] approach instead of a black box. And uh [39:54] and yeah, so within a basically a month [39:57] they spun up like seven new journeys on [39:58] Ducky. Wow. Yeah. Mostly [40:00] >> and it had taken three a year to get [40:02] three. [40:03] >> Yeah. [40:03] >> Okay. Interesting. [40:05] So it's just kind of the speed of [40:07] iteration like some teams will really [40:08] like this like hey we have control of [40:10] it. We our teams especially our [40:11] non-technical people can come in and do [40:13] things and they understand what's [40:15] happening in the in the conversations. [40:17] And maybe there's other teams out there [40:19] that actually do like the like, hey, you [40:21] guys do everything for us and uh that [40:23] approach. But that that's kind of the [40:24] difference in the approaches and that's [40:27] why we've been I would say having a lot [40:29] of success there. And then zooming out [40:32] just selling to the enterprise. Yeah. I [40:34] mean this is something that uh you know [40:36] Asha and I have never sold to the [40:37] enterprise before and I think it just so [40:39] happens that both of us um find sales [40:41] exciting [40:42] >> and the enterprise it was kind of like a [40:44] quick learning curve for us. So, [40:46] I don't think I think a lot of it [40:48] honestly came kind of naturally just cuz [40:51] our space is so hot and like generally [40:53] in these conversations we're not really [40:55] having to convince people to like invest [40:57] in this space. It's like more of hey, [40:59] we're the right approach for you. So, [41:00] like you partner with us and uh yeah, [41:03] with the enterprises it's it's really [41:04] just about like navigating the orgs and [41:06] really having empathy for what they [41:08] value and what they're afraid of. [41:11] Um, so yeah, I mean we we just back to [41:14] being salesled, right? Like we we always [41:16] from the beginning were like, hey, we're [41:17] going to be like extremely strong on the [41:19] go to market side and that's going to [41:21] inform the product even though we have [41:22] this product driven philosophy like we [41:24] don't want to just be dreaming up random [41:26] products to build. Um, so we always had [41:28] that DNA and then in the early days we [41:30] were just yeah pushing really hard and I [41:32] think I also want to say I think we got [41:34] kind of blessed with a a really strong [41:36] early sales team [41:38] >> and we have a lot of really talented [41:40] people in that group and that helped us [41:42] really get leverage as we were talking [41:43] to you know the big enterprises [41:45] >> some of whom cold applied to you guys in [41:46] the early days I remember. [41:48] >> Yes. Yeah. Yeah. [41:50] >> Yeah. Cold cold applied. Um [41:52] >> cuz I think they were working in the in [41:53] the space already and they they were [41:55] seeing from afar like what Decagon was [41:57] starting to do. [41:58] >> Yeah. [41:58] >> Yeah. So some of them had like non [42:01] traditional sales backgrounds, you know. [42:02] So they had nontraditional sales [42:04] backgrounds. They're coming into sales. [42:05] The other profile we had a lot of in the [42:07] early days were just like like Ivy [42:09] League athletes, I guess. And [42:12] >> those profiles were kind of a good [42:14] foundation for the group. And you know, [42:17] we've had to scale that team really [42:18] fast, which is never easy. So there are [42:20] things that we're still trying to catch [42:21] up on in terms of enablement and and or [42:24] structure, but um because we've always [42:26] had that intensity on the sales side and [42:28] the whole company knows that like you [42:30] know everything starts with sales and it [42:33] kind of propagates back um you know [42:35] we've always had that focus. the, you [42:37] know, the other thing I think that [42:39] helped us a lot, um, you know, to your [42:41] earlier point about how did you get some [42:43] of these large deals closed so quickly [42:45] was, uh, I think we were very curious [42:48] about how we could productize parts of [42:51] it within the enterprise, [42:53] >> right? By which I mean, [42:55] >> we aren't a company that just says, [42:57] "Hey, here's a product. We'll throw it [42:58] over the wall and, you know, you get it [43:00] a year later." Because within a lot of [43:02] these enterprises, the question they [43:04] have internally in addition to will this [43:06] product work for me is can I actually [43:09] get this live? Right? And within a lot [43:11] of these enterprises, it's actually [43:12] complicated, especially if you're in [43:14] financial services and you're regulated [43:16] for instance. So we actually spent a lot [43:19] of time sort of uh mapping out that part [43:23] of the journey very well. So that when [43:26] we walk in to one of these enterprises, [43:28] we can walk them through in very [43:29] granular detail, how we go from this [43:33] first meeting today to going live at [43:36] 100%. [43:37] >> So yeah, [43:38] >> you know, at this stage for a company [43:39] like you, uh this is what your model [43:42] risk process is likely to be. This is [43:43] how uh your testing process should look [43:46] like. This is how we should do the [43:47] initial roll out. This is how we should [43:49] catch any issues that come up and how [43:51] we're going to fix them and how we'll [43:52] ensure that they don't happen again. So [43:54] the product and technology part of what [43:57] we sell is important, but for these [43:59] large companies, equally important is us [44:02] uh helping them think through the [44:04] process to actually get this deployed [44:07] and at scale because I think that is [44:10] something that often gets overlooked by [44:12] by tech companies selling into [44:13] enterprise. [44:14] >> Yeah, for sure. And um by the way, I can [44:17] also personally attest to the strength [44:18] of your early go to market team, having [44:20] met a bunch of them. Um, that being [44:22] said, I don't want to underplay how many [44:24] times a decision maker has told me that [44:28] one of the reasons of many, right, that [44:30] they're going with Decagon is they want [44:32] to make a bet on you guys. They're [44:34] they'll literally say, "We think the [44:36] founding team of Decagon is going to [44:39] move the fastest. This is a very [44:42] fast-paced market. it's changing on a [44:43] weekly if not daily basis and we think [44:46] that you guys are going to look at the [44:47] chess pieces and make the right moves [44:49] because it's not sort of like a oh [44:51] everything's going to be the same in you [44:53] know a year or even six months type of [44:54] market. Um so I'm curious I mean don't [44:57] give up too much alpha here but how much [44:59] time do you guys spend on sales as [45:02] founders and how has that evolved over [45:05] time? [45:07] >> Uh I probably spend most of my time like [45:09] 80% maybe. [45:10] >> Yeah. Okay. Um, and yeah, I think a lot [45:13] of it is just pushing speed. So, some of [45:16] it is like, hey, like as one of the [45:18] founders, you just have to be in calls [45:19] and like, you know, people want to meet [45:21] the founders, but also it's just how can [45:23] I be the sort of the main force that's [45:26] pushing our team to go faster, but also [45:28] just like the the partnership to move [45:29] faster. One of the things with that is [45:31] like you know now we work with you know [45:34] several of the largest you know banks in [45:36] the world and airlines and and telos and [45:41] no matter how fast you go like there's [45:42] all there it's those are still like [45:44] massive organizations and it will take [45:46] time and so one of the things that we [45:48] really try to do is you know kind of [45:50] take the project and piece meal it so [45:52] we're not just deploying across every [45:54] surface area every use case at once [45:56] that's really just pick you know one or [45:58] two of the top use cases and just get a [46:00] win [46:00] And [46:01] >> I would say that's that's been helpful, [46:02] right? If you navigate like a big bank [46:05] like it's not going to be like a quick [46:07] like, you know, you just close a big [46:08] deal, [46:09] >> right? At least for us it's not maybe [46:11] [laughter] some people can do it but um [46:13] it's yeah it's still a lot of effort and [46:15] it's it takes time and so you have to [46:18] figure out ways to you know design [46:20] things from a process perspective and an [46:21] oracle perspective and in a product [46:23] perspective as well that like just keep [46:25] shortening that and like finding clever [46:27] tactics and uh that kind of takes [46:30] founder involvement. um you you wouldn't [46:33] really expect a like a a sales team to [46:36] just like [46:38] constantly be coming up with new [46:40] configurations there because you know [46:42] they're not responsible for the product. [46:43] They're not responsible for you know the [46:44] end to end you know process that the [46:46] company runs. [46:47] >> So having the founder involved there is [46:49] very important I would say and then the [46:51] sales people their job is to kind of [46:52] execute on the sales side like build [46:54] champions and navigate the org and so [46:55] on. The other reason um to also spend a [46:59] ton of time with both sales prospects [47:01] and existing customers is also because [47:03] the market is changing so quickly being [47:05] able to really quickly understand [47:07] >> what are the things that we are not [47:09] doing today that we should be [47:12] >> doing very quickly right because model [47:15] capabilities are changing all the time [47:16] as models roll out people are seeing [47:18] other things that happen and they're [47:19] like oh wow this is really cool and like [47:21] I'm seeing this here and you guys aren't [47:22] doing that as well. Um so being able to [47:24] like stay really really close to that [47:26] feedback loop because um that's [47:28] something we never want to never want to [47:31] let go of. [47:31] >> Yeah. Do you want to talk about how that [47:32] like informs product roadmap? Meaning [47:36] >> probably like two two years ago or so uh [47:38] most of Decagon's customers were focused [47:40] purely on customer support and nowadays [47:41] I would say that's that's actually not [47:43] true. You guys have broadened your [47:44] vision to mostly like to be like an AI [47:46] concierge for your customers. Do you [47:48] want to talk about what the distinction [47:50] between those two actually is and in [47:51] practice like what that means for both [47:53] your sales teams and your product teams? [47:55] >> So you know all the when we launched the [47:59] original set of use cases that we sold [48:02] were in customer support. Um and the [48:04] reason was because one that was one of [48:06] the biggest challenges that a lot of our [48:08] early customers were facing and two that [48:11] was where the capabilities of the models [48:14] ended at the time right like that is all [48:16] that is the pretty much the limit of [48:18] what they were capable of doing. Now, [48:20] however, as models have gotten better [48:23] and our customers have realized, well, [48:26] why would I have one set of models that [48:28] just learns about my customers when they [48:29] have another when they have a problem [48:31] and something else when they come to me [48:34] to buy something, right? And so, we had [48:36] a customer that we originally went live [48:37] with them for customer support. Uh, and [48:40] then they realized they were like, well, [48:42] you know a lot about our product now. [48:44] You know about the capabilities that it [48:46] has because you need to do that for [48:47] customer support. you know how we like [48:50] talking to our customers and our brand. [48:52] Um, can you help us with inbound sales, [48:54] right? When someone comes in, answer [48:56] questions about us, do some discovery [48:58] and then, you know, assign it to the [49:00] right uh uh enterprise rep if it's, you [49:02] know, a deal of large enough value. We [49:05] had another customer that um started [49:08] using us for a lot of operational [49:09] workflows, right? So uh we are able to [49:13] now proactively reach out to them once [49:15] we start seeing um any kind of issues on [49:19] on that on that customer's account. Um [49:21] because ultimately at the end of the day [49:23] the thing that we built and we kind of [49:25] built this intentionally from the start [49:27] was not an agent that does customer [49:29] support well but rather an agent that [49:31] follows business process well right and [49:34] executing on operational workflows doing [49:36] sales lead qualifications on certain [49:39] customer support questions at the end of [49:41] the day is just an agent following a [49:43] business process. And we kind of built [49:45] it flexibly enough to kind of do all [49:47] these things because we realized that [49:49] hey at a certain points the models are [49:51] going to get better and they have. [49:52] >> And what do they specifically get better [49:54] at that allows you to do that? [49:55] >> It is specifically the ability to follow [49:59] instructions. Well, right. So when you [50:02] had um models, you know, let's say a few [50:04] years ago, you'd have to give it very [50:06] very tight guidance, very specific [50:09] instructions that you didn't want it to [50:11] deviate from. And as the models got [50:13] smarter, you could kind of give it [50:15] broader and broader guidance, bigger and [50:17] bigger instructions, and just trust that [50:20] the models have good enough sense to [50:22] interpreted like a human would and kind [50:24] of fill in any missing gaps, right? [50:26] Because for again for customer support, [50:28] you can have a very tight path that the [50:31] model should follow. And that's all you [50:32] really need. Whereas for sales [50:34] qualifications, you kind of want to ask [50:36] open-ended discovery questions. The [50:38] conversation is going to kind of bob and [50:39] weave. And so you need the model to kind [50:41] of fill in with reasonable things. So [50:43] that's specifically kind of what the [50:45] what the models got better at over the [50:46] years. [50:47] >> Yeah. Um I think [clears throat] if if [50:50] you think about you know what is the [50:53] like 12 month product road map because [50:55] things are moving so fast like the [50:56] answer the real answer to that is like [50:58] we kind of like see how it evolves and [51:00] we obviously know what we're working on [51:02] now but I think realistically in in [51:04] today's AI world it's very difficult to [51:06] have like a a 12-month road map to a [51:08] tea. you maybe know have like some [51:09] themes of what you want to build but [51:11] ideally if you have those things you [51:13] just build it like right now because [51:14] it's so so fast to build things now so [51:17] um I would say that that is that is one [51:20] element but then the sort of long-term [51:21] vision is still very clear to us now [51:23] right which is we use the term concierge [51:24] but really it just means like hey an AI [51:26] agent should just be the front door of [51:28] your business or your brand and every [51:30] interaction whether it's like reactive [51:32] or proactive with a customer uh should [51:34] be handled by by AI and we've already [51:37] seen that AI is very good at that right [51:38] customer service is like a huge pillar [51:40] of that where it's all these inbound [51:42] interactions but why not have also be [51:44] able to do all these other things. So [51:45] over time again we're we're not trying [51:48] to figure out on our own what these [51:50] things are. We kind of have now have a [51:52] lot of customers that will give us [51:53] signal on the things that they care [51:54] about and those will be the things that [51:56] we built. [51:58] >> We we've talked a lot about how the [52:00] models are getting better and you know [52:02] obviously your capabilities are are [52:03] moving along even you know ahead of that [52:05] progress. Um, what are some of the [52:07] bottlenecks right now that you're [52:08] seeing? Um, whether that's on the [52:10] capability side. Um, I don't it could [52:13] also be, you know, around persistent [52:15] memory. I don't know if you guys feel [52:17] like that's kind of up to snuff on where [52:19] you would like it or um could be other [52:21] bottlenecks, but curious like what would [52:23] you like to see and what's kind of [52:24] holding you back? [52:25] >> Hiring. [52:27] [laughter] [52:29] >> Got it. So, it's less on the AI side. [52:30] It's actually like we are we are [52:33] voracious consumers of tokens but we [52:35] would always love more great people. I [52:37] think there's so much to build these [52:39] days that it's uh you know [52:40] >> and why can't you hire [52:42] >> AI agents to do the things that you're [52:44] doing? [52:44] >> Yeah, we we are voracious consumers of [52:47] [laughter] [52:48] of of token really like our our token [52:50] bills are very very large. Um but uh uh [52:54] you know there are still things I I [52:56] don't quite yet think we're at the point [52:58] where we can have the AI agents uh make [53:02] decisions on what to build and kind of [53:04] have that [53:06] >> uh the taste of is this done yet [53:10] >> right so we can outsource a lot of [53:12] specific execution steps but uh I I [53:15] don't yet think they're at the point [53:17] where they can make the call on what to [53:19] build what to exclude [53:21] things like that. [53:23] >> So the model's improving, have they [53:25] since like you found it three years ago, [53:27] has it changed your hiring needs at all? [53:30] Because a lot of people are like, "Oh, [53:31] you can build like oneperson unicorns, [53:33] you know, like [53:34] >> Yeah, you know, I I I think, you know, [53:36] this argument does get tossed around a [53:38] lot, but I think the the uh an easy [53:41] counter example to this is all the uh [53:45] the AI coding startups are hiring like [53:47] crazy." you know, they're like the most [53:48] sophisticated users [laughter] [53:50] presumably of these models and they are [53:51] hiring like crazy. I think the reason is [53:54] just because [53:55] >> um [53:56] >> everybody has access to these tools and [53:59] so if our competitors are going to use [54:01] them and build more things, we need to [54:04] build more things, right? If somebody [54:06] else said, "Oh, here's our road map and [54:08] now we can get through it in, you know, [54:10] a third of the time." And then they just [54:11] stop hiring. We would just take that to [54:13] mean, "Wow, we can get through it in a [54:15] third of the time. Great. that's built [54:16] three times as much stuff and turns out [54:18] everybody, you know, does the same [54:20] calculus. So, everybody both needs to [54:22] keep hiring more and shifts more. So, it [54:25] is great for consumers of these models. [54:28] Um, but I don't think it has materially [54:29] changed our our hiring plan. [54:32] >> It's so funny. I thought you were going [54:33] to say something like, I don't know, [54:35] latency of voice models or something [54:37] like that, but it seems like on the [54:40] technological [54:41] bottleneck side, it's [54:43] >> Yeah, there's still stuff that we're [54:44] waiting for, right? like um you know [54:46] voicetovoice models is an interesting [54:47] frontier that there's still research [54:49] happening on [54:51] >> um you know the getting smaller models [54:54] to be smarter smarter out of the box [54:55] right so there's there are going to be [54:57] still developments that we are watching [54:58] closely that we care about [55:00] >> but from a business perspective it's [55:01] less on the model side and more on the [55:04] just like can you build the company fast [55:06] >> yeah um actually maybe since we're on [55:09] the topic of hiring um and you know I [55:12] feel like grind slop has become this [55:15] theme on on X. Uh, and it's so funny [55:18] because, you know, as a as a VC, like I [55:22] I'll admit, you know, when I I mean, you [55:24] guys are famously in the office six, [55:27] seven days a week. I hope this doesn't [55:29] get marked as grind slop now, but um, [55:31] you know, I think constantly hustling [55:33] for your teams and your customers. And [55:35] it's so funny to see that kind of turned [55:37] on its head. Um, and so I'm just [55:39] curious, what is your what are your [55:41] thoughts on the narrative out there and [55:43] like um, grind slop is such a general [55:46] term, but like you know you guys grind, [55:48] but there's also a lot of camaraderie [55:50] and excitement in the office. So like [55:52] just you know say more about that and [55:54] like how you're building the culture. [55:55] [clears throat] [55:56] >> Yeah, I mean grinds is a funny term. We [55:59] [laughter] so we have never posted grind [56:01] slot because we kind of view that like [56:03] working hard is just like I don't I [56:05] don't think people are like working hard [56:07] to grind. It's just like oh there's a [56:08] lot of stuff to do. Like [56:11] >> we kind of people spend time there [56:14] mostly because like [56:16] >> hey it's you know this is like a fun [56:17] time of our life. Like we want to take [56:20] advantage of our talent and sort of [56:24] potential so that it's not wasted. I [56:26] think that's that's the main reason and [56:29] it's a very sort of like it's like many [56:31] orders from like the main goal which is [56:32] like can you build a good product and [56:33] can you win in a space and but it's like [56:36] one of the effects of that is that [56:37] people work harder and [56:39] >> even from from the beginning like we yes [56:41] we have an office culture but like we're [56:43] never mandating people to come in on the [56:44] weekends. We don't really care how long [56:46] there are they are in the office. It's [56:47] just people are in the office just so [56:49] that like we can maximize communication [56:52] and that's how we view it. Um like I [56:56] don't view ourselves as like you know [56:59] abnormally grindy or am abnormally [57:02] ambitious. I think like we're I think [57:07] we just like I have a lot of ambitious [57:09] people around me like us and all these [57:10] people that so it kind of just become [57:12] normal and like everyone works hard so [57:13] it's just kind of like normal. [57:15] >> Um so I don't think it's like something [57:16] that we view as you know something like [57:19] super special. [57:20] >> Yeah. And we kind of also view a lot of [57:23] what we do very much as a team sport, [57:26] >> right? Where we very rarely have lines [57:29] between our orgs in that uh you will [57:33] very commonly see engineers on early [57:36] stage sales calls. You will see [57:38] salespeople like debugging parts of the [57:40] product. You will see our APN team in [57:44] absolutely both ends of the spectrum. [57:47] Um, and so I think being able to have [57:51] teams that are so kind of uh disperate [57:54] from like a function perspective all [57:56] working together kind of uh one kind of [57:59] needs people in the office because [58:01] everybody's kind of [58:02] >> jamming on ideas together but two it [58:04] also makes it [58:05] >> fun in a way because you know everyone [58:07] is like working together towards some [58:09] very specific outcome right it's either [58:12] um getting this uh building this thing [58:14] for this customer in time for the deal [58:16] to close or launching this new thing. [58:19] And because it's so many different teams [58:20] working together, it's kind of a it's [58:22] kind of a we're all in this together to [58:24] get this across the line. [58:25] >> Yeah. Well, and how does that scale as [58:27] you know, you you've launched a lot of [58:28] new offices recently. You have a new [58:29] Australia office, London office, your [58:31] New York office is growing like crazy. [58:33] How do you maintain that culture when [58:34] you guys are both in San Francisco? [58:37] >> I don't know. I mean, [laughter] [58:38] >> yeah, I don't I don't think it's a [58:40] solved problem for us. like we're [58:42] constantly working on it and like every [58:43] single time the company gets to the next [58:45] phase there's like new things we have to [58:47] institute to just make sure that [58:48] everyone understands the culture and [58:50] there's like very high accountability [58:52] and um you know there there is pressure [58:54] because there should be and so that's [58:58] something that we're constantly adding [58:59] on because in the first 100 people it [59:01] doesn't really matter because everyone [59:02] kind of knows each other and like [59:03] everyone's but like as you grow people [59:06] might not have no one's communicated the [59:08] vision to them or communicated the [59:10] culture to them And um yeah, I know like [59:13] Ben was talking to us about the A16Z [59:16] culture, right? It's like how it's very [59:18] like actionoriented and you can't just [59:19] like put put like fluffy stuff on there. [59:22] And so [59:23] >> um yeah, it's all these things that [59:24] we're trying to do a better job of as we [59:26] grow. Uh the other thing is also we um [59:30] we bring everybody that we hire out to [59:33] San Francisco for a couple weeks when [59:34] they start so they're kind of immersed [59:36] in the kind of uh the original kind of [59:40] soup of of culture. Uh, and then for [59:43] every new office, right, at this point, [59:46] New York and London, all these offices [59:48] are big enough that they have the [59:50] original decagon culture there anyway, [59:52] but for brand new offices, we actually [59:54] have people from one of these hubs go [59:58] out and spend a few months there really [60:01] until the office becomes big enough and [60:03] has its own kind of culture um, so that [60:06] it doesn't kind of become too different [60:09] from what kind of the original decagon [60:11] culture was. Actually on the topic of [60:13] international we're um so we brought on [60:16] uh Ragu um Ragnaram last year obviously [60:19] former CEO of VMware um and in addition [60:23] to investing he's helping us build out a [60:25] ton of our international capabilities um [60:27] and I think one of the things that we've [60:29] seen is that our AI companies are just [60:33] getting pulled internationally way [60:34] earlier like for you to have an [60:36] Australia office it seems premature [60:39] except for the fact that you have [60:41] customer poll [60:42] your scale is quite large for you know [60:44] how long ago you were founded. Um but [60:47] maybe say more about that like does that [60:50] translate like does your product [60:51] translate well to these other geos um [60:54] are there more enterprise concerns uh or [60:58] fewer or is it kind of just comparable [60:59] to the US market? [61:01] >> Yeah, I think there's two trends. uh one [61:02] is that AI is just such a phenomenon [61:05] that every buyer out there has you know [61:07] tried chat GBT or whatever and so there [61:10] is a lot of just top down pressure from [61:13] boards and sees to just get moving on [61:15] something and if you think about a lot [61:16] of these businesses they're like hm how [61:18] do we adopt AI well it's you know let's [61:21] do some coding agents and like let's do [61:22] customer service because those are like [61:23] the obvious ones and so there is a lot [61:25] of pull uh to to your points [61:27] >> and then the other trend is that [61:30] language is a lot easier with AI. So [61:34] >> yeah, [61:34] >> in the past maybe a blocker would be, [61:37] oh, my language just doesn't work in or [61:39] my app just doesn't work in German or [61:41] >> right, [61:41] >> pick your language, right? But now it's [61:43] a lot easier is to adapt your app. So [61:46] >> I think for those reasons, international [61:47] has been a lot faster. Like at the same [61:49] time, right, like we also want to make [61:51] sure that we're not getting spread too [61:53] thin. And so it's kind of this balance [61:54] where [61:55] >> it's like very unclear what the perfect [61:57] answer is, but you know, we've kind of [61:59] made a determination of like which [62:00] markets we're [62:01] >> um okay with really investing in and if [62:03] we're going to invest, we're going to, [62:04] you know, really invest. And generally [62:06] those markets are ones where we've [62:08] already just like naturally picked up [62:10] some customers out of the US office or [62:12] something. [62:13] >> Yeah. [62:13] >> And then now it's like time to deploy [62:15] people. Um because yeah even though [62:18] these there are these trends that make [62:20] it easier to go internationally like you [62:22] know there's also other things that you [62:25] don't really think about right like you [62:26] have to have data residency there's all [62:28] these things where and there's like [62:29] local competitors which are just know [62:31] the market a lot better and so you have [62:33] to navigate that well. [62:35] >> Yeah absolutely. Um [62:37] >> do you think there is a like a space for [62:40] like local competitors to the large [62:42] categories that we know about? I mean [62:45] there is space for them. I think the [62:47] question is like long-term is there [62:48] consolidation [62:50] and it's it's you you could say that for [62:53] both um geographies but also verticals [62:56] and then also market segments, right? So [62:58] like there are going to be people that [63:00] find their niche in different places. [63:03] Like our view the reason why we've kind [63:05] of built so horizontally is that we [63:07] believe that in our space the winners [63:09] are going to be horizontal. there's just [63:10] not that much that is like super [63:12] verticalized that where like you could [63:14] see a a pure vertical solution surviving [63:17] and historically that's just been true [63:20] in our space right like Salesforce very [63:22] horizontal Zenness very horizontal like [63:24] all these solutions are very horizontal [63:26] because you just gain more from having [63:28] that scale and having a very robust and [63:30] deep product than you do from like [63:32] having very vertical specific features [63:34] and over time we're also going to build [63:36] you know vertical features into it but [63:38] our view is that like from a vertical [63:40] and sort of market point of view there [63:42] will be consolidation. [63:44] >> Um just sort of on related to [63:47] consolidation but maybe not just [63:49] geographic um consolidation. I'm curious [63:52] if AI concierge becomes really the [63:56] interface between the business and its [63:58] customers. Do you see what like how does [64:01] CRM and all of these you know sort of [64:04] traditional [64:06] data very important systems of record [64:08] right for the end customer um how do [64:11] those evolve in this new world and do [64:14] you see any consolidation [64:16] >> there in terms of your own role [64:18] >> yeah I don't um I don't think it's [64:21] necessarily an either or [64:22] >> right because ultimately [64:25] what we're what we're doing here is [64:28] trying to democratize [64:31] uh access or availability of these [64:33] concatives, right? Which is if you were [64:36] going to a business where you were [64:38] spending $100,000 a year, you would get [64:41] the most personalized treatment. They [64:43] would know exactly who you are, what [64:45] your preferences were. They want to help [64:47] you, you know, shop, for instance. [64:49] They'll shut the whole store down for [64:50] you. [64:50] >> Actually, I don't know if they do that [64:51] for, [laughter] [64:53] >> but you get the general, right? [64:55] >> You've never you've never tried that [64:56] before. [64:56] >> I've never tried those. Um, however, if [65:00] you're at a business where you're [65:01] spending $10, they can't do this for you [65:05] because they can't make it economical, [65:07] >> right? It is not a lack of desire to do [65:10] this for their customers. It is just [65:12] that the unit economics don't support [65:14] that. [65:14] >> And so, effectively, all we're doing [65:16] here is saying, okay, if you could give [65:19] them that experience for [65:21] >> 10 cents, all of a sudden it is [65:23] economical and they'd want to do that. [65:24] Now to the point of does that mean CRM [65:28] go away? I mean my answer is no because [65:30] if you had u you know if you have a [65:33] company today where the con your [65:35] concierge is a human being [65:37] >> they still write your info in a CRM so [65:39] they can track it for later. So, and I [65:41] think when we have these AI agents, they [65:43] will need somewhere to put that [65:44] information. [65:46] >> Um, so I don't necessarily think those [65:49] kind of auxiliary pieces of software go [65:52] away [65:53] >> because um for us as we're building [65:56] these concurries, our goal really is how [65:58] do we create that great experience? We [66:01] will still need places to put that data [66:04] somewhere, [66:05] >> right? [66:06] >> Yeah. Um, I actually think CRM could do [66:09] quite well. um they'll they'll be [66:11] slightly different in the sense of like [66:13] CRM are kind of databases in a way and [66:16] >> you know the frustration people have [66:18] with them sometimes is that the [66:19] interfaces are really difficult to use [66:22] etc but in the future maybe the agents [66:24] are just using the interfaces and you [66:27] don't you don't even have graphical [66:28] interfaces or whatever and so the CRM [66:30] are still very valuable because they [66:32] they hold the source of truth and you [66:33] know then the agents they're just kind [66:35] of getting pinged a lot more because the [66:37] agents are are using them so that is one [66:39] possible world that's that's kind of [66:41] bullish on CRM and [66:42] >> for us personally like so far with [66:44] Zechon there's like we have zero desire [66:45] to build a CRM because we think there's [66:47] so much to do in the agentic layer [66:50] >> and that's where we want to focus [66:51] >> yeah okay so SAS is not dead [laughter] [66:56] >> cool maybe um last thing is we were [66:59] chatting right before we we started [67:00] recording that you guys have done some [67:02] little AI experimentation on your own as [67:04] you just figure out how to you know make [67:06] your own life more productive and [67:07] effective and also it sounds like you've [67:09] done something kind of interesting. [67:10] >> Yeah. Um, you know, I think the models [67:14] have gotten very smart uh over the last [67:17] several years and you know the two of us [67:21] will often use it to brainstorm ideas, [67:24] right? Because they are genuinely very [67:25] smart at at coming up with great ideas. [67:28] However, the bottleneck I realize at [67:31] least for a lot of the work that I do is [67:33] business context, right? there's a lot [67:35] of context for every idea around okay [67:37] the constraints that we have the goals [67:39] that we're going for and things like [67:41] that that is difficult to reexlain to [67:44] the agents every time and so I actually [67:46] spent a while building agents for myself [67:49] to capture all the business context well [67:52] so it just kind of looks over my [67:55] shoulder all the time and is constantly [67:57] compiling context on oh here are the [67:59] people that we've hired here are the [68:00] people that we need to hire here are the [68:03] deals that we're working on here's here [68:04] are the problems. Here are the current [68:05] challenges that we have. So that later [68:08] on I can just go to it and say, "Hey, [68:11] there's this new person that we're [68:12] thinking of hiring. What do you think?" [68:13] And now it's able to automatically [68:15] reasonable, well, we had two candidates [68:17] that were very similar and you know, [68:19] these candidates had these kind of uh [68:22] drawbacks or skills that they didn't [68:23] have. And so if we hire this person, [68:25] it's going to be another person that has [68:26] those, you know, kind of exact same [68:28] things. So we need someone [68:29] complimentary. So this is probably not [68:31] the best person to have or [68:33] >> you know in this deal we're barreling [68:35] down a very similar path because you [68:38] know we didn't validate these things [68:39] early enough so this time we should [68:41] validate them uh uh slightly earlier. So [68:43] it's really all about how do you capture [68:45] context well because then you know my [68:47] job is making decisions with lots of [68:50] context. So if I can outsource that more [68:52] and more to a model maybe I can put [68:54] myself out of job quicker. [68:55] >> Sounds like you created Jesse. [68:57] [laughter] [68:59] There we go. [69:01] >> I do think um like one of the big [69:03] struggles of being a solo founder is you [69:04] don't have anyone to bounce ideas off [69:06] of. So you just arrive at conclusions a [69:08] lot slower. [69:09] >> You guys were both solo founders in the [69:10] past, right? [69:11] >> Yeah. So like us working together, I [69:13] think the reason it was so much easier [69:15] is that we could, you know, iterate on [69:16] things much faster. You kind of just [69:18] talk something out [69:19] >> and uh yeah, now you've talked to Fable [69:22] or whatever. It's like [snorts] it's [69:24] pretty good, honestly. seem like very [69:26] original [laughter] [69:29] >> because in the past it's just like they [69:30] just kind of are kind of sick fence, [69:32] right? Where they just agree with you. [69:33] Oh, that's a good idea. But now they're [69:35] like, "No, that's a bad idea. [laughter] [69:37] >> Don't do that." [69:39] I actually uh for a while Mark at one [69:42] point had uh uh posted the prompt that [69:45] he used for Claude where it's like, you [69:48] know, disagree with me, be very direct, [69:50] things like that. So, um I actually used [69:52] that for one. It was great. And the the [69:54] funny story on this was I really enjoyed [69:57] it because it would agree with me very [69:59] aggressively. It would disagree with me [70:00] very aggressively. And um I took it to [70:03] my wife and I was like, "Ah, this is [70:04] great. You should use it." She put it on [70:06] and then, you know, a day later she was [70:08] like, "Wow, Claude was being so mean to [70:10] me all day. I had to turn it off." Like [70:11] he just kept telling me, [laughter] [70:14] "Yeah, it was just disagreeing with me [70:16] so aggressively." [70:18] [gasps] [70:18] >> Amazing. Um well, since we're on this [70:21] topic of f founders using AI to do [70:24] things, um I have to bring up the whole [70:27] uh AI slop um fiasco maybe is a strong [70:32] word that Brian Chesy just went through. [70:34] Um and I want to bring it up because um [70:37] you both have grown your profile a lot [70:39] over these last few years. And you know, [70:41] you know, I sort of mentioned Jess, you [70:42] had these pieces that were just hitting [70:44] the zeitgeist of the discussion that [70:46] everyone wanted to have and came in with [70:49] a very differentiated take. Um, and uh, [70:52] you know, that's the kind of stuff that [70:54] we see exactly hit on. You know, you're [70:56] hitting the conversation right at the, [70:58] you know, right message, right time. Uh, [71:00] unique message, right time. Um, do you [71:02] use AI for writing? Um, and separately, [71:07] um, this is a more of a meta question, [71:09] but how important is X and like the [71:15] sentiment on X to you? [71:17] >> Uh, so yeah, for most of our early days, [71:20] it was mostly LinkedIn with the [71:22] reasoning of like, hey, our customers [71:23] are on LinkedIn. You know, we're not [71:24] going to get someone seeing us on [71:26] Twitter and then coming as a customer [71:27] probably. But I think the the sort of [71:30] learning we had with X is or at least I [71:33] was kind of reflecting on it. X is kind [71:35] of like like the timeline that people [71:38] talk about. [71:39] >> And most of that timeline is not really [71:41] about your company. Like if you're if [71:42] you're very like [71:43] >> just like promoting yourself on X like [71:45] it's going to get no traction [71:46] whatsoever. [71:47] >> Totally. [71:48] >> But it is sort of like a single timeline [71:50] that everyone reads. So it kind of like [71:52] it kind of like mind controls everyone [71:54] to be thinking about the same thing. [71:55] >> Yes. And that's where it's valuable to [71:59] have some say in it. And uh who was this [72:04] guy listening to? There's like there's [72:06] this guy like Jeremy GeFon or something [72:08] who's on Patrick Ashanti's podcast who I [72:10] like and he was like doing he like made [72:12] some claim about how like you know it [72:15] used to be that [72:17] >> like the the the big status symbols in [72:19] the world is like everyone wants to be a [72:20] billionaire cuz like he calls it like [72:22] the priest class or whatever. So it's [72:24] [laughter] like billionaires are the [72:25] priest class but nowadays actually it's [72:27] when people become billionaires now they [72:28] want to become ex influencers because [72:31] like those people hold the real power [72:32] because they can like influence what the [72:34] whole world's thinking about. [72:35] >> Um so that's like one reason to have [72:38] some presence on X I suppose [72:40] >> and when we now when I post on X I don't [72:43] really post about like Decon [72:45] specifically it's more more about you [72:47] know our thoughts on what is happening. [72:50] So, I think that's that's like a good [72:52] good way to do it. And but it is very [72:54] different. [72:54] >> You write it all yourself, right? [72:56] >> Yeah. Um I mean AI is good for um sort [72:59] of helping you brainstorm like what [73:00] topics to write about. I think that's [73:02] that's pretty good. [73:03] >> But I think that was that's kind of like [73:04] a learning that like LinkedIn and X work [73:06] very differently. You can't just like [73:08] come up with something cool [73:09] >> and [73:09] >> like post the same thing on both [73:11] >> because like very few things like do [73:15] well on both. [73:16] >> Yeah. So like LinkedIn's really good for [73:18] you know classic stuff. You're making [73:19] announcements and um talking about your [73:22] product and you know fund raise or [73:25] whatever. I guess you can do fundraising [73:26] on X as well but X is a lot more about [73:29] kind of like placing yourself on top of [73:32] that single timeline that everyone's on. [73:34] >> And is that so is it too much of a [73:37] simple you know simplification to say X [73:39] for hiring especially you know AI [73:41] research talent etc. um maybe ecosystem [73:45] as well and then LinkedIn more for [73:47] enterprise customers or are you actually [73:49] seeing enterprise CIOS pay attention to [73:51] X? Hard attribution is hard obviously. [73:54] Yeah, it's hard because you know I think [73:57] you could say like oh well you know I I [74:00] I made a post on X and then you know the [74:02] people on all in podcast were talking [74:04] about it and like CIOS definitely that I [74:06] saw that so it's like a [74:08] >> like indirectly I'm sure we got like [74:10] some eyeballs from CIOS like is the CIO [74:13] themselves like scrolling X all day [74:15] maybe not [74:16] >> but if you are part of that major [74:19] timeline then you have there's always [74:21] these like secondary effects and then [74:23] and then like reporters will reach out [74:25] to like from like mainstream media and [74:26] then if they write about you then like [74:29] Ashan was on the New York Times recently [74:31] you know it's like if they write about [74:32] you then those for sure get eyeballs so [74:35] >> you were [74:36] >> Mhm. [74:37] But it was just open source stuff. [74:39] >> Oh, Kimberly's only on X. So, [laughter] [74:43] >> you didn't put the next article. I [74:44] didn't see it. [74:45] >> Um, I guess maybe a last uh question [74:48] would be just since we touched on like [74:49] hot button X topics. um one and this is [74:53] kind of a serious one actually but it [74:54] sort of re-entered the narrative I think [74:56] with um you know the anthropic video and [74:58] it's just sort of maybe never left the [75:00] narrative but it's on this concept as [75:03] progress gets better around jobs um and [75:07] the messaging around that um it's a [75:10] sensitive topic obviously but it's [75:12] interesting because I really think [75:15] customer support was maybe the first [75:17] endto-end use case where you could [75:21] really [75:22] take an entire job um or sorry do an [75:26] entire job I should say take is the [75:27] wrong word um versus coding was always [75:29] you know pair programming to start with [75:32] um how has that you know we we sort of [75:36] joked before but I you know we weren't [75:38] really joking that um AI is actually [75:40] creating jobs I'm curious how do you [75:42] turn that narrative on its head that [75:44] folks are just losing their jobs right [75:46] like do you see the upleveling of folks [75:49] folks with AI where you know maybe they [75:51] were doing this job and now they're [75:52] doing something else. [75:53] >> Yeah. I mean we we we see this all the [75:55] time. Uh because uh if you recall [75:59] earlier on when we were talking about [76:00] okay what are we truly doing? Um, we [76:03] found that in a for a lot of our [76:05] customers, there's actually just more [76:08] demand for things like customer support [76:12] than there's supply, [76:13] >> right? [76:14] >> Where companies realize that they're [76:17] like, okay, if our cost of doing [76:20] customer support drops by 30%. Most of [76:24] them are not just immediately saying, [76:25] okay, now what I will do is, you know, [76:27] let go of 60% of my team. They're saying [76:30] okay now that this thing which is [76:31] clearly valuable for my customers is [76:33] much cheaper let me do more of it [76:36] >> so that my customers retain for longer [76:39] so that you know they don't turn off as [76:40] much so that they activate sooner things [76:42] like that [76:44] >> you know we had a customer in the early [76:45] days um they and this was you know [76:48] probably two and a half years ago at [76:50] this point um where they said you know [76:52] our ticket volume you know the amount of [76:55] customer support inquiries that we get [76:57] uh per month was I I think I think it [77:00] was like 50,000 a month or something [77:01] based on uh you know the existing [77:04] surfaces that they had. Once they [77:06] started using us they said wow turns out [77:09] our customers have a lot of problems [77:11] they said let us make support more [77:13] easily accessible right so instead of it [77:15] just being in one part like buried [77:18] within a support panel. They're like [77:19] let's put support on every page and [77:21] let's make it more prominent in places [77:23] where people are more likely to get [77:24] stuck. Let's allow immediate support for [77:28] even free users rather than only paying [77:30] users. Right. So because of this kind of [77:34] >> there's more kind of latent demand for [77:36] support. Yeah. [77:36] >> Uh than there is supply. So [77:38] >> automating things doesn't necessarily [77:40] result in just kind of people laying off [77:43] their entire teams. [77:44] >> That may be the best example of Jeban's [77:46] paradox in real life that I've heard. So [77:48] it's exciting. [77:48] >> Yeah. I think it's like uh AI will uh [77:50] kill jobs but not careers in a way [77:53] because like those jobs that are being [77:55] done currently should not be done by [77:57] humans. Like they're very mundane and [77:59] menial. It's like it's like a super high [78:01] volume use case and people are just like [78:03] kind of picking up the phone. I was [78:04] like, "Okay, let me click here, click [78:05] here, and like, okay, here's the answer, [78:07] right?" And that should be done by AI. [78:09] But there is actually like a near [78:11] infinite amount of things that people [78:13] could be doing to make their customers [78:15] happier and, you know, take care of them [78:16] more. And so people will end up doing [78:18] those things and more and more of the [78:21] mundane repeatable things will get eaten [78:23] up by AI. So that that's that's what we [78:26] think will happen. Jesse, I think on a [78:28] podcast, maybe Patrick Oshanosy's [78:29] podcast a couple months ago, you had [78:31] mentioned that even your customers [78:34] when they've been using BPOS for [78:36] customer support instead, you haven't [78:38] actually seen like layoffs at the BO. It [78:40] just turns out that those employees have [78:41] gone and done other things instead. Is [78:43] that still true? [78:44] >> Oh, uh, I mean, it's it's it really [78:48] depends on the situation. So, there are [78:50] definitely scenarios where people use [78:52] their BPOS a lot less or don't need the [78:54] BO anymore. There are other situations [78:56] where they are not in cost cutting mode [78:59] whatsoever and their [clears throat] [79:01] goal is to either their business is [79:03] growing so quickly that they don't want [79:05] to scale their operations along with [79:06] their growth and so with Dakon they can [79:09] kind of like keep it flat or whatnot or [79:12] it's yeah actually we still need people [79:14] but now there's all these other things [79:16] they could be doing and it could be more [79:18] re revenue generating things. um you [79:20] know as [clears throat] that's like a [79:23] big area for for us even is like as the [79:25] AI matures you first start with these [79:27] cost cutting use cases because those are [79:29] easy but then like revenue generating [79:32] use cases should also be able to be done [79:33] through this conversational interface so [79:36] yeah there's it really depends on the [79:38] customer but um you know we definitely [79:39] have customers that have made massive [79:41] changes [79:41] >> actually I'd like to end it on that [79:42] uplifting note um and just to repeat [79:45] what Jesse said it may kill jobs but not [79:47] careers I love that um thank you so for [79:50] joining us, guys. A pleasure to have [79:51] you. [79:51] >> Thanks for having us. [79:54] [music]