Anthropic Hand-Offs Execution Frameworks to Standardize AI Platform

Anthropic开放执行框架以推动AI平台标准化 Anthropic正在解耦其智能体执行栈并公开内部meta-harness策略，以在多智能体AI生态系统中推动开放标准。 Katelyn Lesse和Angela Jiang概述了Anthropic的开发者平台策略，该策略平衡了内部快速迭代与外部深度企业集成。她们详细介绍了由知识层、执行层和协调层组成的三层架构模型，旨在促使开发者从构建底层基础设施转向更高阶的智能体策略。相比封闭生态，Anthropic更强调模型上下文协议（MCP）等开放生态标准以及多合作伙伴沙盒执行，同时将执行框架与Claude模型家族紧密耦合。最后，讨论重点指出了向Token合理化、Claude Tag等组织级智能体框架的转变，以及将Token分配给执行、反思和咨询路由等专业功能任务。 Anthropic 将其开发者平台划分为知识层、执行层与协调层三层架构，打通内部工具与外部 API 基础设施，推动应用从无状态 API 向长时运行的 Agent 演进。 (6:00) Anthropic 秉持开放生态理念，与 Modal、Vercel、Cloudflare 合作支持自托管沙箱，并通过开源的 Model Context Protocol（MCP）实现 Claude 与第三方 Agent 间的跨平台互操作。 (15:00) 新推出的 Claude Tag 被定义为“组织级 Harness”，通过将深度上下文工程与 Agent 架构嵌入 Slack 或 Teams 等工作流，让非技术员工无需在多工具间跳转即可处理复杂事务。 (22:26) Agent 的开发重心正在从底层脚手架微调转向高阶 Meta-Harness 策略，通过为每个 Token 分配执行、反思或评审等专门职责，并在 Claude 模型家族内深度调优以实现最高的单位成本收益。 (26:04)

Anthropic platform leaders Katelyn Lesse and Angela Jiang argue that scalable AI development requires an open, modular ecosystem rather than a walled garden. Their approach pairs open interoperability standards like the Model Context Protocol with managed execution layers and specialized token coordination strategies. Three Operational Layers for Agent Abstraction (6:00) Anthropic structures its developer platform into three modular layers to prevent builders from repeatedly engineering redundant infrastructure for state and context management. At the base, the Knowledge Layer manages model inputs via the Messages API, prompt caching, tool calls, skills, and memory. The Execution Layer transitions agents from knowing to doing by offering managed sandboxes, state preservation, and session transcript storage, integrating with external runtimes including Modal, Vercel, Cloudflare, and Amazon microVMs. The highest tier, the Coordination Layer, governs token allocation strategies across specialized roles rather than treating tokens as uniform commodities. Lesse and Jiang explain that Anthropic maintains symmetry between its internal product tool chains and external APIs, exposing the same primitives internally dogfooded for first-party applications to outside developers. Open Protocols and Cross-Platform Interoperability (12:13) Rejecting proprietary platform lock-in, Anthropic emphasizes open standards and broad interoperability across models. Jiang draws an analogy to the historical rollout of electricity, arguing that societal transformation depended on universal standards that let anyone plug in. Central to this strategy is the Model Context Protocol (MCP), an open specification designed to let first-party and third-party tools, context, and skills circulate securely across both Claude and non-Claude multi-agent setups. This open architecture allows developers to expose MCP servers on top of managed agents, enabling cross-platform tool invocation across agent boundaries and through corporate firewalls via MCP tunnels. In legacy environments without modern APIs, such as healthcare systems, Anthropic uses Computer Use adapters to bridge connectivity gaps, while collaborating with industry peers on baseline security to counter automated execution exploits and fraud. From Scaffold Tuning to Meta-Harness Strategies (26:04) As foundational models have grown more steerable, Lesse and Jiang argue that performance gains from low-level scaffolding—such as basic prompt engineering, manual context window clearing, and prompt caching—have reached diminishing returns. High-leverage engineering now focuses on higher-order meta-harnesses that coordinate multi-agent routines and allocate specific tasks to individual tokens. Under this meta-harness framework, tokens are designated for specific operational roles: execution, reflection and memory storage, large-model advisory routing to guide smaller models, and automated grading loops. For complex workflows such as automated bug detection, Lesse highlights algorithmic strategies like best-of-N sampling, which can generate higher returns on intelligence per dollar than merely expanding model size or execution runtime. Enterprise Adoption and Token Rationalization Builder adoption bifurcates based on engineering capabilities: AI-native startups tend to build custom execution stacks directly on raw primitives, whereas enterprises and application developers prefer managed solutions like Claude Managed Agents to bypass sandboxing and compliance overhead. Jiang highlights expanding enterprise adoption into non-software sectors like automotive manufacturing, as well as conversational back-office automations like Claude Tag—an 'org-level harness' embedded directly into enterprise chat tools like Slack or Microsoft Teams. Simultaneously, unmonitored employee adoption of tools like Claude Code has prompted an industry shift from 'token maxing' to 'token rationalization.' Rather than instituting rigid usage caps that suppress internal innovation, Lesse and Jiang advise enterprises to manage AI expenditure through intelligent routing strategies and outcome-based budgets, while cultivating a product culture willing to discard outdated form factors as underlying model capabilities advance. Anthropic frames the competitive advantage of agent systems as lying in coordination strategies and open ecosystem standards rather than defensive walled gardens. However, balancing bleeding-edge multi-agent experimentation with the rigid compliance, sandboxing, and governance demands of traditional enterprises remains an ongoing platform challenge.

Anthropic开发者平台负责人Katelyn Lesse与Angela Jiang指出，Anthropic致力于构建开放协同的AI生态系统而非封闭花园，其核心战略是通过三层抽象架构与模型上下文协议（MCP）等开放标准赋能开发者。她们认为，智能体开发的创新重心正从底层的提示词与上下文微调，转向以结果和预算为约束、将Token分配为多元专业角色的高阶元调度策略。 三层抽象架构与开放生态哲学 (6:00) Anthropic的开发者平台划分为三个清晰的模块化层次。底层的“知识层”涵盖Messages API、提示词缓存、工具调用、技能与记忆等基础原语，负责向模型输入必要背景；中间的“执行层”依托Claude Managed Agents等托管基础设施，处理会话存储、状态保持以及动态沙盒运算，使模型从“知晓”过渡到“行动”；顶层的“协调层”则专注于元调度框架与策略，将非同质化的Token指派给不同专业任务。 在生态构建上，Angela Jiang以电力网络铺设需要统一标准插口为喻，强调全行业生态协作的重要性。Katelyn Lesse表示，Anthropic并不追求掌控基础设施的每一层，例如执行层便积极接入Modal、Vercel、Cloudflare及亚马逊microVM等自托管沙盒。同时，Anthropic推出开源的模型上下文协议（MCP），通过防火墙隧道技术支持私有MCP服务器连接，旨在建立跨厂商模型与智能体无缝互通的连接层，并协同行业防范网络欺诈与安全漏洞。 双北极星驱动与产品形态迭代 (1:49) Anthropic开发者平台由对内和对外两颗“北极星”共同引导：对内追求极致的研发交付速度，为内部工程团队提供高可靠的基础设施杠杆；对外则强调极端民主化，通过与AWS和Google Cloud等超大规模云厂商的原生集成，让初创团队与传统企业都能低成本搭建专属软件工作流。为防止内外部需求脱节，Anthropic坚持不搞系统双轨制，所有内部工具链原语均通过紧密反馈闭环向外部开放。 在产品构建方面，Anthropic坚持“敏捷淘汰”的研发文化，主张当底层模型能力跃迁时，应当主动废弃仅有一年历史的旧形态（如从早期对话交互转向长期运行的智能体）。Katelyn Lesse提到，针对代码生成等“重度消耗Token”且能持续激发用户生产力的工作流，团队会优先进行垂直探索。例如，新推出的企业内部工具Claude Tag表面上是嵌入Slack或Teams的交互入口，但Angela Jiang援引Andrej Karpathy的观点指出，其本质是“组织级调度套件”，核心价值在于底层的上下文工程与自主后台执行能力。 从底层脚手架转向元调度策略 (26:04) 针对高性能智能体的开发路径，Katelyn Lesse与Angela Jiang指出，尽管提示词缓存、上下文窗口清理、程序化工具调用和评估测试（evals）等底层工程细节至关重要，但随着大模型可控性的飞跃，仅靠微调底层脚手架所能获得的收益正在递减。开发者不再需要编写繁琐刻板的提示词护栏来规范模型走向。 真正的技术红利正在转移至更高维度的“元调度策略”（meta-harness strategies）。该策略将Token视为具有特定职能的数字劳动力，灵活分配给执行任务、事后反思沉淀记忆、大模型指导小模型路由，以及自动化评分复核等环节。Anthropic目前在内部提炼出约五种核心Token职能，其平台演进目标正是将这些复杂的多智能体编排封装为通用组件，使开发者摆脱繁琐的基础设施搭建，直接根据结果目标与预算约束组合调度逻辑。 垂直领域落地与Token合理化治理 在市场实践中，开发者的技术栈选择呈现分化：AI原生团队更倾向于基于底层原语自主构建执行栈，而传统行业和垂直应用开发者则青睐开箱即用的Claude托管智能体。Lesse强调，在法律与金融等高风险场景中，模型与执行层之间的领域专属验证逻辑与错误处理微调往往决定产品成败；而在缺乏现代API的医疗等传统行业中，客户正利用“计算机使用”（Computer Use）功能与遗留软件桥接。 伴随企业内部自发采用（如广泛安装Claude Code）带来的影子IT隐患，企业关注点正在从盲目的“Token最大化”转向“Token合理化”（Token Rationalization）。针对这一趋势，Lesse和Jiang主张避免实施僵硬的用量封顶，因为这会直接扼杀员工创新。她们建议在Claude模型家族内部建立紧密耦合的智能路由机制，并结合N选最佳（best-of-N）采样或反思回路等算法策略，在受控的预算边界内换取更高的任务解决效率与经济效益。 Anthropic描绘了一个去中心化、基于统一开放协议且强调元调度架构的AI平台远景。然而，面对传统企业在严格合规要求下对多智能体架构的采纳迟疑，以及异构平台智能体互联时的实际系统稳定性，如何在消除基础设施复杂度的同时满足差异化的安全与治理诉求，仍是该生态演进中需要持续验证的课题。

## Background 本期播客由红杉资本（Sequoia Capital）于 2026 年 7 月 14 日在播客平台发布，由 Sonya Huang 与 Lauren Reeder 共同主持。节目邀请了 Anthropic 开发者平台负责人 Katelyn Lesse 与 Angela Jiang，围绕构建开放生态而非封闭“围墙花园”的理念，深入拆解了 Anthropic 平台的知识、执行与协调三层架构体系及其产品哲学。 ## TL;DR 节目全面梳理了 Anthropic 开发者平台的技术进阶路径，提出了涵盖“知识层、执行层与协调层”的三层平台架构。核心要义在于未来 Agent 的最大杠杆来自协调层的“策略（Strategies）”，即不再将 Token 视为同质消耗品，而是按顾问、执行、反思和质检等职责进行细化分工。在生态策略上，Anthropic 坚定拥抱开放标准，通过开源 MCP 协议、解耦自托管沙箱（适配 Modal、Vercel 及 AWS microVMs 等）支持跨系统互联，但在模型路由与 Harness 层面则专注于深耕 Claude 家族的原生调优。此外，对谈还剖析了从无状态 Messages API 到托管式 Agent（Claude Managed Agents）的演进、组织级 Harness（如 Claude Tag）的底层上下文工程，以及企业在 Token 治理上从盲目狂飙走向策略理性化的必然趋势。 ## Atmosphere & style 整场对谈洋溢着硅谷顶尖工程团队特有的前沿感与从容笃定，既有极高抽象维度的系统架构美学，又充满扎根底层一线的实战洞察。两位嘉宾言简意赅、配合默契，将原本晦涩的 Harness 底层工程与调度逻辑借由“电力革命”与“三层蛋糕”等生动隐喻拆解得举重若轻。主持人的提问直击行业痛点与商业边界，在严谨务实的技术研讨与轻松幽默的氛围中，清晰勾勒出一幅充满理想主义又极具落地可行性的多智能体协作图景。 ## Bulletin - `00:00` Anthropic 将其开发者平台梳理为“知识层、执行层、协调层”三层架构，目前核心研发重心正向最顶层的协调层演进，探索通过“策略（Strategies）”或元 Harness 实现 Token 的角色专业化分工。 - `15:39` 在生态定位上 Anthropic 拒绝构筑全栈闭环，通过推出自托管沙箱（适配 Modal、Vercel、Cloudflare 及 AWS microVMs）和开源 MCP 标准解耦基础设施，仅在与底层模型深度绑定的 Harness 设计上保持针对 Claude 家族的专有调优。 - `20:00` 内部践行“用后即弃”的高速形态探索文化，垂直场景（如金融、法律、编程）选择重点锚定具有深度交织迭代流的“Token 密集型”场景，而非单次交付即离场的事务型任务。 - `43:24` 行业正由盲目追求调用的“Token 狂飙”迈向“Token 理性化”，Anthropic 认为除换大模型和拉长运行时间外，通过协调策略（如 Best-of-N）在多模型间分配职责是极具不对称收益的第三增长杠杆。 ## Key takeaways - `03:54` Anthropic 坚持对内对外一致的平台哲学，避免为内部业务设立特权接口，通过原语民主化应对快速过时的应用产品形态。 - `06:00` 开发者平台从早期的无状态 Messages API 升级为托管式 Agent 基础设施，重点承担安全沙箱管理与会话状态维护等复杂工程。 - `10:00` 三层蛋糕模型奠定演进基础：底层知识层聚焦认知模式与参数规范，中层执行层提供沙箱和文件系统级修改，顶层协调层负责任务编排。 - `11:09` 协调层的核心假设是“Token 并不具备同质可替代性”，应当按职责划分为出谋划策（Advising）、实际执行（Executing）、反思沉淀（Reflecting）和评分校验（Grading）。 - `15:00` Anthropic 提出电力公用事业隐喻，认为变革性技术依赖全行业通用的标准插座与配电网，因而将 MCP 与 Skills 作为开放标准交付社区。 - `15:39` 执行层支持深度解耦，代码运行在何处并不关键，Anthropic 关注的是 Agent 架构是否健壮，并以 MCP Tunnels 解决跨内网防火墙访问问题。 - `17:12` 垂直产品研发具备双重逻辑：既是探索颠覆性人机交互形态（如 Claude Design 去除繁琐微调、纯靠自然语言驱动代码生成）的试验场，也是检验商业 TAM 的载体。 - `20:00` 战略倾斜于高粘性的“Token 饥渴型”场景（如 Coding），利用持续反馈闭环激发用户“还想做更多”的探索欲。 - `22:26` Claude Tag 的本质并非表层的 Slack 机器人，而是融合了主动感知、系统连接与全局上下文工程的“组织级 Harness”。 - `26:04` 大模型的可引导性提升使得许多旧式硬编码引导脚手架可被直接剔除，Harness 的新使命是构建让模型运行周期更持久稳定的元策略环境。 - `30:00` 垂直特定领域不存在通用通吃型 Harness，金融和法律等场景的核心壁垒在于末端执行动作的错误处理与领域特定校验逻辑（Verification Logic）。 - `33:05` Claude Managed Agents 的长期终局是实现彻底抽象化，开发者仅需定义预期结果与预算上限，无需微调底层管线即可自动完成目标。 - `37:05` 前沿开发者正在利用 Computer Use 绕过老旧遗留系统的 API 荒漠，甚至通过给 Agent 封装 MCP 接口来实现异构多 Agent 之间的模块化跨平台调用。 - `40:00` 在模型路由选择上，Anthropic 坚决深耕 Claude 家族内部的精细分流与调优，反对脱离模型特性的通用底层跨供应商路由器。 - `40:00` 面对企业的 Token 支出焦虑，应借鉴云计算时代治理 AWS 账单的经验建立动态护栏与任务分流，而非采用一刀切的硬性限额扼杀一线创新。 - `43:24` 将学术界的 Best-of-N 等策略工程化落地能极大提升单位成本的智能密度，Anthropic 旨在将复杂的策略协调机制转化为开箱即用的模块。 - `46:04` 平台必须同时兼顾两类开发者画像：为企业提供满足合规审计的自托管可插拔能力，为独立极客提供高度自由 Hack 的组合式原语基石。 ## Detailed walkthrough ### `00:00` 协调层与“策略”元框架：代币分工的未来构想 在 Anthropic 的设想中，平台架构最顶层的抽象是“协调层”（Coordination Layer）。这一平台整体可以清晰划分为三层：知识层（Knowledge）、执行层（Execution）与协调层。在协调层之上，团队正在探索一种被称为“策略”（Strategies）的机制，其本质类似于一种元治理框架（Meta-Harness）。传统的底层 Harness 专门针对具体执行任务设计，而元框架则着眼于代币（Token）的异构性与专业化分工。当 Token 之间不再是等同且同质化的，模型就需要扮演不同角色：某些 Token 负责出谋划策与建议，某些负责实际执行，还有一些用于反思评估或记忆沉淀。这种编排策略构建于知识与执行之上，使得复杂的智能体协作成为可能。 如果审视 Anthropic 开发者平台的演化蓝图，其抽象能力正沿着这一路径稳步推进：从最底层的知识层，向上拓展至执行层，最终全面迈向顶层的协调层。红杉资本的 Sonya Huang 与 Lauren Reeder 在开场中指出，Katelyn Lesse 与 Angela Jiang 所领导的正是当前 AI 生态中最核心的开发者平台之一——它不仅承载着全球外部开发者的系统，同时也是 Anthropic 内部各类产品运行的底座。 ```mermaid flowchart TD accTitle: 开发者平台三层抽象架构 accDescr: 展现知识层、执行层与协调层三层结构的示意图 subgraph Coord["协调层 (Coordination Layer)"] S["策略元框架 (Strategies / Meta-Harness)"] R["代币专业化分工 (建议 / 执行 / 反思 / 记忆)"] S --- R end subgraph Exec["执行层 (Execution Layer)"] H["执行 Harness & 智能体上下文"] SB["安全沙箱与持久化会话"] H --- SB end subgraph Know["知识层 (Knowledge Layer)"] M["Messages API 与模型参数设计"] K["Claude 认知模式与交互原语"] M --- K end Coord --> Exec Exec --> Know ``` --- ### `01:49` 双北极星准则：内部极速杠杆与外部生态赋能 对于一个同时服务企业内外部的平台团队而言，Anthropic 拥有两个相互独立的“北极星”目标。团队开玩笑称这就像一个“双行星系统”。对内，平台的目标是为内部产品团队提供极致杠杆，支撑他们以最快速度交付具有“AGI 属性”（AGI-pilled）的前沿产品。内部业务极其强调迭代速度与敏捷性，底层的稳定可靠是支撑团队快速试错的前提。 而在对外维度上，团队的北极星则是为全球所有开发者提供与 Claude 协作的基石工具，让他们能够随心所欲地构筑任何应用。这一愿景落地为两大核心实践： - **深度贴近业务场景**：与大型云厂商（如 AWS、Google Cloud 等超大规模云服务商）展开深度原生集成，让模型能力直接触达企业现有的工作流与云基础设施。 - **释放定制化软件的生产力**：在传统软件开发中，最后一英里的定制化软件往往受限于高昂的人力成本而无法实现。AI 彻底扭转了这一经济模型，Anthropic 致力于提供灵活的原语（Primitives）与高阶抽象，让企业能够经济高效地实现定制化开发。 - **践行开放标准**：诸如 MCP（Model Context Protocol，模型上下文协议）与通用技能定义（Skills）等关键组件，并没有被作为私有护城河封闭起来，而是直接开源并推向整个行业，赋能所有开发者最大化释放 Claude 的智能潜力。 --- ### `03:54` 平台一致性哲学：拒绝信息茧房与形态民主化 许多科技巨头往往会将内部基础设施与对外商业 API 彻底隔离开来，但 Anthropic 坚持“对内对外一致性”的平台哲学。无论内部团队还是外部客户，虽然具体业务诉求略有差异，但平台层坚持提供完全一致的基础原语，避免为内部特权需求开辟专用通道。 这种取舍背后是对模型演化节奏的深刻洞察。大模型的能力正在呈指数级跃迁，任何固化的产品形态（Form Factor）都极其短命：两年前整个行业普遍认为“一切应用的终局都是对话框（Chat）”；而如今行业共识已经转向“忘掉对话，一切皆是智能体（Agents）”。未来必然还会诞生全新维度的交互形态。面对这种不确定性，平台不应由单一团队去垄断并规定某种标准形态，而是要通过原语的民主化，把探索权交给整个市场。 在实践中，团队高度警惕“闭门造车”式的内部测试（Dogfooding）。如果仅仅根据内部工程师的偏好来封装高级功能，极易陷入过度拟合局部需求的陷阱。因此，Anthropic 在内部验证新工具与高阶抽象的同时，通常会同步面向外部客户开放早期体验（Early Access），通过广泛且多元的真实反馈对平台功能进行校准。 --- ### `06:00` 从无状态 Messages API 到托管式 Agent 基础设施 回溯至一年前，Anthropic 的开发者平台主体实际上非常精炼，核心就是无状态的 Messages API，辅以基础的 SDK、文档、控制台以及 MCP 规范。然而，随着 Claude 模型在长时程运行（Long-running execution）和超大上下文处理上的能力出现质的飞跃，开发者与内部团队开始遭遇高度重合的复杂痛点：如何在无需人工持续介入（Human-in-the-loop）的远程环境中，维持一个长生命周期 Agent 的稳定运行？ 为了消除开发者反复造轮子的负担，平台开始将分散的原语封装为开箱即用的高阶抽象，核心解决两大维度的难题： - **复杂运行时基础设施（Infrastructure）**：自动管理具有企业级安全合规治理能力的计算沙箱（Sandboxes），实现按需瞬间唤起与销毁；提供会话转录与状态存储机制，支持长任务随时中断并无缝恢复。 - **Harness 工程化与成本优化（Harness Engineering）**：将 Prompt 缓存机制（Prompt Caching）、上下文窗口动态管理（Context Window Management）以及激发模型高阶推理能力的实践打包内置，帮助开发者在压低调用成本的同时榨取极致智能。 在这些产品推出后，用户群体展现出了清晰的分流特征：底层极客与 AI-native 原生初创公司更倾向于直接调用原子原语，以保留对系统每一处细节的微调掌控力；而传统企业或聚焦特定业务流的产品团队，其核心竞争力在于连接业务工作流并提供垂直用户价值，无需在底层算法优化上盲目爬坡，因而会毫不犹豫地全面拥抱托管式 Agent（Managed Agents）解决方案。 --- ### `07:18` 平台架构的三层蛋糕模型 Angela 将 Anthropic 的技术架构具象化为一个“三层蛋糕”（Three-Layer Cake）。最底层的基石是**知识层（Knowledge Layer）**。 在这一层，核心聚焦于理解模型本身的认知特质及其运作规律——即“知晓如何实际驱动 Claude 开展工作”。知识层的许多原语属于相对成熟、经过反复打磨的沉淀项，例如 Messages API 中精细设计的各种数据结构、请求参数与输入规范。这些设计并非通用的抽象接口，而是高度贴合 Claude 模型的深层思考架构与推理模式，旨在以最原生的方式表达其智力逻辑。在这一稳固基石之上，才得以进一步向上生长出执行层与更高阶的协调层。 ### `10:00` 从知识层到执行层：三层架构的演进 在回顾过去一年多的技术路线时，Angela Jiang 将 Anthropic 的开发者平台抽象梳理为一个清晰的三层架构：知识层（Knowledge Layer）、执行层（Execution Layer）和协调层（Coordination Layer）。最初，团队主要在知识层进行标准化探索，包括模型对特定参数的遵循方式、工具调用（Tool Calls）机制，以及随时间动态注入上下文的组件（具体体现为 Skills 和 Memory）。这些抽象解决了模型“知道什么”的问题，让用户能够提问并获得解答，或是将分散的信息串联在一起。 然而，团队越来越多精力转向了更高维度的执行层。正如 Katelyn Lesse 此前探讨的抽象提升，当目标变成让 Claude 真正去“交付工作”而不仅仅是“掌握知识”时，复杂度发生了质的飞跃。在执行层，Agent 需要生成最终产出并在多个异构系统中编辑和修改文件，这需要底层基础设施的强力支撑。Anthropic 将这一层的核心抽象定义为“底层运行框架（Low-level Harness）加托管基础设施（Managed Infrastructure）”，目前对外推出的高级形态即为 Claude Managed Agents，团队正逐步将更多复杂能力封装进该产品中。 ```mermaid flowchart TD accTitle: Anthropic 的三层平台抽象架构 accDescr: 展示从知识层到执行层再到协调层的技术进阶路线 subgraph Coordination["协调层 (Coordination Layer)"] Strategy["策略 (Strategies) / Meta-Harness<br/>Token 分工: 建议、执行、反思"] end subgraph Execution["执行层 (Execution Layer)"] Harness["底层 Harness + 托管基础设施<br/>Claude Managed Agents / 文件多系统跨域编辑"] end subgraph Knowledge["知识层 (Knowledge Layer)"] Base["工具调用标准 (Tool Calls)<br/>动态上下文: Skills 与 Memory"] end Base --> Harness Harness --> Strategy ``` ### `11:09` 协调层与“策略”路线图：Token 的角色分工 在执行层之上，Anthropic 正在探索并逐步构建最顶层的协调层。尽管目前团队只是以不太显眼的方式暴露了部分能力，但其核心构想是一种被称为“策略（Strategies）”的机制，本质上是一个“元运行框架（Meta-harness）”。如果说底层的 Harness 是专门为了具体执行而设计，那么协调层则是为了解决 Token 角色分工的问题——因为“Token 并不是同质可替代的（Tokens aren't really fungible）”，每一个 Token 在系统流水线中应该承担不同的职责。 在这种协调机制下，一部分 Token 专门负责提供咨询建议（Advising），一部分负责具体落地执行（Executing），还有一部分负责发散思考与反思构想（Dreaming/Reflecting）。开发者需要将这些经过编排的策略组合在一起。因为归根结底，高阶策略仍需驱动具体执行，而执行又依赖于具体的知识输入，所有层级在理论上都必须层层咬合。从 Anthropic 未来的产品路线图来看，整个平台的演进轨迹就是坚定地从知识层推向执行层，再从执行层全面迈向协调层。 - **Token 的异构职责划分**：突破单提示词全包的局限，让不同计算步骤承载咨询、执行或反思任务。 - **架构层级联动**：协调层（Strategies）提供调度顶层设计，执行层（Harness + Infra）负责落地交互，知识层（Skills + Memory）提供基础事实与上下文。 ### `12:13` 生态系统与开放标准：MCP 与跨 Agent 协作 当被问及这些技术组件如何走出 Anthropic 自身的产品闭环、赋能外部开发者生态时，Angela Jiang 强调团队的核心诉求是“尽可能为所有开发者提供坚实的基础原语”，而不是建起封闭的高墙。无论是在知识、执行还是协调层，团队都希望将这些构建块开放给行业，让创业公司能够自由构筑自己的产品乃至 Agent。对于 Anthropic 自身而言，虽然团队也在打造第一方产品，但同时推出了基于 MCP（Model Context Protocol）规范构建的原生连接器（Connectors），保持接口的高度开放与标准化。 Angela 描绘的终极愿景是一个具备高互操作性与可交易性的多 Agent 生态系统：任何一家企业所构建的 Agent，不仅能与 Claude 驱动的 Agent 无缝协作，也能与其他第三方模型驱动的 Agent 相互调用、顺畅通讯。而要让这个生态运转起来，跨系统的标准制定不可或缺。除了基于 Skills 和 MCP 的协议互通外，更高维度的标准在于“安全协同”。面对网络安全（Cybersecurity）和防欺诈等严峻挑战，任何平台都不希望技术被恶意攻击者滥用，整个行业必须在关键基础设施防护和安全标准上达成共识与联防。Anthropic 正积极与业界各方展开合作，共同探索并建立这些关键的行业标准。 - **开放连接器规范**：Anthropic 深度依托开源的 MCP 协议打造 Connectors，支持第三方系统与内部第一方产品双向接入。 - **无壁垒 Agent 互联**：打破模型孤岛，不仅支持 Claude Agents 之间的配合，更致力于实现 Claude 与非 Claude Agents 之间的顺畅通信。 - **行业级安全防御标准**：在互操作协议之上建立安全协同防线，重点防范网络攻击、欺诈及对底层基础设施的恶意入侵。 ### `15:00` 电力隐喻：生态系统与标准化插座 谈及技术变革的底层逻辑时，团队退后一步，将人工智能比作电气化革命。在电力普及之前，人类只能依赖烛光，能做的事情极其有限；而电力之所以能够成为改变整个人类社会运行方式的通用公用事业（utility），核心在于它能被“接入并布线到一切事物之中”，让每个人都能平权地获取这种动力。 更重要的是，电气化革命不仅需要发电机，还需要统一的标准插座、变压器和配电网。这种庞大的底层设施绝非任何单一商业实体能够凭一己之力垄断或完成的，必须依赖全行业的开放生态与跨界伙伴协作，共同探索出一条互联互通的前行路径。这一视角构成了 Anthropic 思考开发者平台哲学的基石：与其试图构筑全封闭的护城河，不如致力于定义清晰的标准与接口。 - **电力的变革性本质**：不仅在于能源本身的强大，更在于标准化的接入机制让全社会都能即插即用。 - **生态协作的必然性**：没有任何一家公司可以独自为整个世界“铺设电线”，必须与广泛的生态系统伙伴携手推进。 --- ### `15:39` 开放生态 vs 围墙花园：基础设施的解耦与架构强观点 针对红杉资本合伙人关于“究竟是构建开放生态还是围墙花园（walled garden）”、以及“哪些产品必须由第一方掌控、哪些完全乐意交由第三方生态负责”的追问，团队回顾了此前探讨的“三层蛋糕”架构（知识层、执行层、协调层）。在执行层（Execution Layer）以及如 Claude Managed Agents 等能力的设计上，Anthropic 表现出极高的开放度与解耦意向，团队明确表示：“我们并不固步自封地认为，这些代码必须跑在我们的基础设施上，或者沙箱与存储层必须由我们全权把控。” 这种哲学的落地成果是高度模块化的：Anthropic 正式推出了自托管沙箱（Self-hosted Sandboxes），深度集成了 Modal、Vercel、Cloudflare 等合作伙伴的算力环境，甚至是 Amazon 全新的 microVMs（微虚拟机技术），将其作为平台的一等公民。同时，他们推出了 MCP 隧道（MCP Tunnels），允许开发者安全地穿透企业内网防火墙，直接与内网部署的 MCP 服务器进行通信。Anthropic 关注的重心并不在于算力到底由谁计费或代码跑在哪台机器上，而是如何搭建出一套真正可靠、强大且具备弹性的 Agent 架构：“我们在架构理念上有着极强的见解（strong opinions），只要开发者符合我们开放的标准接口，把任何外部模块插进来，整套系统就能运转得极其顺畅。” ```mermaid flowchart TD accTitle: Anthropic 开放式执行层与解耦架构 accDescr: 展示了 Claude 架构规范如何与外部自托管沙箱、内网 MCP 服务器及第三方基础设施无缝对接。 subgraph AnthropicCore["Anthropic 架构核心与接口规范"] direction TB Spec["Agent 架构规范 & 协调逻辑"] Router["标准接口协议 (MCP / API)"] Spec --> Router end subgraph ExternalExecution["开放式执行环境 (自托管沙箱)"] direction TB Modal["Modal"] Vercel["Vercel"] CF["Cloudflare Workers"] AWS["Amazon microVMs"] end subgraph InternalInfra["企业私有基础设施"] direction TB Tunnel["MCP Tunnels 穿透组件"] Firewall["企业级内网防火墙"] PrivateMCP["私有 MCP 服务 & 数据库"] Tunnel --> Firewall --> PrivateMCP end Router --> ExternalExecution Router --> Tunnel ``` - **基础设施去中心化**：支持开发者将计算与存储无缝迁往第三方环境，Anthropic 主动放弃全栈掌控的控制欲。 - **生态合作伙伴矩阵**：已深度适配 Modal、Vercel、Cloudflare 及 AWS microVMs，建立开箱即用的原生集成。 - **防火墙穿透机制**：通过 MCP Tunnels，使云端模型能够安全连通企业内部私有 MCP 节点。 - **架构哲学**：“代码跑在谁的机器上并不重要，重要的是 Agent 的装配架构是否健壮、可靠且具备扩展性。” --- ### `17:12` 动态形态与抛弃文化：用垂直产品探索模型表达极限 在探讨 Anthropic 何时会亲自下场做垂直场景产品时，团队阐释了内部的两个决策框架。第一个关键框架是“探索不断演进的产品形态（form factor）”。Anthropic 内部坚信产品形态绝非一成不变，而是具有高度动态性的生命周期——在当前这一年 AI 能力下堪称惊艳的交互界面，到了下一年可能就会彻底落伍。因此，团队在内部时刻保持着自审心态，员工们甚至经常半开玩笑地互相追问：“这东西究竟够不够‘被 AGI 脑控’（AGI-pilled enough）？”他们崇尚一种“打造出很酷的东西、运行一年、随后果断扔掉重来”的迭代文化，并坦承很多时候推出垂直产品不是为了去争夺最大的总体潜在市场（TAM），而是为了向业界示范：当底层模型能力跃升时，人机交互的载体完全可以用截然不同的方式呈现。 以“Claude Design”为例，表面上看 Anthropic 似乎在进军垂直设计领域，但其背后的真实动因是验证两个颠覆性的交互假设：第一，全面卸载控制权给模型。它刻意减少了传统设计工具中繁琐的手动微调交互，态度鲜明地鼓励用户“直接跟 Claude 对话，放手让模型去理解并搞定一切”；第二，用纯代码生成击碎传统“所见即所得”（WYSIWYG）的设计套路。市面上绝大多数 AI 设计或 PPT 生成工具，都死板地套用现成的设计组件系统，而 Claude Design 尝试完全依托模型底层实时编写代码来驱动视觉呈现。这种极具破坏性的实验在 Anthropic 的 Labs 团队内部极为普遍：团队会高强度试验某个新概念，内部疯狂试用两周觉得“酷毙了”，然后甚至根本不对外发布，便迅速转身跳入下一个前沿形态的探索中。紧接着，团队也指出了另一面：作为一家商业公司，在形态探索之外，他们同样有着严肃审视商业 TAM 的第二套产品衡量逻辑。 - **形态动态论**：坚决摒弃固定界面的执念，认为适应今年模型能力的产品形态，在下一年大概率需要被彻底重构。 - **“AGI-pilled”与抛弃文化**：鼓励团队和平台开发者不沉溺于过去的阶段性成功，敢于推倒自研产品并持续探索极限。 - **Claude Design 的核心试验点**： - *控制权反转*：弱化微操界面，引导用户以自然语言对话为核心控制流。 - *代码即设计*：不依赖僵化的设计库组件，通过端到端生成代码来颠覆传统的 WYSIWYG 视觉工具生态。 - **Labs 团队的实验节奏**：大量前沿产品形态在内部仅经历两周的高强度迭代验证，随后即被下一代设想迭代替代。 ### `20:00` 垂直化落地与选择“Token 密集型”场景 Anthropic 在评估垂直业务场景时，首要考量的是潜在市场规模（TAM）以及该领域是否存在合理的智能体协作（Agentic operations）空间。不过，团队在战略选择上存在一个显著的偏好——倾向于那些“Token 密集型（Token-heavy）”或“Token 饥渴型（Token-hungry）”的场景。所谓的 Token 密集，关键不在于单次调用消耗了多少 Token，而在于当用户结束这一轮交互（Turn）时产生的情感与心理反馈：“我是已经搞定收工了，还是由衷地觉得‘这太棒了，我还想继续做更多’？”如果用户的回答是“我想接着做更多”，这就是 Anthropic 最青睐的赛道。 代码编程（Coding）就是最典型的例证。在写代码时，一次成功的生成不会让用户离开，反而会瞬间打通思路，激发“我被解放了，我要构建更多、生成更多”的冲动，形成一种深度交织的迭代流（Iterative flow）。反观某些事务性服务，用户单轮操作完成后目标即已达成，便直接离场。除编程外，Anthropic 也公开将触角延伸至金融（Finance）和法律（Legal）等垂直领域。团队希望赋能具体的业务买家（Buyer），帮助他们优化工作流。Anthropic 的策略是通过提供上下文、工具与形态契合的产品，向外界展示“可能性的艺术（The art of the possible）”： - **多层级接入路径**：开发者既可以直接调用底层的 Messages API 自行搭建所有逻辑，也可以使用 Claude Managed Agents 开箱即用的高级托管能力。 - **现成连接器与技能包**：以推出的 Claude for Financial Services 为例，团队打包了预设技能（Skills）与连接器（Connectors），既可在 Anthropic 自己的产品内使用，也能嵌入第三方产品。 - **开源食谱指南**：发布官方 Cookbooks，手把手示范如何利用 Claude Managed Agents 完成端到端的特定业务闭环。 --- ### `22:26` 冰山之下：Claude Tag 与“组织级 Harness” 随着 Shopify 开发了内部智能体平台 River、Block（原 Square）推出了 BuilderBot，业界各家企业纷纷尝试为内部智能体注入全局上下文并接入日常协作平台。Anthropic 顺势推出了内部研发的集成封装产品——Claude Tag。针对外界部分声音将其戏称为“不过就是个 Slack 机器人（Just a Slack bot）”，团队指出这种看法完全停留在表层交互形态上。过去人们习惯于执着在 UI 和外壳形式，但 Claude Tag 的核心绝非仅仅是“在 Slack 里 @ 一下”。 ```mermaid flowchart TD accTitle: Claude Tag 架构分层 accDescr: 展示 Claude Tag 表层多平台交互与底层组织级 Harness 及上下文工程的对应关系 subgraph Surface["表层协作入口（随时可替换的冰山一角）"] Slack["Slack 频道 / @Claude"] Teams["Microsoft Teams"] Text["WhatsApp / 短信 / 邮件"] end subgraph Iceberg["冰山水下：组织级 Harness（底层硬核架构）"] ContextEng["全局上下文工程 (Context Engineering)"] Proactive["主动感知与介入 (Proactivity)"] OrgTools["内部系统连接器 (报销 / HR / 文档 / 权限)"] end Surface --> Iceberg ``` 真正的技术壁垒在于水面之下的“上下文工程（Context Engineering）”与底层架构。正如 Andrej Karpathy 所精准定义的，它是一个“组织级 Harness（Org-level harness）”。在日常场景中，非技术员工可能仅在 Slack 里拉个群，发一句“我不知道怎么提销报表”，以往他们需要在 Wiki、主管与入职导师（Buddy）之间到处询问，而现在 Claude Tag 能主动感知意图、调取上下文并执行操作，如同一个经验丰富、全天候在线的新同事。 - **去形态化适配**：Slack 只是当前企业协作的高频入口，未来这一交互层完全可以无缝置换为 Microsoft Teams、WhatsApp 群组、短信甚至传统邮件。 - **拟人化隐形助手**：智能体最前沿的演进趋势反而呈现出一种“看似无趣（Boring）的自然状态”——不强求奇特花哨的专属 UI，而是直接入驻人类已经建立的沟通渠道，成为随时能够调动全部业务上下文的高智力协作者。 --- ### `26:04` 从底层脚手架到“元 Harness”与 Token 策略 谈及构建顶尖智能体所需的 Harness（执行载具/运行框架）最佳实践，Anthropic 认为基础工程必须扎实且克制。Claude Managed Agents 之所以具备高性能，是因为帮开发者处理了大量枯燥但致命的底层杂活：比如提示词缓存（Prompt Caching）、上下文窗口维护（及时淘汰旧会话保持 Context 纯净）、工具的编程式按需调用（避免将不必要的数据硬塞进上下文窗口）以及严谨的 Evals（评估基准）。 更重要的是，业界的范式正经历代际变迁。两年前的大模型如同缺乏自律的野马，Harness 必须充当坚固的脚手架，在左右两边强行立起高墙才能让模型走出一条直线；而如今的模型具备极高的可引导性（Steerable），许多原先复杂的 Harness 引导逻辑完全可以通过一段精准的 System Prompt 替代——团队甚至经常主动建议开发者“大胆删掉这些多余的脚手架代码”。 当下 Harness 真正的技术杠杆正从底层基础管理迁移至更高维度的“策略（Strategies）”或“元 Harness（Meta-harnesses）”。其核心逻辑在于：**如何赋予每一个消耗的 Token 不同的职能分工？** | Token 角色类型 | 具体职能与运行机制 | 核心价值 | |:--- |:--- |:--- | | **执行者 (Executing)** | 负责最直接的工具调用与任务输出。 | 推动业务流程往前落地。 | | **反思者 (Reflecting)** | 复盘过去的智能体运行历史，提炼经验并写入长期记忆。 | 确保下一次执行的智能体表现更优。 | | **导师/顾问 (Advising)** | 由顶尖大模型担任顾问，向负责执行的小模型传授策略与步骤。 | 兼顾执行性能与高吞吐的成本控制。 | | **评分员 (Grading)** | 对执行结果进行质量打分，发现偏差直接判定“未达标，重试”。 | 闭环保证最终输出的可靠性与容错度。 | 当模型自身能够通过理解力吞噬掉过往繁琐的执行脚手架时，新一代 Harness 最关键的使命就变成了：**构建让模型能够更长周期、更持久稳定运行的执行环境（Allow it to run longer）**。深入挖掘 Token 角色分配与元策略，比在底层细节上“榨取最后一滴汁水”具有大得多的长期溢价。 ### `30:00` 策略型 Harness 与垂直领域的定制化价值 Angela Jiang 阐述了当前 Harness（测试运行底座 / 封装框架）理念的演进：随着底层模型智能水平的飞跃，开发者不再只是希望模型从 A 点走到 B 点就停下，而是期望指挥它“从 B 走到 C，再到 F、跳到 Z，最后带着结果回到 A”。为了应对这种多步骤、非线性的复杂探索，Harness 的角色已经从单纯的“方向操舵（steering harness）”升级为 Katelyn 所提到的“策略型 Harness（strategy harnesses）”。这种框架匹配了模型最新涌现的高阶推理能力，让系统能够在更高层级的思维抽象上运转。 当被问及“任务特定或垂直行业特定的 Harness 是否有必要”时，Angela 直截了当地给出了肯定答复：“并不存在万能通用的通用 Harness（general harness）。”虽然有些基础能力具备普适性——比如软件编码（Coding）几乎侵入了各行各业的每一个角落，因而写代码的能力极其通用——但在强专业领域中，Harness 必须进行深度定制。其中最核心的差异点，就在于**模型生成内容与外部环境执行动作之间的错误处理与校验逻辑（verification logic）**。 在法律（legal）和金融（finance）等容错率极低的严肃行业中，微小的幻觉或错误都会带来灾难性的商业与合规后果。在这些场景中，开发者对 Harness 最末端校验逻辑的微调与极致打磨，往往能够挤出大量的性能提升与可靠性溢出（"tweaking that last bit will give you a ton of juice"）。正是这看似微不足道的校验差异，构成了产品间决定胜负的护城河。相比之下，Angela 认为外界对单纯“上下文填充（context）”的关注有些被过度放大了；任何合格的 Harness 都能处理庞大的上下文，真正区分平庸与卓越的，是极度严苛的验证闭环以及针对高阶策略的 Token 预算智能分配能力。 ```mermaid flowchart TD accTitle: 垂直特定 Harness 的核心增益架构 accDescr: 展示通用模型能力与垂直领域在校验逻辑及 Token 预算分配上的分层关系 subgraph GeneralLayer ["通用底座层"] A["通用大模型能力 (如 Coding / 基础推理)"] B["海量上下文摄入 (Prompt Caching / 数据检索)"] end subgraph StrategyLayer ["高阶策略与调度层"] C["高阶策略 Harness (多跳规划 / 动态 Token 预算分配)"] end subgraph VerticalLayer ["垂直领域定制核心 (Legal / Finance)"] D["执行与工具调用"] E{"领域特定校验逻辑 (Verification Logic)"} F["高可靠输出 / 错误自动自愈"] end A --> C B --> C C --> D D --> E E -- "未通过验证 / 出现偏差" --> C E -- "严格合规通过" --> F ``` ### `33:05` Harness 的多层定义与 Claude Managed Agents 的终局形态 Katelyn Lesse 接过话茬，剖析了业界对 Harness 认知不一的根本原因：每个人口中的 Harness 指代的层级截然不同。对于部分人来说，它仅仅是一个原始的基础循环——`用户 -> 模型 -> 工具 -> 用户`；而对另一些人而言，它包含了随框架打包的所有工具链。Katelyn 强调，底层那些繁琐而通用的机制其实最不值得团队耗费心力去“重新发明轮子”，比如： - 如何正确实现 Prompt 缓存（Prompt Caching）的精确命中； - 如何在长程会话中定期修剪、清理上下文窗口里的陈旧工具调用记录（tool calls）。 这些繁复的底层管线应当沉淀为平台级基础设施。向上走一层，才真正进入需要开发者亲自掌控的业务策略域。Katelyn 坦言，目前 Anthropic 推出的 Claude Managed Agents（托管 Agent 服务）虽然被归类为“高阶（higher order）”，但本质上仍保留了大量可调旋钮（knobs）——开发者可以自由定义并接入自定义工具集、配置 MCP（Model Context Protocol）服务器、设定专用 Skills 以及深度定制 System Prompts。 然而，Anthropic 心目中托管 Agent 的真正终局，是彻底抽象掉所有底层机械细节。开发者未来只需向 Agent 下达极其简洁的高层意图：“**这是我想要的结果，这是我的预算上限，预备——开始！（Here's the outcome I want, here's the budget I want to spend, ready set go!）**”至于底层的调用拓扑、上下文轮转与工具调度，开发者完全不需要操心。 - **Harness 的层次划分**：从底层的 Prompt Caching、上下文垃圾回收，到中层的工具集成（MCP / 自定义 Tools），再到顶层的策略编排与预算管控。 - **差异化掌控权**：开发者应当将精力集中在能产生实质商业结果的策略优化层，而非陷入底层工程管道的维护。 ### `35:48` 平台视角观察：前沿开发者的上下文工程与权限创新 作为基础设施平台的主导者，最令人兴奋的特权之一便是能够俯瞰全球最顶尖的开发者如何在 Claude 之上构筑应用。Sonya Huang 顺势提问，Anthropic 从平台构建者身上观察到了哪些令人惊艳的新范式。 Angela Jiang 指出，许多头部团队在处理复杂上下文时展现出了极其惊艳的创意（"some really funky ways of handling context"）。Anthropic 自身在打造内部产品（例如 Claude Tag）时，就对上下文工程进行了极其深入的探索，这也是该产品表现优异的核心原因。而外部团队甚至更进一步： - **主动跨源触达**：针对散落在各类异构系统、互不连通的数据孤岛，Agent 不再是被动接收检索片段，而是具备主动探索并按需向多端抓取上下文的能力。 - **动态权限协商与聚合**：在多源异构环境下，构建者们正在设计能够跨多个系统安全、自动化生成或申请权限的流通机制，使 Agent 能够在合法合规的前提下，将分散的敏感上下文无缝融合成统一的全局认知。 这种跳出传统静态 Prompt 与基础 RAG 框框的“上下文主动治理与权限融合”，正是 Anthropic 团队目前最为振奋且重点汲取经验的创新前沿。 ### `35:00` 内部用例创新与老旧系统的上下文连接 AI 原生企业的创新往往不再单纯执着于外在的产品形态，而是聚焦于打造对实际工作流程“最大化实用”的内部工具。很多客户正在以极具想象力的方式改造内部软件开发生命周期（SDLC）或重塑整个后勤后台。特别是在上下文流动与数据串联的细节设计上，工程团队展现了极高的灵活性与构想力。 另一类极具代表性的创新则发生在医疗等深植于陈旧遗留软件（Legacy Software）的传统领域。在这些行业中，底层系统往往历史久远，甚至连基本的 API 接口都是一种奢求。面对这种“API 荒漠”，客户开始探索利用 Claude 的 Computer Use 能力来接管老旧界面、自动化繁杂工作，并尝试各种大胆实验——例如直接在一台笔记本电脑上自动化执行一整套流程并生成中间产物，以供下游智能体读取和使用。 Anthropic 团队正在全力支持这种来自客户一线的有机创新，致力于将这些非正规探索规范化： - **规范与标准支持**：通过定义标准协议，让开发者只需提供规格，Claude 就能自动遵从并规范交互。 - **无缝连接层**：推动生态从打补丁式的自动化，平滑过渡到安全、标准化的系统互联。 ```mermaid flowchart TD accTitle: Legacy Systems to Agent Connectivity Architecture accDescr: Diagram showing how legacy systems without APIs are connected via Computer Use and standardized context layers to multi-agent workflows. subgraph Legacy["遗留系统层 (无 API)"] OldSys["老旧业务系统 / 界面"] end subgraph Automation["连接与自动化层"] CU["Claude Computer Use"] DataGen["自动生成结构化上下文"] end subgraph Ecosystem["智能体生态层"] Spec["规范与协议标准 (MCP)"] Agent["下游专业智能体"] end OldSys -->|"UI 自动化接管"| CU CU -->|"导出与流式接入"| DataGen DataGen -->|"符合协议规范"| Spec Spec -->|"消费并协同任务"| Agent ``` --- ### `37:05` 多 Agent 互联：MCP 的“脑洞大开”与制造业突破 在不同模型与平台并存的实际场景中，“连接层（Connectivity Layer）”正在成为最有想象力的一环。有团队分享了一个极具代表性的案例：某客户使用 Claude Managed Agents 构建了一组智能体，同时也在其他模型和第三方平台上定制了若干智能体，各自适配不同专长。为了让这些异构智能体顺畅协同，客户产生了一个“脑洞大开（Galaxy Brain）”的设想——直接在某个 Agent 之上包装并暴露一个 MCP（Model Context Protocol）服务器接口，将该 Agent 变为一个可调用的标准 Tool，供其他 Agent 按需接入。Anthropic 团队与该客户深入合作实现了这一方案，验证了 MCP 架构在模块化与多智能体跨平台互联中的极高适配度。 与此同时，AI 应用的落地浪潮正在打破早期的“唯编程论”边界： - 编程（Coding）场景虽依然呈现爆发式增长，但应用版图已在加速向重工业蔓延。 - 制造业（Manufacturing）展现出强劲的构建需求，Anthropic 的产品经理甚至直接飞往底特律（Detroit）现场对接车企及重工制造客户，深入挖掘车间与产线背后的全新需求。 --- ### `38:40` 从“Token 狂飙”走向“Token 理性化” 随着大模型能力逐步跨过特定智能阈值，行业正经历由“Token 狂飙（Token Maxing）”向“Token 理性化（Token Rationalization）”的转折。在穷尽某一智能维度的上限后，团队自然会向下一维度优化——要么追求极致的速度，要么追求极佳的成本效益，并在各复杂度的任务分布中寻找最优性价比平衡点。 面对企业内部因成本上升而试图“紧急刹车”的做法，Anthropic 认为盲目叫停是不可取的。很多企业之所以支出失控，往往是因为员工自发通过“影子 IT（Shadow IT）”采购并大规模在内部安装 Claude Code 等重型 Agent 工具。Agent 本质上极其消耗 Token，但如果它确切换来了更快的交付速度和更高效的运营回报，这些投入便具备坚实的商业收益。企业不应压制创新，而应建立成熟的策略层： - **避免硬性阻断**：保护一线团队因 AI 带来的效率红利与工程节奏。 - **智能化任务评估与路由**：根据任务本身的复杂度进行实时判定，将高复杂度工作分配给顶级模型，低难度工作交由轻量级方案，用更具前瞻性的策略路由架构替代粗暴的权限封堵。 ### `40:00` 模型路由哲学与成本管控的自然演进 关于模型路由（Model Routing），Angela Jiang 与 Katelyn Lesse 阐述了 Anthropic 的独特定位。对于复杂的任务场景，开发者自然倾向于用规则来分流：把高难度、复杂的任务交给最聪明的超大模型，把相对简单、机械的环节路由给低成本的小模型。这在工程上虽然具备一定的技术复杂度，但完全可行且值得鼓励。然而，Anthropic 坚持平台必须深度聚焦于 Claude 模型家族本身，而不是成为跨不同供应商大模型的通用路由器。他们坚信，Agent 的 Harness（执行驾驭层/脚手架）必须与其底层的模型家族深度适配与微调。早期行业曾流行在底层随意切换不同供应商的模型，但如 Vercel 推出 Harness Agent 一样，行业抽象层正在向上移动，更合理的范式是把整套与特定模型家族紧密耦合的 Harness 和 Agent 整合起来，Anthropic 的职责则是在 Claude 家族内部提供更聪明、更高效的“多模型混用与匹配”方案。 ```mermaid flowchart TD accTitle: Anthropic 的模型生态专注度 accDescr: 展示 Anthropic 聚焦 Claude 家族与 Harness 深度绑定的路由理念 subgraph IndustryTuning ["行业演进与 Harness 绑定"] A["高抽象层 Agent / Harness"] --> B["与特定模型家族深度调优"] B --> C["避免底层随意跨厂商切换"] end subgraph ClaudeFamily ["Anthropic 内部策略路由"] D["输入任务"] --> E{"复杂度分流"} E -- "高难度/长推理" --> F["Claude Opus"] E -- "轻量/高吞吐" --> G["低成本 Claude 模型 (如 Haiku/Sonnet)"] end ``` 谈及企业对 Token 成本的焦虑和管控，Katelyn Lesse 回忆了自己在加入 Anthropic 之前在 Stripe 的工作经历。当时团队对 AWS 账单极其敏锐，一旦有工程师配置了不合理的后台作业、疯狂空转 CPU 导致账单激增，团队便会设立防护护栏（Guardrails），并“非常客气地请该工程师关闭任务”，因为那超出了该目标本应消耗的预算。AI 领域的成本演进也将经历相同的健康周期：一味给团队下死命令设成本上限（Cap）会扼杀创新，真正聪明的做法是在保留创新的同时，优化协同策略。与其让庞大的 Opus 通宵运行跑出天文数字的账单，不如通过组合精巧的策略，在大幅降低成本的同时达成完全相同的成果。 - **模型家族定制化**：Anthropic 平台坚决限定并深耕于 Claude 家族内部的最优组合，不寻求做泛模型的外部路由器。 - **AWS 账单历史镜像**：企业对 Token 消耗的审计就像云原生时代的算力治理，重点是识别低效开销并设置护栏，而非简单粗暴地封顶扼杀创新。 - **策略替代硬算力**：通过在协调层（Coordination Layer）设计巧妙的执行策略，可以用更低廉的成本匹敌甚至超越大模型整夜暴力运算的效果。 --- ### `43:24` 协调层新纪元：让每个 Token 承担明确的工作职责 展望未来数月的开发规划，团队最兴奋的方向是构建能够让开发者自由组合“策略（Strategies）”的基础设施，即向架构栈中的协调层（Coordination Layer）深度挺进。Angela Jiang 指出，许多开发者在构建智能体（例如用于自动搜寻漏洞的 Bug Hunting Agent）时往往会陷入瓶颈。当单个 Agent 效果有限时，大家通常只知道两个杠杆：要么换一个更大更聪明的模型，要么让当前模型运行更长的时间。然而，业内研究和实际测试表明，真正具备不对称收益的“第三个杠杆”是策略组合，比如采用 Best-of-N（多轮采样择优）或多分支并行验证。 ```mermaid flowchart LR accTitle: 智能体效果提升的三个杠杆 accDescr: 展示传统两杠杆与第三个更具阿尔法的策略杠杆对比 subgraph Traditional ["传统仅有的两个杠杆"] T1["换更大的模型"] T2["增加运行时间"] end subgraph StrategyAlpha ["真正蕴藏 Alpha 的第三杠杆"] S1["协调策略 (如 Best-of-N)"] S2["Token 分工架构 (Advising / Reflection / Execution)"] end Traditional -.->|收益遇瓶颈| StrategyAlpha ``` 虽然学术界关于 Best-of-N 等方法的论文汗牛充栋，但要把它工程化、做成能直接推向生产环境接受真实用户检验的架构却极度困难，需要开发者手工搭建极其繁琐的定制 Harness。Anthropic 的核心哲学是：“如果一件事回报极高但做起来极其痛苦，我们就负责把它彻底做简单”。主持人 Sonya Huang 笑称这让人联想到一年前大家热议的“智能体蜂群（Agent Swarms）”。Angela 认同蜂群本质上就是策略的一种形式，但她更倾向于摆脱单纯的人类组织比喻，将其提炼为底层本质——“让每一个 Token 都拥有明确的职责（The token has a job）”。无论这个职责是充当顾问、执行操作、反思审查还是维护记忆，Anthropic 内部已经验证了若干种高效的工作角色模板，而开放给开发者社区后，将激发成千上万种未曾被设想过的策略组合。 - **突破效果杠杆瓶颈**：不再单纯依赖增大模型或增加超时时长，通过生产级的协调策略实现质的飞跃。 - **将学术理论产品化**：Best-of-N 等机制在论文中简单，但在生产落地中极难，Anthropic 旨在提供一键式、可组合的抽象层。 - **Token 职责化（Token has a job）**：协调层的最高境界是将 Token 分配至不同职责（建议、执行、反思、记忆等），实现单位美元上智能密度的最大化攀升（Hill Climbing）。 --- ### `46:04` 满足双重开发者画像：企业合规控制与黑客极致自由 为了将这些前沿的策略组合赋能给全行业，Katelyn Lesse 梳理了团队必须同时照顾的两类核心开发者画像（Personas），并强调了打磨“基本盘（Table Stakes）”的重要性。一类是身处大型企业中的开发者，他们受限于严格的围墙花园（Walled Gardens）、安全合规与审计需求。对他们而言，哪怕 Anthropic 研发出能最大化智能的策略框架，只要无法无缝集成企业自有的记忆存储或安全沙箱，就无法实际采用。因此，平台正在致力于让底层组件更加模块化，使得企业能够灵活拆装记忆模块或管控插槽，提供无阻碍的企业级开发者体验。 另一类群体则是“周末极客开发者（Weekend Developers）”。他们热衷于为自己构思有趣、实用的工具，通常横跨社区内多个开源平台与工具链进行拼装。针对这部分人群，Anthropic 致力于提供更加开放、可 Hack 且灵活的接口与开发体验，让他们能随心所欲地展开实验。Katelyn 强调，把企业合规与开放可拓展等基础设施基本功做扎实，正是解锁广泛生态采纳的关键前置条件；唯有基石稳固，各层次的开发者才能无缝享受到更高级的策略组合与智能红利。播客最后，主持人总结并感谢了团队在保持生态开放与架构严谨之间的深思熟虑，并对平台未来的落地进展充满期待。 - **企业级模块化赋能**：提供清晰的安全审计、合规管控，允许企业将其现有的隔离环境与记忆体系自由接入，扫清合规死角。 - **极客开发者体验**：为独立开发者打造高度开放、低门槛、可自由篡改组合的原语生态，激发底层创新活力。 - **夯实基础以拓上限**：企业合规与极客体验等基本功并不是创新策略的阻碍，而是让更多开发者能够接入协调层、实现“更高智价比（Intelligence per dollar）”的必经之路。 ## Notable quotes > `11:09` Tokens aren't really fungible — Angela Jiang > `15:39` 我们并不固步自封地认为，这些代码必须跑在我们的基础设施上，或者沙箱与存储层必须由我们全权把控。 — Katelyn Lesse & Angela Jiang > `15:39` 代码跑在谁的机器上并不重要，重要的是 Agent 的装配架构是否健壮、可靠且具备扩展性。 — Katelyn Lesse & Angela Jiang > `20:00` 我是已经搞定收工了，还是由衷地觉得‘这太棒了，我还想继续做更多’？ — Katelyn Lesse & Angela Jiang > `30:00` 并不存在万能通用的通用 Harness（general harness）。 — Angela Jiang > `30:00` tweaking that last bit will give you a ton of juice — Angela Jiang > `33:05` 这是我想要的结果，这是我的预算上限，预备——开始！（Here's the outcome I want, here's the budget I want to spend, ready set go!） — Katelyn Lesse > `35:48` some really funky ways of handling context — Angela Jiang > `43:24` 如果一件事回报极高但做起来极其痛苦，我们就负责把它彻底做简单 — Angela Jiang > `43:24` 让每一个 Token 都拥有明确的职责（The token has a job） — Angela Jiang ## Mentioned Anthropic, Katelyn Lesse, Angela Jiang, Sonya Huang, Lauren Reeder, Sequoia Capital, Claude, Claude Code, Claude Design, Claude Managed Agents, Claude Tag, Claude Opus, Claude Sonnet, Claude Haiku, Messages API, MCP (Model Context Protocol), MCP Tunnels, Modal, Vercel, Cloudflare, Amazon / AWS, Google Cloud, Shopify, River, Block (Square), BuilderBot, Stripe, Andrej Karpathy, Slack, Microsoft Teams, WhatsApp ## Video description Katelyn Lesse and Angela Jiang lead the team building Anthropic's developer platform - the layer that both outside builders and Anthropic's own products run on top of. Angela frames the platform as a three-layer stack: knowledge, execution, and coordination. She argues the real leverage is what’s at the top: "strategies," or meta-harnesses that give each token a different job, from advising to executing to reflecting to memory. On the question of open ecosystem vs. walled garden, they say they aren't precious about owning the stack. Katelyn points to Anthropic's self-hosted sandboxes with partners like Modal, Vercel, and Cloudflare. Whether the work runs on Anthropic's infrastructure or someone else's, what really matters to them is that the architecture is sound. The deeper bet is standards: they hand skills and MCP to the whole industry, build connectors on the MCP spec, and help agents (Claude and non-Claude) work together. The one place they stay closed is model routing: they argue harnesses should be tuned to a model family, so they're designing for Claude rather than routing across models. Angela's frame for the ecosystem bet is electricity: transformative only because everyone could plug in, and no company wired it alone.Hosted by Sonya Huang and Lauren Reeder, Sequoia Capital 00:00 Introduction 01:49 Two North Stars 02:27 External Builders And Primitives 03:54 What To Externalize 06:00 From Messages To Agents 08:19 Managed Agents Adoption 09:07 Three Layer Cake 10:22 Execution Harnesses Explained 11:09 Coordination Strategies Roadmap 12:13 Ecosystem Standards And Safety 15:39 Open Ecosystem Not Walled 17:12 Vertical Products And Form Factors 22:26 Claude Tag Under The Hood 26:04 Harness Best Practices 38:13 Token Costs And Whats Next [Source](https://pscrb.fm/rss/p/traffic.megaphone.fm/CPUAI5412108570.mp3)

[11:09] Angela Jiang: Tokens aren't really fungible [15:39] Katelyn Lesse & Angela Jiang: 我们并不固步自封地认为，这些代码必须跑在我们的基础设施上，或者沙箱与存储层必须由我们全权把控。 [15:39] Katelyn Lesse & Angela Jiang: 代码跑在谁的机器上并不重要，重要的是 Agent 的装配架构是否健壮、可靠且具备扩展性。 [20:00] Katelyn Lesse & Angela Jiang: 我是已经搞定收工了，还是由衷地觉得‘这太棒了，我还想继续做更多’？ [30:00] Angela Jiang: 并不存在万能通用的通用 Harness（general harness）。 [30:00] Angela Jiang: tweaking that last bit will give you a ton of juice [33:05] Katelyn Lesse: 这是我想要的结果，这是我的预算上限，预备——开始！（Here's the outcome I want, here's the budget I want to spend, ready set go!） [35:48] Angela Jiang: some really funky ways of handling context [43:24] Angela Jiang: 如果一件事回报极高但做起来极其痛苦，我们就负责把它彻底做简单 [43:24] Angela Jiang: 让每一个 Token 都拥有明确的职责（The token has a job）

[26:04] Katelyn Lesse: There's best practices on stuff like your prompt caching and exactly how you clear stuff out of your context window and how you write your evals... but I don't know that there's necessarily so much juice to squeeze in a lot of cases out of that layer as compared to a layer higher than that. [35:00] We were like, 'Yeah, totally!' And we sat down with them and worked through it and it worked perfectly... We're seeing a lot of that connectivity layer as one of the cooler areas where people are innovating. [40:00] The thing that gets dangerous is when you're just like, 'Here's a cap and you're stuck within your cap.' Encouraging innovation and creating excellent outcomes, then coming in from the side to optimize costs with smarter strategies—that's the next layer of thinking.

[0:00] The last layer of abstraction on top of this is probably the coordination layer. So you have knowledge and you have execution and you have coordination. And at the coordination layer, we're beginning to think of these things called like strategies, where basically it's almost like a meta harness. The true low level harness is designed for execution. But the next one is about, okay, if tokens aren't really fungible and you need to give them different jobs, like maybe this token is advising versus this token is executing, you want to start composing these like these kind of orchestrated strategies that go together and they should sit on top of all these things because at the end of the day, you still need to execute and the execution still needs to know what to do. So everything in theory should kind of like ladder together. And so I think, you know, if you were to look at our roadmap and the maybe kind of project forward a little bit where you kind of expect us to go, we'll move more and more from the knowledge layer to the execution layer, from the execution layer to the kind of coordination layer in terms of the abstractions that you can see us put out. Caitlin and Angela, thank you so much for joining us today. Lauren and I are thrilled to have you here. You are responsible for building Anthropix platform And so you are responsible for building what I think is one of the most important if not the most important developer platform in the world And we are really excited to interview you today to understand more about what ahead And so maybe just to get started can you give us the context of, you know, what is Anthropic platform and where do you sit within Anthropic? Yeah, so platform is both our externally facing APIs, our developer platform that people build on top of when they want to build applications and systems that access Claude's intelligence, as well as internally, we run our product infrastructure. And basically, we're the layer that our apps build on top of internally as well. Awesome. What's your North Star as a team? It's a great question. We actually, because we have both internal and external, we actually kind of have like two North Stars, which is probably like, you know, you'd be like, why there's only one North Star? But no, we kind of planetary system. Yes, exactly. There's separate solar system so it's fine um but uh on the internal side like we really want to provide is like literally as much leverage as possible for our internal teams to be able to ship like agi-pilled products um and we want them to be able to move fast we want to have reliable like great like uh platform uh to be able to build on top of but i think that key bit about speed is like really intentional for us and we really really care about that internally externally um we actually have a lot more like complicated set of things But one of the true norths that we have there is to be able to basically give any builder the tools to be able to work with Claude to build whatever they want to build. And so it's a bit of a broad statement, but as a result, that boils itself down into, you know, being wherever that business is. Like we really care about like bringing our platform really, really close to that business. This is why we spend a lot of time with the hyperscalers, integrating really closely directly with them, like AWS, Google, so on and so forth. And it is a lot of primitives that we end up creating. We want people to be able to express what they think their product should be. We want them to be able to almost do custom software in their own way. In this new world with AI, what used to be probably economically impossible was that last mile of custom software now, in theory, should be very, very achievable. And we want to give them all the tools and all the capabilities to go and do that. And so sometimes that comes that form of primitives and APIs and higher order abstractions. And sometimes that comes in the form of just like standards. So for example, like skills and MCP, those are things just like Cloud needs them to be useful. And we can just give them out to the rest of the ecosystem, work with everyone to help you create those things and get the best out of Cloud So I would say externally you know we really are oriented around just helping you just be able to build But internally that orientation while still existing is probably more you know specified towards speed and being able to move really quickly. How do you decide what goes into the platform, what gets externalized and what doesn't to decide what products should be available? Yeah, I mean, we generally try to have a philosophy that we try to be consistent across the board. It's actually one of the reasons why we do internal and external. There's plenty of other platform businesses and constructs where you actually bifurcate these two things. For us, we kind of try to intentionally keep it equal. And then as a result, we try to hold this philosophy as much as we can around for any builder, internal or external, even though our internal builders might have some slightly different requirements in the same way any user would have slightly different requirements. We want to have the same primitives that are available to everyone. And one of the, maybe the overarching thesis for that is that we've just seen like the capabilities of these models just grow and so it's just exponential. And it's really hard to figure out like a long lasting form factor. I think two years ago we were all like, everything's chat. And now everyone's like, forget chat. And it's just like agents. And like, there's going to be another form factor, another form factor. And we kind of imagine that like constantly evolving. And so the best way for us to kind of enable that for everyone and also ourselves is to actually build a really robust platform that gives people those kinds of like tools. [5:00] to figure out what those form factors are. And I don't think we by any means feel like we're the only ones capable of figuring out that form factor, like not at all. In fact, the more democratization we can do on that and help people and allow people to experiment, I think the more those form factors will actually kind of naturally come out of the market. Yeah. And I think within our team, we've had moments where we're experimenting even with just like a packaging up of our primitives in a different sort of higher order way. And we've thought about, okay, cool, we've solved this exact type of problem with this product that we've built into the world. And so we can go and dog food it for ourselves, but we'd never want to fall into this trap of like, we're over-indexed on the problem as it needs to be solved for an internal user. Like, because exactly what Angela said, internal users have very specific requirements. External users have very specific requirements. And so if you over-index on one or the other, you fall into a trap. So a lot of the time what we'll do is dog food something internally at the same time that we open up early access of some sort with external customers so that we can kind of get a range of feedback and bring those things back into the platform. I'd love to talk about the higher levels of abstraction that you discussed. So I guess at the base level, this is just, you know, raw access to Clive, Opus or whatever tokens. How do you think about the I guess the layer cake of abstractions above that Yeah if you look back so when I joined Anthropic around a year ago the platform was basically just the messages API It was a messages API. You know, we had come out with standards like MCP. We obviously have developer tooling around our SDKs and our docs and our console and things like this. But for the most part, it was a stateless API. And what's interesting to Angela's point on form factors evolving over time is we found a lot of our customers solving the same problems over and over again that we also were solving over and over again around as the models got better at running for longer and working with more contacts at a given time, you want to build agents that can succeed in a kind of long running context and even a remote context that doesn't necessarily have a human in the loop. And so we found that we could piece together our primitives and stand up all the same infrastructure that we're finding ourselves standing up internally to power our own products and arrive at some higher order abstractions that let you do more agentic work out of the box. And the problems that we're solving for you are, you know, infrastructure being kind of a hard thing to deal with. Like how do you figure out spawning sandboxes that are going to have the right governance and security and like you know spin them up and spin them down when you need to Or the storage around transcript sessions so that you can resume a session if you stop it and pick it back up later So that infrastructure is a big thing that we wanted to be able to provide more of out of the box, and we do more of that today. And then the second thing just being harnesses and harness engineering. There's a lot of thought and energy going into how do I do my prompt caching and how do I manage my context window, as well as how do I actually just get more intelligence out of the model and how do I manage my costs and things like that. So we've kind of packaged up our primitives a bit more in tune with the problems that we found ourselves solving to provide more of these things out of the box for people so that they can, if they're building systems for themselves internally, if they're building products, they can just be more focused on the problems that they want to be solving. And if they want to offload some aspects of those problems to us, they can. And that's kind of the ethos. And are your customers generally choosing to opt from the grab bag of stuff that you offer? Or are they like, how often are they opting into just the managed agents offering, I guess? Just take care of it all for me. It varies by like the user group. So like for, I would say, you know, like really AI native startups, like the ones who are like tinkering and like experimenting at a really low layer, they just going to go for the primitives And then for everyone else these kind of classic like more like enterprises or areas where it like the purpose of the startup or the philosophy behind the startup isn necessarily to optimize on some kind of hill climbing piece It's more like stringing together a bunch of workflows and, you know, providing unique user value to that user. For those people, you know, it's just kind of not their core competency. It's not where they want to focus their time and resources. And they reach much more for these kind of like higher order, like package offerings. Thanks. What are some examples of the primitives you've released at different layers in the last few months? We've seen a few of them. We'd love to hear. Yeah, I think maybe one framing I would give for some of the constructs that Caitlin was talking about is like, and this is a bit of an oversimplification, but effectively, there's approximately like three layers of this cake. At the very bottom is just kind of like knowledge. And so at this layer, in many ways, it's knowledge about the model. It's knowledge about the things that the model needs. And it's It's just like the ability to know how to actually do something with Claude is maybe the way I'd phrase that. And so there, the primitives that we have spent more and more time on have been actually things of the past. Because we still evolve them, but they tend to be a little bit more baked. Like, for example, there's very specific shapes and parameters we put on the messages API. And it's more like trying to expressly showcase Claude's design, like Claude the model's actual design, the way it thinks, [10:00] the way it respects certain parameters, the way it kind of like will do tool calls, like all of those different pieces. And then we started standardizing like tools and then we started standardizing bits and pieces of like context that you could put in at different moments in time, which is concretely like skills and like memory. And so those are like the kind of like knowledge layer type of abstractions that we've put out over the past, I guess, like year plus a bit. The next layer of abstraction that we've actually started to spend more and more of our time on is like once you kind of know stuff, you then need to like execute. And so at the execution layer, that level of abstraction is the part that Caitlin was talking about around like, we're doing these like higher order pieces, but like, what are we putting higher order there? It really is because you're now getting Claude to execute work. It's not just to know something, right? I can give it a question and give me an answer. You can put string a lot of that stuff together. But now if you need to execute, like do work, give me the output, edit files in a bunch of different systems, that becomes a lot more complicated and requires infrastructure to handle. And so that layer is basically, I would say a low level harness plus managed infrastructure as like the set of abstractions. Today, we just like our high level product for that is called Cloud Managed Agents. And so that's like a piece, but we started to wrap more and more pieces in that. I think there gonna be a layer like on top of that We have like some inklings of it if we started to build towards but the last layer of abstraction on top of this is probably the coordination layer So you have knowledge and you have execution and you have coordination And at the coordination layer, we've started to expose some of these in ways that like aren't very obvious, but we're beginning to think of these things called like strategies, where basically it's almost like a meta harness, right? The harness, the true low level harness is designed for execution. But the next one is about, okay, if tokens aren't really fungible and you need to give them different jobs, like maybe this token is advising versus this token is executing, this token is dreaming versus this token is executing, so on and so forth. You want to start composing these kind of orchestrated strategies that go together, and they should sit on top of all these things, because at the end of the day, you still need to execute, and the execution still needs to know what to do. So everything in theory should kind of ladder together. And so I think if you were to look at our roadmap and maybe kind of project forward a little bit where you kind of expect us to go, we'll move more and more from the knowledge layer to the execution layer, from the execution layer to the kind of coordination layer in terms of the abstractions that you can see us put out. That's a really cool thing. How do you think this all comes together into a broader ecosystem beyond just the things that you guys are building? How do you help support people building products on top of it? And how do you help them get the most out of all these pieces? Yeah I think this is like super top of mind for us Like we really want to find a way to be to support as many people in doing this as we can I think we still like learning like a lot of the industry like has evolved We seen you know a lot of different pieces get spun up and spun down And I think the operative part for Caitlin and I has been in the category of like making sure, at least at the base layer, that we provide as many primitives across the board as possible. So, you know, this kind of like, yeah, like knowledge, execution, coordination there. We want to give all of that out to everyone so that people can start to compose and create on top of that. And that's just from a, I think, pure builder kind of point of view. Then there's a point of view around like, how do you kind of like plug in with us? Right. Like we're also building first party products of our own. We've also created some ways to embed natively with us, like, for example, connectors, which are built on top of the MCP spec. And we try to be more open about those types of things. And we're starting to figure out what are the right bits and pieces. But what we're really trying to do is get to a place where a company is able to get created and built on. They can build whatever products that they want. They can build agents if they need to. And then those agents and those products could be things that could plug into other agents. Some of those agents could be cloud agents. Some of those agents could be other people's agents. But we want to be able to enable that kind of like transactability across the board And then I think in order for all of that to kind of ultimately be true there is a bit around like standard setting And I think there's the traditional standard setting, which is around, you know, how do systems interoperate? And that's, you know, things that you've kind of seen to see with like skills and MCP. But they're out again, like the builder layer. I think at a higher order layer, there's also a bit around interoperability and standard setting around how do we all kind of like treat safety together? And, you know, we've talked to a lot of these companies and this is less from, you know, philosophies aside, just more like no one really wants to have technology that's like, for example, like doing negative things on their service. Right. So cyber, I think, is a great example of this. You want to protect your own systems from like negative actors or bad actors. And so like these kinds of like standard settings of like how can we find ways to partner with more and more people to be like, yeah, we all kind of want to make sure our critical infrastructure is good. We all want to prevent like fraud or any of those things from happening. And how can we work better with each of these members? I think on the last layer, we're still kind of like we're still evolving. And I think we're still very much like trying to find ways that we can be better and work with the rest of the industry to bring people along and work with them. But those are kind of like, you know, the higher order primitives or pieces that we wish to kind of like be in place. [15:00] So they can work with folks to ultimately solve this. I think if I were to take a step back at the end of the day on all of these things, this technology is so transformative. And if it's a little bit like electricity in a sense, like before electricity, there was just like, you know, you had to have a candle and it was like, you can only do so many things. But with electricity, the reason why it's such a transformative technology for all of us and so greatly of a utility is because you can actually like wire it into everything. Everyone is able to actually access it. we also have like standards and ways to plug in and do all the pieces that we need. And that's not something that anybody can do by themselves. They always have to work with the ecosystem and work with partners to figure out a path forward. How do you think about the philosophy of building an open ecosystem versus a walled garden? And how do you think about what products are really important for you to own first party versus where you're perfectly happy to plug into other components of the ecosystem. Yeah. There's so maybe in using Angela's kind of layered cake that we talked about a little bit earlier, you'll see that on some pieces of this, like execution, for example, what we've done within something like Cloud Managed Agents, and I think over time you'll see us try to make this a little bit more modular We actually aren precious about you should run these things on our infrastructure Like it should be sandboxes that we control or it should be a storage layer that we control Well, we actually like, for example, we launched self-hosted sandboxes and we partnered with Modal and Vercel and Cloudflare and a bunch of other folks, even like Amazon's new micro VMs to have a first class offering where you can go plug any of those things in. And we launched MCP tunnels so that you can call out to your MCP servers that are behind your firewall, right, and be able to punch through there. And so for some of these things, we, you know, the weather, whether it runs on our infrastructure versus somebody else's infrastructure is actually not important to us, because the thing that's important to us is more that the architecture of how you put together these agents in a way that will be powerful, in a way that will be reliable and scalable. We have strong opinions on that. And you can kind of just conform to the interfaces that we put out there and plug those things in. And we think that that generally is a thing that works really well. Yeah, I think on the kind of like verticals where we might build products, you know, I think we kind of have like two frames here. The first one is we are always trying to figure out a form factor like an evolving form factor We by the way don think form factors are like static It like a dynamic thing So what might be awesome for one year worth of AI development will probably not be awesome for the next year worth And we just kind of try to have that mentality We tell the team just overall, like around Anthropic, everyone's always trying to be like, is this AGI pilled enough? And then we also have this mentality of like, you know, we build something, it works. It was cool for a year and maybe it's not the right next thing. And so throw it away, try again. And we tell like platform users the same thing. I just think that's probably just like, you know, attached to the technology. But so, yeah, one principle is like trying to always constantly find this new form factor. So sometimes we'll like launch products in certain areas to try to showcase a new type of form factor. It's not necessarily because we think it's like the biggest ham or the most important thing to go after. But sometimes like, OK, this is like always been a really difficult thing. And people have always communicated this way or tried some things this way. And can we show that maybe there's a slightly different way? And because the model capabilities are so advanced now, can we try to express it a bit differently. What's an example of that? Yeah, you know, like, Claude design is a little bit of that way. I think depending on how you squint, you might see it as like a way that we kind of going into design as, as, as like, you know, one of the verticals. But more often than not, it's like, if you take a look at what we trying to do with that product there a couple of like decisions that were made in there The first one is that like you can actually try to offload more and more and more to Claude And so it tries to be kind of opinionated on like you know just just like talk to it and like let it really try to figure out. And yes, you can still edit it and do these kinds of things, but kind of like discourage a little of that and more just like let just talk to Claude to go figure it out. The second thing was it was really trying to express that actually like code is a way to solve for things that you wouldn't normally think would be the way. So a lot of people who have built kind of generative, you know, like slide decks or designs or whatever, will pick the way of like, they have like some kind of design system, you integrate against design system, it's almost in the traditional, like classic WYSIWYG style of designing something. And with like, Claude design, it was like, okay, can we try to just like use code purely, but have Claude generate that code? And would it like do a good job? And we found through some experiments early on, it's like, actually, it looks like it can kind of do that and how can we kind of showcase that to the world so that's like an example we have a lot of other internal projects and this kind of falls in the category of like expressing form factor we'll all try it out internally it'll be super cool for like two weeks and then we move on to the next thing we never even ship the thing frankly but yeah we actually do a lot of product experimentation in that area that's like our labs team and then there's like the second category which is that we actually do look at tam like we're a business [20:00] We do look at TAM, we do look at areas that we think, you know, there'd be reasonable agentic like operations that would happen in those areas. We do tend to have an orientation towards things that are more token heavy. And by token heavy or token hungry, maybe is the way I would say that is like what we mean is like, you know, you for spending once you spend a call like one turn. You look at the end of that turn and you say, like, am I done or am I actually so glad that I did that thing? I want to do more of that thing. We like industries where it's like the answer to that question, you say, I want to do more of that thing. So coding is obviously the one that we all know. And the great thing about coding is that what it's actually doing is that once you've finished a turn, you look at that and you're like, that was incredible. I'm like unlocked. I'm going to do like more. I'm going to build more. I can do more. And there's other services where it's like, actually, when you finish that turn, you completed the job and you just move on. You know what I mean? and so we tend to like go into the ones that are a bit more like there's this kind of like iterative flow you're going to build more generate more together and then the last angle that we kind of take a look at is just sort of like you know there's going to be certain business functions that we're like they are the buyer that we like to go to we want to help them optimize their workflows help them create better products there and I think we been pretty transparent with some of the verticalization like we done like finance we done like legal and we tried to to kind of like narrow on into specific areas where we feel like by having the right context and the right tools and putting it together in a good form factor is probably useful for us to be able to do And in each of those areas, we do, we're trying to do a bit of like showing the art of the possible across all the different ways that you would accomplish those outcomes. And so for, you know, like finance, for example, is a good one. You know, we you could be a company that solves problems in finance and you could build directly on the messages API and you can just get some tokens and you can build everything else on top. Or you could be someone who builds on cloud managed agents. you can get a lot more out of the box. Or you could say, I'm going to build a plugin that or like a connector, right? That's going to sit within one of our products and within those form factors. When we did recently, we launched like Cloud for Financial Services is like, okay, cool. We've got packages of skills and things like this. You could choose to use within our product, within other people's products. We even launched like cookbooks on here's how you would use Cloud managed agents to go and do these things. And so I think for us, it's all kind of an experimentation around Like you know we provide people all these different pieces and see kind of where they run with it And then sometimes we put together products that are just packaging of all of these things Like Claude Tag I think is a really good example Like we had been seeing people in the industry go and say like Shopify did this with River Square Block recently did this with BuilderBot. There's like a few of these examples where people said, I'm going to I'm going to build like an agentic platform internal to my company. and I'm going to try to give it all the right context and I'm going to make it accessible from Slack or from various other platforms that you'd want it to be accessible at. And I think Cloud Tag was very much a packaging of all those same things that anybody could choose to build something similar. But this is how we're kind of like, well, this is how we're doing it internally. And if you would like to just kind of plug in and go, here's what that looks like. What do you think people have misunderstood about Cloud Tag? Because there was all this like ruckus about, oh my gosh, it's just a Slack bot. Like, tell us what the magic of tag is. Yeah, I think it's a great question. And I do think it actually showcases a little bit of where maybe the future could be going. Yeah, I think like the I think if you look at products in the past, people are like, oh, you really attach to like the form or the UI almost. Right. Like it looks like this. So it's like super cool. And I think when you look at like tag it like yeah like the way you interact with it is that you like literally tag it in Slack And so yeah that is like the interface But that not really the important part The important part is all the kind of like context engineering and like architecture that we put underneath the hood so that tag just works. It really should just like just feel like a coworker, like a, you know, if you go to a company and you onboard, the coworker comes into your channel and then you can chat with it it's proactive it figured out like what's like useful you could and um it just gets stuff like done for you and so if you think about you know especially like non-technical audiences this is like it's a huge unlock you just you literally create a channel and then you add claude or sometimes you don't even add claude and you're like hey i want to be able to do this and do that and i can't figure out this and how do i actually like submit an expense report again and traditionally you think about how to solve that workflow you are going all over the place and you're talking to your manager and you're talking to your spin-up buddy and it's really really complicated. And today, now you just like go talk to Cloud Tag. And we do a lot of the hard work on doing the context engineering, the proactivity, a lot of the harness pieces. I think Andre Kaparthi said it really well. It's like it's like an org level harness. There's a lot of complexity baked into that. Like Kayla mentioned, you can use our APIs to go and construct that. You can do a lot of the experimentation yourself, obviously. But this is like an opinionated take from Anthropic on how you can have this really awesome, always on, [25:00] kind of agent for your entire entire company and the bit that's like futuristic i guess is like a lot of that complexity is actually like it's like an iceberg it's like all the stuff underneath it that's actually becoming the harder and harder and like useful part that we're trying to like push through and i think we'll see more and more like that kind of like tip bit that's like outside in the water it's just like the interface can actually constantly swap like today right like Slack is a place where a lot of people collaborate, a lot of business collaborate, but also a lot of people collaborate in teams. And some people collaborate by a WhatsApp group or they text each other or they may some people still email each other. And like those could be the form factors that actually completely you can imagine agents just going there and being. And they're almost taking up the same form factors as humans have taken up. It was almost like a very, almost like boring take, but it's actually like, I feel like the most like forward one, because you want the agent and you want AI to basically be like another person and it's helping you. But it's like, you know, very intelligent, can figure out all the context and you can always have it to be a really helpful assistant. Totally. You talked about context and then harnesses quite a bit. And so your team is just you know has such an opinion and point of view on like what it takes to build an exceptional agent I imagine a lot of that comes down to the context engineering and the harnesses Totally Maybe like what best practices or advice would you would you share with people about what you need to get right on the harness and what you need to get right on the context? Yeah, I think so. It's interesting because we've kind of talked about, you know, we launched Claude Managed Agents as this like very generic but high performing harness because we've done all the nitty gritty work that's actually like really boring and not super interesting around how do you deal with prom caching? How do you deal with context management? You like clear old stuff out of the window. Sometimes you like call tools programmatically so you don't pull everything into the context window and you can keep it clean. There's a lot of those sort of details on the lower level harness layer. And I think honestly, best practices are just stuff like prom caching, do it, save a lot of money and token costs. obviously like try to keep your context window clear and then putting those things together in a harness that will be performant is is you know sometimes specific to the tasks that you're trying to accomplish right and then of course evals I'm surprised we got this far into this thing before one of us said the word evals but like you need evals to make sure that what you trying to accomplish is performance but I think we we starting to go and Angela mentioned this a little bit earlier is more of a concept of strategies or meta harnesses Because I do think that, yes, you can, again, make this lower level harness. It's going to be performant. And maybe that's interesting for you to do yourself or maybe not. And you offload it to us. But this concept that you can take any given token and spend that token on just executing, or you could take that same token and choose to actually reflect on your past agentic sessions and write learnings to memory so that the next agent does a good job. Or you could take that token and advise with a bigger model so that a smaller model can execute and do a better job. Or you can say execute, execute. And then like a grader comes in and is like, did you do a good job? No, you didn't try again. Right. And so I think the interesting innovation is going to come more at that higher level on the meta level, right? And I think optimizing within those strategies is something that our team is really excited about. And we're starting to do a lot of work there. And I think a lot of other people are starting to feel really excited about this concept of strategies and the jobs you give to tokens. Because again like yes there best practices on stuff like your prom caching and exactly how you clear stuff out of your context window and how you write your evals and like a lot of things like this but I I don know that there necessarily so much juice to squeeze in a lot of cases out of that layer as compared to a layer higher than that yeah and one of the reasons for that I think is it has to do with the generations of the the models I if you look like two years ago a lot of the harness was like a scaffold to kind of like tell the model to go from point a to point b and you had to like you really had to like build in a lot you'd practically both one wall here and one wall here, sort of like the thing would go in a straight line. And now the models are actually very, very steerable. And so a lot of that steering, you can just put in the prompt, right? Like go do, go from point A to point B and the model, like will go from point A to point B. So a lot of, if you have harnesses that are like designed to kind of do that kind of like steering, you can delete that part. Like that part, we actually frequently encourage, we can delete part of those harnesses. I think various people have said things along those lines. And that's, I think, what people oftentimes mean when they're like, you know, the model will kind of consume some of the scaffolding. And like in that sense, like for sure, if your scaffolding is telling it to go in direction that it can just intelligently figure out, like that I think will increasingly continue to be so. But as a result of this, what the harness needs to start doing is more allow it to run longer. And so that's where that execution bit tends to be, I think, like it sounds like a maybe somewhat silly point. [30:00] But I do think it results in a lot of differences because because you can go in the direction that you tell it to go, you obviously don't want it to stop at B. You're like, OK, now go from B to C and then go to F and then go to Z and then come back to me on A. You know, something funky like that. In order to be able to do a lot of those things, the kinds of harnesses that you do are less the steering harness. And it's more like these kind of strategy harnesses that Caitlin's mentioning, which allows you to operate at a slightly higher level of thinking, which matches, I think, a lot of the intelligence gains we're starting to see with the model. Do you think task-specific harnesses make sense? Or vertical-specific or task-specific harnesses? I think people have different opinions on this. Our opinion is yes. I don't think there's a general harness. I think there are some capabilities that are obviously very general, and they tend to be very useful. Coding is a capability that is very useful because you can use it across so many things, and software has just eaten so much of what is capable. So our ability to write software is therefore useful. I think when you think about like very, very specific types of domains, they were going to require like a couple of pieces of the harness to be sort of like customized. One of that I do think is how you choose to kind of like handle sort of like errors between when you do something and you hand something off to the model So in like domains where require an extreme level of verification that logic of how you handle that again I think it sounds small but I totally understand why some people feel like they really want to own the harness because tweaking that last bit will give you a ton of juice, and especially domains like legal and finance where there's a lot of consequences to not getting it perfectly correct. It's really going to matter, and that's going to be the difference between your product and someone else's product being the thing that the user ultimately uses. And then there are other domains for which I would say it's not going to matter as much because you're able to compress it into a general model capability. So the tweaks that I guess where we feel like the domain specificity is really going to matter is the specific verification logic between the model and your execution. And then I think it's going to be about some of these kind of higher order strategies on how well you're able to actually allocate your token budget. I think the context bit is actually a little overdone. Like, yes, you're going to throw in context. But any harness can actually handle a lot of context. And so that's just more like you have the data. And if you have the data, then obviously you're uniquely qualified to do something useful. Yeah. And I think when people say harnesses they often mean a lot of different things And I think this is why in part there so many different opinions on this Like you can think of a harness as literally just like a loop that like okay cool like user model user model tool you know like that sort of thing then you could think of the harness as also all of the tools that are packaged up with the harness right and and there's just like a lot of different definitions of these things and I think the stuff that can be pretty generic and like less interesting to own and and deal with what I was kind of saying earlier is like getting your prompt caching rights right like maybe that is not the world's most interesting thing choosing to clear out old tool calls from the context window and and things like that right or like maybe a little bit less interesting and you like go a layer higher into some of the stuff Angela's talking about. And then you get into like, okay, yeah, these are things that I might want to own and control. And so it's interesting with cloud managed agents, like the thing that we built today, we call it higher order, but it's not really like that high order in the sense that you can choose to define all of the tools that you want to bring in as custom tools with the harness, right? And like, we give you a lot of knobs to control, you can define skills, you can do your system prompts, you can do a whole bunch of different things MCP servers and things like this And I think where we want to get to is a point where you can literally just tell an agent here the outcome I want and here the budget that I want to spend like ready set go And you may be like don think about any of those things underneath. And so I think there's just a few different layers of this, right, that for certain things, like you might want to sit at a different layer of what you actually go and control. And you can probably get better outcomes within some of those layers by doing a little bit more optimization work. Very cool. One of the things I'm curious about, and one that I love about infrastructure and platform teams is that you get to see what the most advanced users in the world are using and learn from them. I'm curious, what are some things that you're seeing and learning from the people building on your platform? There's some people that have been doing some really funky ways of handling context. We ourselves explore this a lot. That's actually one of the reasons why Tag is such a great product is there's a lot of really awesome context kind of engineering that's happening. We've seen some teams be really clever about how they do that. And they are able to kind of think through like, okay, if I have all these contacts in a bunch of different places, how can I proactively go reach out to them? How can I try to generate enough permissions across each of them? And then feed that all into an agent. And it's interesting that this is kind of the level of innovation that we're actually very excited by. [35:00] express itself as like a completely different product form factor. But what it actually does express itself as is like maximally useful to users. And we've been seeing this more and more with like actually like internal use cases instead of like external ones. So like companies who are becoming more AI native, basically, they're the ones we're seeing increasingly more and more innovation out of. And so, you know, we've had like customers try to do this for their like, they've built their own like custom SDLC kind of setup in very, very innovative ways. We've had ones who do that for like their entire back office. And just like the kind of nuances of how they like stream in context, I think it's been like actually really interesting in terms of like how they've been putting together the pieces. So that's been like one category that's been like really, really like fascinating. Another category that's been like really interesting has actually been with companies that are dealing with like really old school software. And so there's a lot of like healthcare companies that we kind of engage with. And you know, like they're like the systems I'm working with, they don't even have APIs. like that's that's a dream um and so you know how can they use computer use uh and things like this to be able to start to kind of automate and create more connectivity with our systems um and that area of innovation i think has been really exciting it been really interesting to see people try all sorts of crazy stuff from like taking a laptop and trying to like run a bunch of things on it to auto generate a bunch of things that then their agents can go and use And this has actually been probably like an area of I think a lot of innovation coming from a lot of our customers that we want to find ways to like support better and see like, okay, maybe there are like, how can we make this easier for you? How can we help you with some standardization? How can we get it so that, you know, like you can just have a spec and then Claude can then respect it. And so it's much easier for you to organically connect a lot of these things. But yeah, maybe the general theme I would just give you is like, interestingly, a lot of the innovation that's most exciting out there right now has been this kind of like context and connectivity layer, which has been really fascinating. Yeah, like a good one in that we were working with a customer who they built some agents on cloud managed agents. They also have some agents they built on other models and other platforms. And they've kind of optimized each of these agents to be good at the things that they want. they want these agents to all be able to work well together. And they kind of were like, wow, galaxy brain, like, what if I expose an MCP server on top of this agent so that I can then go and like have this other agent call a tool on that agent, right? And have these things just be more modular and be able to work together. And we were like, yeah, totally. And we sat down with them and worked through it and it worked perfectly and it was pretty cool And so we seeing a lot of again that connectivity layer that I think is one of the cooler areas where people are innovating But outside of that one thing that has been cool is just seeing the shift in I guess like industry trends of where we seeing a lot of our usage come from Like we talked a lot about coding, like coding as a category, like, of course, absolutely exploding. There's so much going on there. And we're starting to see some of these emerging trends. More recently, we're starting to see manufacturing really pick up as just a category where people are building with AI and one of our PMs getting on a flight to Detroit to go figure out with these customers what they need and what's going on. And so I think we're going to start to see a lot more just kind of like outside of the box of what people think about today sort of use cases, which we're really excited about. It seems like there's now there's a we went through a token maxing moment of history. And now there's like the token rationalization moment of history. What are your thoughts on that? And like, what should companies be doing? And then how does the platform team think about enabling that? Yeah, I mean, it makes sense. It makes sense from the high you start to rationalize. I really like that framing. And I think there's like a couple of things that are like top of mind for us on this front. I think like again it makes sense And as these models get more and more capable you going to hit like levels of intelligence max maxing that are like there that then you want to do the next kind of dimension and the next dimension after intelligence will either be cost or it will be speed And you just kind of go through that across all possible task complexities in the distribution. And as we kind of see that like happen, you know, something that's like really top of mind for us that we kind of try to spend some time with users on is like what you don't want to do is like stop AI usage. Right. Like that's kind of the wrong move. And we do actually see some of our customers do that. Oftentimes, the way that AI spend has erupted inside their company has been through some kind of like shadow IT. You know, like their employees just want to use it. They find a way. They end up procuring it themselves. And before you know it, like half your org has like found some way to install cloud code. And in that world, it is kind of hard to manage because these things are, again, like they're very token hungry, ultimately. And so what we try to kind of encourage our customers is like you don't want to like stop the innovation. If you are getting returns on top of this, you are shipping faster than ever before, you can run more operationally efficient, then those are gains. And so the area that we actually try to encourage people is if there is a way for you to construct, again, a strategy that allows you to design an architecture that says, given a task, assesses level of complexity. I mean, I'm effectively describing a router, but there are ways to do this that are, I think, a bit better now. And so this [40:00] level of complexity for that level of complexity like you can define some rules but for the most part right if it's like a hard task you should probably route that to like a big super smart model and if it's not a hard task you can route that to like cheaper models um designing that thing has a little bit of like there's a lot of technical complexity in that but it's like very very doable and we actually like encourage people to try those kinds of things i think ultimately i think within the quad space it will like make sense it's actually one of the strategies we imagine like designing because the way that we're kind of thinking a lot of these things is like it almost feels like every month there was a new era of something. And if we just take a step back, like, okay, and it seems to be like really fast. And so what are the different ways that are recomposable so we can redesign very quickly for any new, whatever the cool thing is that month kind of like bit. And so this is like in that category of things where we feel like we can actually just like recompose a lot of our primitives and then design it. I think the bit that we do feel really strongly about on the model routing front is like we are designing our platform for Claude. And we want to make sure that Claude is great at like solving all these things. So we'll like restrict to that space rather than, you know, I don't think we're that interested in saying like, okay and then you know you should route to a different model or whatever Makes sense Yeah And well some of that too is just like I think we have a strong belief that harnesses and just like the agentic layer should be tuned to the model family that you use it with. And so I think there was a period where people were kind of like, yeah, cool. I can like build a harness and build an agent and then just like plug in a different model underneath. And they were excited about routers from that perspective. And I think we started to see like Vercell just did this with harness agent, for example, like some of these players in the space, like come up a layer of abstraction and say, actually like plug in the whole harness and the whole agent that's tied to a model family, which makes a lot of sense. And so what we could provide is a little bit better, smarter, like how do you mix and match the right models within the model family underneath that thing, if that makes sense. But yeah, on the general question of token maxing costs and these sorts of things, I think we're just kind of going through what feels like a normal natural cycle for companies and figuring out how to make the best use of this technology and run their businesses really well and really effectively. And it's interesting, like before working at Anthropic, I was at Stripe, and we were kind of in the very reasonable era of like, we paid a lot of attention to our AWS bill. And so you know if someone were to have built some background job and they like didn quite configure it correctly and this thing like burning through like CPU or whatever it is right Like at any given moment and causing a big increase in spend that not actually worth it right Like we have put in place the guardrails to find that and then go ask that engineer very nicely to please turn off their background job. It's not like within the bounds of what they should be spending for the thing they're trying to accomplish. I think those are the things with AI that people are going start to go and figure out. And I think to Angela's point, a thing that gets dangerous is when you're kind of just like, here's a cap and you're stuck within your cap, like ready, set, go. But I do think that encouraging innovation, encouraging people to, you know, create really excellent outcomes with this stuff and then coming in from the side and looking and saying like, okay, well, there are a few different ways that we probably could have accomplished that outcome. Right. And One is like you take Opus and you run it all night and you do something crazy. And another is maybe to get a little bit smarter with the strategies that you put together in order to create that same outcome within a lower cost. And I think that's the like next layer of thinking that everyone's going to start to do. Very cool. Is there anything that you guys are excited about building over the next few months that you can share a hint at what might come next? Yeah, I mean, I know we said this word like 20 million times. I apologize but we really are trying to build ways for you to compose strategies And so that is an area that we trying to move into that kind of coordination layer of the abstraction And we want to start at this front because the types of problems that we see people building, they are at a layer where it's like, in order to get the most return on this, you have to be a little clever about what is the nature of the problem that you're solving. So to give you something concrete, when you try to solve for, like let's say you want to build an agent that's like trying to um do bug hunting and you could just send one off to go and do that and it's going to give you a certain level of return of possibility um and then people kind of get stuck at that and they're like okay my next options are i can like make a bigger i can just like swap the model for a different i probably bigger model um or i could like let it run like longer and that's pretty much like the only two like levers that you have to like try to make this like bug hunting agent for a lot of experimentation when we do these kinds of things, there's like, actually the thing, like those two things are still true, but you actually have like a third lever and tends to actually do a lot more than you think it does, which is that actually if you were to like best of end the thing, it would like give you a lot more returns. But like just to be, just saying those words are fine. And there's plenty of papers and people have published it to actually build that thing and put it into production. So you can actually test it on users and see the results [45:00] that's like really, really freaking hard. And you end up building all these like custom harnesses, so on and so forth, like, you know, all that stuff. But we're seeing like, this is where the alpha is and it's hard. And so like in the same very simple philosophy that we talked about at the beginning, like if it's like gives you the return that you want and it's hard, we're going to go try to make it easy for you. So then you can use it to then run the experiments you actually need to run. It reminds me of when people were talking about agent swarms a year ago. It's some version of that. Yeah. Has it been a whole year? Yeah, I know. We're finally there. Yes. Yeah. No, I think that that's like that's a type of strategy. Exactly. In the same way that you have like, you know, one big one that separates a bunch as another type of strategy. And I think people have thought about this maybe in the way of like human organization. I guess it could be similar, but if you take it to kind of its end state, it's actually more just like the token has a job. And I think it's this job piece that we're really indexed on. And we see a lot of returns to you. And that's the thing that we want to spend time with users and the rest of the ecosystem on, on like, how can we just make that easier for folks to then experiment? like we can give you like five jobs off the top of our head and we're probably like that's what we have internally um and if we give this out to the rest of the ecosystem there's probably going to be like a hundred thousand two hundred thousand who knows what other combinations that people could put together yeah we want to be able to keep doing this hill climbing on like how do you get the most value the most intelligence per dollar and just put that power in people's hands but around the edges of that we have these personas that have kind of just like things they have to work through in order to be able to like really deploy AI either within their companies or within their products. And that's like the sort of enterprise ready security and compliance controls and things like this. But really even just like making the platform more modular in the right ways, like being able to plug in different pieces of the solutions that we're building, like I want to use memory for this thing over here, right, or whatever else it is, and having a truly excellent developer experience around that because we spend a lot of time with enterprises who are like okay I have this like walled garden I need to figure out exactly how I can plug these solutions in And so we we got a part of our team that's innovating on things like strategies and jobs and trying to help you maximize intelligence. And they're like, that's really cool, but I can't actually use any of that for XYZ reasons. So I think solving those problems is really, really important to us. But then the other persona is, you know, the like weekend developer who's like, I want to go and build something useful for myself, right? And they're often doing that on top of our platform and on top of many other just pieces of developer platforms in the community. And I think for some of those folks, there's more that we can do to provide solutions that are maybe more open or more hackable or whatever it might be for those folks to kind of just like go wild with what we can offer them and have this really excellent developer experience. And so I think there's a lot of stuff that maybe I would put in the category of table stakes that I'm really excited about, because I think those are the things that then unlock getting people to say, okay, yes, this thing works for me. And now I can plug in on some of the stuff that you guys are doing that's really innovative and hill-climby to get more intelligence and save costs and things like that. Wonderful. Caitlin and Angela, I feel, I mean, you were building one of the most important developer platforms in the world. And talking to the two of you over time, I just feel really optimistic that that platform is in very thoughtful hands that care about the ecosystem. So thank you for taking the time today to share what you're up to. And we look forward to what's ahead. Thanks for having us. Thank you, guys. Thank you.