何时打开:你想看 Agent 公司怎么做的(不是怎么用) / 想做 Agent 创业 / 想理解 Agent 商业模式。本 wiki 把深思圈 76 篇 Agent 公司案例按"水平 Agent / 垂直 Agent / Agent 基础设施 / Agent 商业模式"四类组织。
一句话核心:Cursor "训练即产品" + microVM 环境 + 强化学习 + Anthropic "AI 真正的护城河是权限不是智力" + Imbue 估值 10 亿做通用 Agent + 垂直 Agent 8 大赛道(销售/客服/招聘/法律/医疗/保险/HR/数据分析)各诞生独角兽。
0. Agent 公司 4 大类型
| 类型 | 代表公司 | 深思圈频次 |
|---|---|---|
| 水平 Agent / 通用 Agent | Imbue / Manus / Devin / OpenAI Operator | 10+ |
| 编程 Agent | Cursor / Lovable / Devin / Replit / Codex | 15+ |
| 垂直 Agent(销售/客服/招聘/法律/医疗) | Harvey / 11x / Eve / Decagon | 30+ |
| Agent 基础设施 | LangChain / GitHub Spec Kit / Agent 保险 / Memory / Browser | 15+ |
1. Cursor —— "训练即产品"(技术内幕)
深思圈 / AI Agent 公司案例库 source:weixin/2025-11/Cursor首度揭秘
1.1 核心命题
Sasha Rush(Cursor AI 研究员)at Ray Summit 2025:
Cursor Composer = 比顶级前沿模型几乎持平,但 token 生成效率 4 倍;模型不只聪明,而且快到不打断思路(2 秒内给答案 → 保持心流)。
1.2 三大技术挑战
| 挑战 | 解法 |
|---|---|
| 训练与推理匹配 | 数千 GPU + MoE + microscaling FP8 + 自定义内核(Blackwell 上 3.5x 加速) |
| 超长 rollout | 10 万-100 万 token / 数百工具调用 / Ray 单一控制器解 stragglers |
| 训练 = 生产一致 | 同一套 cloud agents microVM 环境做训练和产品 / "训练即产品"哲学 |
1.3 关键设计决策
"我们能够通过生产 Cursor 产品进行训练 —— 生产 agent 服务器,在运行云 agent 时和训练强化学习时是完全相同的。"
含义:模型在训练时就已经在学习如何在真实产品中表现得更好,而不是训练完了再去适配。
1.4 Cursor 现状(2026-Q1)
- 估值 500 亿美金
- 为 Kimi 做广告(2026-03)—— 多模型路由
- 首席设计师专访 —— "AI 原生设计"
- 反框架路线 —— 揭秘 Cursor/Perplexity/Lovable 都选择"反框架"
2. Anthropic —— AI 真正的护城河是权限
深思圈 / AI Agent 公司案例库 source:weixin/2026-05/打了两年谁最聪明Anthropic护城河
2.1 Jaya Gupta 核心判断
"企业 AI 里最稀缺的东西,正在从「智力」转向「权限」。"
两个角色:
- 顾问:给建议
- 操作员:自己动手(写代码 + 合并 PR / 开关工单 / 改生产配置 / 发消息 / 触发下游)
跨过这条线之前:模型是"助手" 跨过之后:它是"系统的一部分"
2.2 "权限"不是 IAM / SSO,是组织信任
"Jaya 说的'权限'是一种组织信任 —— 一家公司愿不愿意在法务、风控、董事会层面,签字同意让一个模型在真实系统里自己执行。"
2.3 旧剧本:能力 + 治理双卖
四个历史案例(Google / 微软 / AWS / Palantir):
- 谷歌:改写控制层(Privacy Sandbox)
- 微软:锁住身份层(Entra ID + Security Copilot)
- AWS:基础设施 + 守护一起卖
- Palantir:和场景捆绑到无法替换
2.4 Anthropic / AI 不一样的两点
- 能力本身就是威胁:"让模型在修补漏洞上变强的改进,同样会让它在利用漏洞上变得更强" —— Anthropic 自己模型发布时说的
- 越用越懂你:AWS 不会因为你多用了几年就更懂你这家公司,但 AI 会;换掉它 = 把"组织上下文"重新搭一遍
2.5 Anthropic 其他动作
| 标题 | 看点 |
|---|---|
| 40 余人撬动 1300 亿收入 | "自增长黑盒" |
| 69 个 Anthropic 员工用 AI 做生意 | 内部 dogfood |
| 三个月估值翻倍超过 OpenAI | 老股东等上市套现 |
| Anthropic 进军金融 | 垂直化 |
| 海外 2025 人才报告:Anthropic 留存率 80% 碾压全球 | 人才战 |
| 营销已死,Anthropic 一个人干翻市场部 | AI 自营销 |
| 你的 Agent 为什么没法上生产 | Anthropic 给出了答案(Agent 工程实践) |
| Claude Code 背后 Anthropic 的"野心" | Skill / OS 战略 |
3. 通用 / 水平 Agent 公司
3.1 Imbue(估值 10 亿 / 2 亿融资)
"Imbue 估值 10 亿美金,2 亿美金融资通往 Agent 的下一个阶段" —— 深思圈
3.2 Manus(中国出海)
- Manus 命门:newtype · Agent 架构与多 Agent 编排 详细分析
3.3 Devin(Cognition)
- 编程 Agent 三巨头之一(Cursor / Devin / Claude Code)
- "继 Cursor、Devin 和 Claude Code 之后,又一匹 AI coding 黑马正在快速崛起"
3.4 Operator / Computer Use(OpenAI / Anthropic)
- a16z 预测:Computer Use 让 AI Agent 像人类一样工作,18 个月内效率超越人类
3.5 浏览器 Agent OS
- Accel 领投 2200 万美金,YC 创始人都心动 → 浏览器 AI Agent 的"操作系统"
- 与 海外推广与多账号矩阵(跨作者主题综合) / 王凯多 Agent 浏览器矩阵架构(v1.1 实操指南) 浏览器多账号路径不同
4. Agent 商业模式:三类典型
4.1 "Agent 终结 X 时代"模式
| 公司 | 替代谁 | 数据 |
|---|---|---|
| 销售领域 Claude Code(Peter Thiel 3500 万) | Salesforce | 号称"终结 Salesforce 时代" |
| AI-native ERP(红杉美国 2500 万) | 传统财务软件 | "干掉传统财务软件" |
| AI 重建律师事务所(红杉美国) | 卖工具的法律 SaaS | 不是卖工具,直接用 AI 重建 |
4.2 "为 Agent 而生的基础设施"模式
| 公司 | 做什么 |
|---|---|
| Agent 保险(1500 万美金) | 当 AI Agent 出错时,谁来买单? |
| Agent 时代的 Git(GitHub 前创始人,a16z 1700 万) | Agent 协作版本控制 |
| Agent 注册邮箱(YC 600 万) | 只做一件事:为 Agent 准备邮箱身份 |
| 2025 AI 记忆系统大横评 | Memory Infra |
4.3 "Agent 自带订阅模式"
- AI 私人助理住进 iMessage:两步设置 / $49/月
- AI 销售培训:5000 万美金融资 / 极度细分赛道
- Founder Mode 已经不够用了(AppSumo 前 CEO):AI 时代创始人要从"做引擎"升级到"设计引擎"
5. Agent 失败案例:11x 暴雷
- 2024-2025 11x 公司(AI 销售 SDR)暴雷 / 客户大量流失
- 代际更替:"11x 暴雷后,又一家做 AI 数字员工的公司拿到了 2500 万美金融资"
- 教训:Agent 不能只是"自动化 SDR" → 必须解决组织信任 / 权限问题(Jaya Gupta 视角)
6. 垂直 Agent 8 大赛道
详见 深思圈 / AI B2B 垂直行业(8 大赛道独角兽案例):
| 赛道 | 代表公司 / 数据 |
|---|---|
| 销售 | 红杉 5000 万(Salesforce 替代) / Peter Thiel 3500 万 / 0 到 8 亿(23 岁) |
| 客服 | 华人 2 亿(估值 15 亿)/ 5000 万巨额 / 丹麦 2100 万 |
| 招聘 | 5000 万一体化 / 2000 万 6 个月吸 5w 用户 / Inflection+Anthropic 用的 |
| 法律 | Harvey 类 / 25 岁电竞选手 7 亿 / Draftwise 2000 万 |
| 医疗 | 2400 万 Copilot / 4200 万家庭医生 / Shimmer 220 万 |
| 保险 | 6 个月连融 3000 万 / Agent 保险 1500 万 |
| HR | 1500 万 AI HR 通才 + 垂直模型 |
| 金融 | 4350 万(前 Google/Meta 科学家)/ 5000 万下一代基建 |
7. Agent 工程实践(深思圈视角)
7.1 训练即产品(Cursor)
详见 §1。关键认知:训练环境 = 生产环境 → 训练时学到的工具用法直接迁移。
7.2 反框架路线(Cursor + Perplexity + Lovable)
"揭秘 Cursor、Perplexity、Lovable 的技术内幕:为什么它们都选择'反框架'路线"
反 LangChain / AutoGen / CrewAI 等通用框架 → 自己写底层,更可控、更快。
7.3 Agent 上生产难点(Anthropic)
"你的 Agent 为什么没法上生产?Anthropic 给出了答案"
详见原档(权限 + 上下文 + 错误处理 + 监控)
7.4 LangChain 销售/营销最佳实践
"LangChain 团队用 AI agent 做销售和营销的最佳实践"
8. 怎么用 —— 按身份的 Agent 公司案例路径
| 你是谁 | 主用 | 起点 |
|---|---|---|
| 想做编程 Agent | Cursor 训练即产品 + microVM | RL + 自定义内核 + cloud agents |
| 想理解 AI 护城河 | Anthropic Jaya Gupta | 权限 > 智力 / 组织信任 |
| 想做垂直 Agent | 第 6 节 8 大赛道 | 销售 / 客服 / 招聘 / 法律 / 医疗 |
| 想做 Agent 基建 | 第 4.2 节 | Agent 保险 / Agent Git / Agent Email / Memory |
| 想避免 11x 式暴雷 | 第 5 节教训 | 解决组织信任 / 权限,不只是自动化任务 |
| 想做反框架 | 第 7.2 节 | 自己写底层 / 不用 LangChain |
通用纪律:
- 训练即产品(Cursor 哲学)
- 权限 > 智力(Anthropic Jaya Gupta)
- 垂直 8 赛道各诞生独角兽 —— 不是赛道太挤,是没找到组织信任
- 能力即威胁(AI 时代旧剧本升级)
- 越用越懂你 —— 数据 / 上下文成为新护城河
9. 引用清单
- 深思圈作者全集入口 —— 全集入口
- 主要 source:
sources/learning/深思圈/含 "Agent" / "Cursor" / "Anthropic" 等 ~76 篇文章 - AI Agent 架构与多 Agent 编排(跨作者主题综合) —— 综合 Agent 架构(已合并本 wiki)
- newtype · Agent 架构与多 Agent 编排 —— newtype 视角(Manus / Profile)
- AI Agent 技术架构演进 2025(深度研究报告) —— 2026-01 学术研究报告
- 王凯 Agent 工程实操 —— 王凯实操(Chrome MCP)
- 深思圈 / AI Coding 公司案例(Cursor/Lovable/Bolt/Devin/Replit) —— 编程 Agent 公司专题
- 深思圈 / AI B2B 垂直行业(8 大赛道独角兽案例) —— 垂直 Agent 8 赛道详情
2026-06 增补：垂直工作流的防线与 Agent 商业基础设施
本节全文阅读深思 SenseAI 6 月 1 日与 5 日的两篇中文解读后整理。前者转述 a16z 的 Joe Schmidt IV，后者解读 Stripe 的 Emily Sands；属于二手材料与作者分析，本次没有核验公司现状、指标或产品可用性。两篇原文中的配图说明比已归档版本更完整，因此另留文字快照，不覆盖旧档。
1. 通用连接器组合不等于垂直业务系统
“黄砖路”是 Schmidt 对容易与模型厂商正面重合的产品路径的比喻：把通用模型、现成的 Drive/Slack/CRM 连接器和一层任务协调拼起来。如果客户只需一次检索、自己就能判断答案，应用层很难只靠包装形成长期差异。
法律审阅、保险核保、复杂销售则涉及多系统上下文、多人审批、旧系统和明确的错误代价。竞争力可能来自深入业务系统的工程与治理，而不是下一代模型本身。判断一个机会可用三个问题：
- 步骤测试：是不是只有一两次通用工具调用？还是必须可靠完成多角色、多步骤工作？
- 系统测试：客户依赖你编排整个工作，还是只把你当临时附加工具？客单价高只是线索，不足以证明不可替代。
- 业务结果测试：客户用模型榜单打分，还是用有效销售线索、风险识别、合同处理等自身结果衡量？后者才把能力与付费理由接起来。
2. 四条防线必须在运营中兑现
| 防线 | 需要实际积累什么 | 不能偷换成什么 |
|---|---|---|
| 数据反馈 | 客户的风险升级规则、例外处理、人工改写及其原因 | 有日志就天然拥有数据权利或护城河 |
| 模型管理 | 跨供应商选型、升级回归测试、提示词与客户边界案例维护 | 一个通用路由器就无法被复制 |
| 成本控制 | 难任务用前沿模型、常规任务用更便宜方案，窄场景验证后再考虑小模型 | 所有任务都用最贵模型也能保持利润 |
| 治理 | 谁可授权、允许做什么、实际做了什么、出了问题由谁负责 | 写了“合规”两个字就完成行业要求 |
FurtherAI 的保险案例说明“工作流就是操作记忆”：表面相同的收件、审核、报价、承保，背后的风险权重和规则冲突处理却因公司而异。可重复步骤由确定性软件承担，变化与异常交给 Agent，需问责的判断保留给人；人工升级与改写成为下次修正规则的反馈。
11x 的销售案例把结果拆为潜客筛选、数据补全、账户调研、CRM 上下文、文案、资质评估和送达。文中 CEO 认为约一半步骤是排序、过滤、查询等确定性软件，并自报正向回复率数月内提高四倍。这是案例说法，不是所有行业的固定比例，也不能抹掉本页第 5 节记录的早期争议。对产品经理，更有用的问题是：哪一步真的需要模型，哪一步需要稳定规则？客户反馈变化后，谁负责持续维护？
3. 当 Agent 成为买家，支付要拆成不同职责
Stripe 解读文章把 Agent 看作购买服务、部署应用和消耗算力的新参与者。它描述的组合如下；这是 2026 年 6 月的产品叙事，不是当前接入指南。
| 模块 | 文章描述的职责 | 产品设计要分清的边界 |
|---|---|---|
| MPP，机器支付协议 | 用程序可理解的价格与支付流程替代人工结账页面 | 自动执行仍发生在预先授权范围内 |
| Link 钱包 | 用户授权 Agent 消费，凭证不直接暴露，购买可被通知和追踪 | 通知不等于每笔都必须人工点击，也不等于无限授权 |
| Stripe Projects | 从命令行管理部署所需服务，减少跨后台操作 | 减少操作步骤不等于账号和权限审核全部消失 |
| Metronome 与 Tempo | 用量计量与清算协作，探索消耗发生时收费 | 计量正确、收款成功、授权成立是不同问题 |
| Radar | 识别试用滥用与消耗后不付款风险 | 文中没有足够效果证据证明某类欺诈已被解决 |
4. 成本、计费与风险必须一起设计
文章以 Lovable 和 ElevenLabs 的演化说明：简单订阅便于起步，之后可将套餐内用量与超额收费结合。AI 任务有随使用增长的成本，不能只看订阅收入而不知道重度用户的实际消耗。迁移到按量计费的前提是能定义并追踪有意义的用量单位。
免费试用也有成本：虚假账号耗尽额度后消失，费用已产生但未必收得到。纯预付费可能中断正常用户，月底后付费则扩大坏账暴露；文中提出的流式支付试图缩短消耗与收费之间的时间。它是一种待评估方案，不是“稳定币必然解决一切”的结论。
最后保留两个未解决问题：数据使用权、真实反馈规模和竞争者捷径会影响垂直护城河的持久性；临时生成的 Agent 如何继承信用记录与责任主体，文章也没有答案。立项时应把这些写成待验证问题，不能因商业图谱完整就认定已经跑通。
来源与关联资料
- https://mp.weixin.qq.com/s?__biz=MzAxNjE1NTg2Ng==&mid=2247494661&idx=1&sn=64971ef39eae6a1b35c436149b49b4c9&chksm=9bfbb9b0ac8c30a66667201e1b3d1ed571918cdc1b9c6d4b2937db5fb365bfc49c8dab6953ee
- https://mp.weixin.qq.com/s?__biz=MzAxNjE1NTg2Ng==&mid=2247494752&idx=1&sn=6c50c0e7ca16735d43623052422e8267&chksm=9bfbb9d5ac8c30c3dd3a7d5ea23646b263f6f6af737c6bebd494d773f631bcad914a80ca41db
- https://mp.weixin.qq.com/s?__biz=Mzg3NDc2MjQxMg==&mid=2247491282&idx=1&sn=83dce462b2a3158fbe3c2d310235b095&chksm=ceca8711f9bd0e07208dbb1b6b925268005426b516beaf2fc666b7de7e8610fdec32044bb810
- https://mp.weixin.qq.com/s?__biz=MzAxNjE1NTg2Ng==&mid=2247494188&idx=1&sn=394115e9006df186ed1c2944a1aa01b8&chksm=9bfbbf99ac8c368fb1821f0d52491195fcaaf55d2c6557c7c53c6621674a9840ece831b72246
- 深思圈作者全集入口
- 深思圈 / AI 一级市场 VC 视角(a16z + 红杉 + YC)
- 深思圈 / AI Coding 公司案例(Cursor/Lovable/Bolt/Devin/Replit)
- 深思圈 / AI B2B 垂直行业(8 大赛道独角兽案例)
- AI Agent 架构与多 Agent 编排(跨作者主题综合)
- newtype · Agent 架构与多 Agent 编排
- 王凯 Agent 工程实操
2026-10-08 增补：模型升级后删临时步骤，保留目标、权限和验收
本节依据深思圈 10/7 对 Tibo 访谈的中文解读。来源同时包含访谈转述、媒体转述与作者推断；本次未重新核验原节目、配图或产品现状。仅提炼产品设计方法，不采用连接器数量、套餐范围、速度倍数、价格比例等数字作选型依据。
将工作流拆成两类，避免一起保留或一起删除
一类步骤是在补模型当时的能力不足，例如反复提醒做某项检查、手工拆分本可一次完成的任务。另一类是业务必须成立的条件，例如结果需符合哪个标准、能操作哪些数据、谁可以批准发布。前一类可以随着模型改善重新测试并精简，后一类需要明确保留。
为什么。 访谈转述描述了 agent 团队随能力变化而扩张、收缩的过程。可迁移的判断不是“单 agent 总比多 agent 好”，而是不要让历史上的临时绕路成为永久产品要求。每次升级用同一组真实任务比较完成质量、人工干预和成本；精简后退步就恢复旧安排。删步骤的依据应是任务证据，不能只是模型发布了新版本。
主动提醒与主动修改要分别设计
文中生产服务故障的例子，展示的是 agent 将时间、活动和服务异常联系起来，向负责人提出修复请求；负责人没有允许它直接动手。因此这份转述能启发提醒机制，不能证明 agent 已可靠完成生产修复。
可将能力分为发现异常、解释影响、准备方案、实际执行四步，分别设定授权和结果记录。先让用户看到“为何此刻需要注意、影响哪个任务、建议做什么”，再决定是否执行。一个提醒足够及时，不代表系统获得了改代码、发消息或购买服务的权限。评估主动性时，同时看漏报、误报、打扰次数与越权动作。
减少配置之后，仍要让用户能检查与纠正决定
隐藏模型选择、循环结构等技术设置，能降低用户的学习负担，但这些决定会由平台承担。产品应让用户知道任务目标、使用了哪些资料、哪些操作已经发生，以及如何改目标、停止后续动作和撤销权限。否则配置减少只是把复杂性变得不可见。
运行监控也属于持续成本：执行中的 agent 若需要另一层系统检查异常、拦截风险，其成本必须计入成功任务的总投入。不能用一次模型调用价格代表整套服务成本。监控提出警告、任务暂停和已经造成的外部影响是三件事，停止后续运行并不等于自动撤回已执行的动作。
分发主张暂留为待验证问题
文章转述了插件推荐可能关注留存与使用质量，也包含收入分成、平台用户规模等口头描述。没有完整规则和一手验证时，不能写成确定的获客渠道。产品仍可先验证具体任务是否有人重复使用、结果是否稳定、授权是否清楚；这些是自己能测的条件。平台是否推荐、推荐多少、能否带来付费，需要另外取得证据。
来源：本次参考文章。
October 8, 2026 addition: remove temporary steps after model upgrades; retain goals, permissions and acceptance criteria
Based on Shensiquan's October 7 Chinese interpretation of an interview with Tibo. It combines interview reporting, media reporting and the author's interpretation. The original program, images and current product state were not independently verified in this review. This addition extracts design methods; connector counts, subscription coverage, speed multipliers and price ratios are not used as selection evidence.
Separate two types of workflow steps
Some steps compensate for a model's limitations at a particular time, such as repeated reminders or manual decomposition of a task the model could eventually handle at once. Others express necessary business conditions: required results, accessible data and who may approve publication. Re-test and simplify the first group as capabilities improve; retain explicit conditions in the second.
Rationale. The reported interview describes agent teams expanding and contracting as capabilities change. The transferable lesson is not that a single agent always beats multiple agents. Temporary workarounds should not become permanent product requirements by default. Compare each upgrade on the same real tasks, measuring quality, human intervention and cost. Restore the previous arrangement if simplification hurts results. Remove steps because of task evidence, not merely a model announcement.
Design proactive reminders and proactive changes separately
The production incident in the article describes an agent connecting timing, activity and a service anomaly, then asking the owner for permission to repair it. The owner did not permit direct action. This account can inspire reminders; it does not establish reliable autonomous production repair.
Separate detection, impact explanation, proposal preparation and execution, with distinct permissions and result records. Show users why something matters now, which task is affected and what action is proposed before execution. Timely reminders do not confer permission to change code, send messages or purchase services. Evaluate missed alerts, false alarms, interruptions and unauthorized actions together.
Less configuration still requires inspection and correction
Hiding model selection and loop configuration can reduce learning effort, but the platform then owns those decisions. Users should understand the objective, information used and actions already taken, and know how to change the objective, stop subsequent actions and revoke permissions. Otherwise complexity has merely become invisible.
Monitoring is a continuing cost. If another system must check agents for anomalies and intercept risks, include that work in the total cost per successful task. A model call's price does not represent the whole service. A warning, a paused task and an external effect already produced are different states. Stopping further execution does not automatically reverse earlier actions.
Keep distribution claims as questions to verify
The article reports possible emphasis on retention and usage quality in plugin recommendations, alongside spoken claims about revenue sharing and platform scale. Without complete rules and primary verification, these are not a guaranteed acquisition channel. First test repeat demand, stable results and clear authorization. Whether the platform recommends the product, how much exposure it delivers and whether exposure converts to payment require separate evidence.
Source: Article used for this addition.
2026-10-13 增补：把发布阻塞项写清楚，再检查完整体验
本节依据深思圈对 Muse 团队访谈的中文转述，仅提炼产品评审方法。未核验原节目、团队规模、增长排名或公司交易信息，不据此判断 Muse 的实际效果。
让“还不能发布”对应具体用户任务
一次演示很惊艳，不能证明产品在日常任务里稳定可用。可以把准备支持的用户任务拆成可检查的行为，并在测试前区分两类条件：缺失就不能发布的条件，以及可以继续改善的体验。前者需要逐项满足，不能用其它项目的好表现抵消。
例如，一个助手能整理会议待办，但会把草稿误发给未确认的收件人。即使整理速度和界面都很好，发送对象与确认机制仍可能是发布阻塞项。这个例子是编辑应用示例，不是来源中的实测案例。清单应写清触发条件、预期结果与失败表现，避免只填“好用”“智能”等主观词。
每轮迭代用相同条件复查，才能知道修改解决了什么、是否破坏已经通过的部分。何时用： 从原型进入真实用户试用、替换模型或新增可执行动作之前。反例： 团队临时降低门槛，让表格看起来全部通过；或把所有小瑕疵都列成阻塞项，使上线永远没有明确条件。条件如何分级，应由用户任务后果和产品承诺决定。
检查各项功能是否在兑现同一个承诺
功能分别成立，组合起来仍可能让用户困惑。评审除了逐项打勾，还应走完一条真实任务，检查目标、界面反馈、可执行动作及人工确认是否一致。一个功能提高自动化程度，另一个功能却让用户无法知道已经发生什么，就需要重新作出取舍。
统一体验需要明确的产品判断和负责作决定的人，并不意味着每条建议都要加入版本，也不意味着小团队天然做得更好。来源关于“单一视角”的观察可以用来检查功能之间的冲突；团队规模和负责人品味不能替代用户验证。与企业场景中的评测、交付责任相互参照，可读 智能体原生产品与企业 AI 落地。
来源：深思圈：为什么Muse团队做出了ChatGPT以来增长最快的AI产品？。标题中的增长排名为来源主张，本节不将其作为已核验事实。
October 13, 2026 addition: define launch blockers, then check the complete experience
This section draws only product-review methods from Shensi's Chinese account of an interview with the Muse team. The original interview, team size, growth rankings and corporate transactions have not been independently verified here; this section does not assess Muse's actual performance.
Tie “not ready to launch” to a specific user task
An impressive demonstration does not establish reliable performance in everyday use. Break the intended user tasks into observable behaviors and distinguish two types of criteria before testing: conditions that must be met before launch, and aspects of the experience that can continue to improve. Every requirement in the first group must be satisfied; strong performance elsewhere cannot compensate for a failed requirement.
For example, an assistant may organize meeting action items well but mistakenly send a draft to an unconfirmed recipient. Even with excellent speed and interface design, recipient selection and confirmation may remain launch blockers. This is an editorial application example, not a tested case reported by the source. A checklist should specify the triggering conditions, expected result and failure behavior, rather than subjective labels such as “useful” or “intelligent.”
Recheck each iteration under the same conditions to identify what a change fixed and whether it broke something that previously passed. When to use this: before moving from a prototype to real-user trials, replacing a model or adding actions the assistant can execute. Counterexamples: lowering thresholds at the last minute to make every row appear to pass, or treating every minor imperfection as a blocker so that launch has no clear conditions. The consequences of user tasks and the product's commitments should determine how requirements are classified.
Check whether the features fulfill the same promise
Features can each work in isolation yet create a confusing combined experience. In addition to checking individual requirements, walk through a complete real task to test whether the goal, interface feedback, executable actions and human confirmation are consistent. If one feature increases automation while another makes it impossible for users to tell what has already happened, the team needs to reconsider that tradeoff.
A coherent experience requires explicit product judgment and someone accountable for decisions. It does not mean every suggestion belongs in the release or that small teams automatically build better products. The source's observation about a single point of view can help identify conflicts between features; team size and a leader's taste cannot replace user validation. For the related enterprise questions of evaluation and delivery responsibility, see Agent-native products and enterprise AI.
Source: Shensi: Why did the Muse team build what it describes as the fastest-growing AI product since ChatGPT?. The growth ranking in the source title is a source claim, not a verified fact adopted by this section.
2026-10-15 增补：先决定个人上下文如何使用，再选择本地或云端执行
证据范围：深思圈《Perplexity 为什么押注小公司和本地算力》的完整文字，属于访谈转述与作者分析；本批未独立核验原节目。硬件价格、利润、未来推理成本和增长预测不作为本节结论。
部署位置与数据权限是两个决定。 个人助手可能需要文件、使用习惯和长期工作背景。选择本地或云端前，先说清哪些资料属于谁、这次任务允许读取什么，以及哪些信息会离开设备。把模型放在本地，不等于它可以读取全部个人资料；把任务交给云端，也不等于服务已经获得完整上下文或持续访问权。
本地计算省下的是哪一部分。 文章讨论用本地算力承接持续工作、按任务调用不同能力的方向。本地执行可能减少反复发生的云端推理账单，但仍需要设备资源、维护和恢复；云端可提供另一种能力与运行方式，也有网络、数据传输和持续费用。两种位置可以分工，不能从“本地”直接推导更便宜、更安全或效果更好。
编辑应用推导：用同一条任务做比较。 固定输入资料与完成标准，分别核对能否得到正确结果、用户能否看见正在使用哪些资料、失败后由谁恢复，以及持续运行的总成本。若设备不可用、上下文缺失或某项操作需要确认，应明确呈现等待状态。让用户承担大量提示和排错工作，也属于产品交付成本。模型路由沿用本页已有讨论，完整运行责任参照 企业 AI 交付责任；本节仅补充上下文位置与执行分工。
来源：深思圈：Perplexity 为什么押注小公司和本地算力。
October 15, 2026 update: Decide how personal context can be used before choosing local or cloud execution
Evidence scope: The full Shensi article on why Perplexity is betting on small businesses and local compute. It combines a retelling of an interview with the author's analysis; the original program was not independently checked for this update. Hardware prices, profits, future inference costs, and growth forecasts are not conclusions of this section.
Execution location and data permissions are separate decisions. A personal assistant may need files, usage habits, and long-term work context. Before choosing local or cloud execution, specify who owns the material, what the current task may read, and what information will leave the device. Running a model locally does not entitle it to read all personal information. Sending a task to the cloud does not mean the service already has complete context or ongoing access rights.
Which costs can local compute reduce? The article discusses using local compute for ongoing work and calling different capabilities as tasks require. Local execution may reduce recurring cloud inference bills, but it still requires device resources, maintenance, and recovery. Cloud services offer other capabilities and operating arrangements, with network dependencies, data transfer, and recurring charges of their own. The two locations can share work; being local does not by itself establish that a system is cheaper, safer, or more effective.
Editorial application: Compare the same task. Hold the input material and completion criteria constant. Check whether each approach produces the correct result, whether the user can see which data is being used, who restores service after a failure, and the total cost of ongoing operation. If a device is unavailable, context is missing, or an action needs approval, make the waiting state explicit. Requiring extensive prompting and troubleshooting from users is also a product delivery cost. The earlier discussion of model routing still applies; see enterprise AI delivery responsibilities for operational ownership. This section adds the boundaries around context location and execution responsibilities.
Source: Shensi: Why Perplexity is betting on small businesses and local compute.
2026-10-17 追补：个人 Agent 的数据用途要逐服务核对
根据10月12日收件的 Persona 中文报道提炼。报道混合公司陈述、媒体转述和作者判断，产品条款、认证及下游合同未独立核验；以下是评审问题，不是对 Persona 当前做法的事实认定。
“不训练自己的模型”不能替代整条数据链说明
本页已有个人上下文、部署位置和权限讨论。这里补充数据离开入口产品后的去向：入口服务、自身长期记忆、第三方模型和交易服务可能承担不同职责。入口公司说“不用来训练自有模型”，仍不能据此推断下游模型供应商的保存和训练用途。使用同一个聊天入口也不意味着资料只交给同一个处理方。
评审时可为每条数据流记录四项：接收方、用途、保存时间、删除入口。例如邮件内容用于生成草稿，与从邮件推断长期偏好，是两种用途；删除聊天记录，也需要检查是否同时处理派生记忆及已传给下游的数据。拿不到条款或实际控制证据时标记待核验，不能用一句隐私承诺填平缺口。
推荐和交易分别检查利益与授权
报道讨论广告商品与中立推荐并存的设计。产品方说模型不知道哪些商品属于广告，只描述其中一个环节；候选商品如何进入列表、排序依据、商业合作是否改变展示，仍需分别说明。可用相同需求比较推荐理由与候选覆盖，检查商业内容是否可辨认。这是本库提出的验收办法，未对该产品做实验。
推荐符合偏好与实际购买获准是不同条件。评审清单应把商品理由、价格和收款方、动作确认以及失败后的处理分开；不要把用户允许读取邮箱扩展成允许付款。原文对法律责任的概括未经核验，不转写成通用法律结论。
何时用：评估有长期记忆、多个模型服务或商业推荐的个人助手时。先画出实际数据路径，再决定允许交出哪些资料；只有营销介绍时保留疑问，不用融资或创始人履历替代核验。
Addition: Check personal-agent data use at every service
This addition draws on a Chinese report about Persona collected on October 12. The report mixes company statements, media accounts and the author's interpretation. Product terms, certifications and downstream contracts have not been independently verified. The following are review questions, not findings about Persona's current practices.
A promise not to train an in-house model does not explain the full data chain
The existing article discusses personal context, deployment location and permissions. This addition examines where data goes after entering the product. The entry service, its persistent memory, third-party models and transaction services may have different responsibilities. A company's promise not to train its own models does not establish downstream providers' retention or training policies. One chat interface does not imply one data processor.
For each data flow, record the recipient, purpose, retention period and deletion mechanism. Using an email to draft a reply and deriving a lasting preference from it are different purposes. Deleting a conversation also raises questions about derived memories and data already passed downstream. Where terms or evidence of actual controls are unavailable, leave the point unverified instead of filling the gap with a general privacy promise.
Review incentives and transaction authority separately
The report discusses a design combining advertised products with neutral recommendations. Saying that the model does not know which products are advertisements describes only one part of the process. Candidate selection, ranking criteria and the effect of commercial agreements on presentation still need explanation. One proposed test is to compare recommendation reasons and candidate coverage for the same request and check whether commercial content is identifiable. This is an editorial testing proposal; no such experiment was performed on the product.
A recommendation matching a user's preferences and an authorized purchase are separate conditions. Review the product rationale, price and payee, action confirmation and failure handling separately. Permission to read an inbox must not be expanded into permission to pay. The source's broad statements about legal liability were not verified and are not presented as general legal conclusions.
Use this review when evaluating personal assistants with persistent memory, multiple model services or commercial recommendations. Map the actual data route before deciding what to share. If only marketing material is available, retain the open questions; financing and founder credentials do not replace verification.
2026-10-20 增补：给主题聊天设置任务生命周期
证据范围：2026年10月20日 Builders 整理的 Nikunj Kothari 对 Wabi 2.0 的个人体验。它是单个用户描述，不是产品实测或留存实验，也不能代表其他用户。下列验收办法是本站从案例提炼的建议。
主入口保持连续，具体任务可以结束
个人 Agent 不必把所有事务塞在一个无限延长的聊天里，也不必为每件事建立永久存在的新角色。可以让主 Agent 负责统筹，再为一次旅行、一个税务年度或一段学校事务创建有明确用途的主题聊天。任务结束后归档该会话，让当前工作区反映仍需处理的事，减少用户反复寻找和管理会话的负担。
Nikunj 的例子是：Wabi 看到航班信息后创建纽约旅行聊天，旅行结束后归档；2025 年税务也采用类似方式。学校事务聊天可以分享给妻子。值得借鉴的是“围绕一件事组织上下文，并允许它结束”的产品机制；他对新版更有兴趣，只是个人体验，不证明这种设计带来了普遍留存增长。
分享一个任务，不等于分享整个助手
分享范围可以落在具体主题会话，而不是主 Agent 的全部记忆。本站建议把会话创建、持续提醒、分享和归档分别设计：谁能看哪段上下文，任务结束后是否停止主动提醒，归档后如何找回，哪些资料仍会被主 Agent 使用，都应能让用户理解。归档在这个案例里只表示会话收起，不能推断产品已经删除数据或撤销权限。
反例与验收。 Nikunj 同时认为产品过于主动，说明自动创建会话也可能增加管理负担。可以先用一次旅行检验：是否准确识别任务开始和结束、提醒是否有用、分享是否限于所选事项、用户是否容易纠正和撤销。不要只统计创建了多少聊天；也要观察误建、打扰及用户整理会话所花的时间。需要长期稳定身份的关系或持续项目，不应为追求清爽界面被强行结束。
来源：https://x.com/nikunj/status/2112219327881761008
Addition — October 20, 2026: Give topic chats a task lifecycle
Evidence scope: the October 20 Builders digest’s account of Nikunj Kothari’s personal experience with Wabi 2.0. This is one user’s description, not a product test or retention experiment, and it cannot represent other users. The acceptance checks below are editorial suggestions drawn from the case.
Keep a continuous main entry point while allowing individual tasks to end
A personal agent need not put every activity into one indefinitely growing conversation, or create a permanent new character for every task. A main agent can coordinate work while purpose-specific topic chats handle a trip, a tax year, or a period of school-related activity. Archiving a conversation when its task ends lets the active workspace reflect what still needs attention, reducing the effort spent finding and managing chats.
In Nikunj’s example, Wabi noticed a flight and created a New York trip chat, then archived it after the trip. His 2025 taxes followed a similar pattern. A school-related chat could be shared with his wife. The reusable product idea is organizing context around a specific activity and allowing that activity to end. His greater interest in the new version is a personal experience, not evidence that this design generally improves retention.
Sharing a task need not mean sharing the entire assistant
Sharing can be scoped to a particular topic conversation rather than all of the main agent’s memories. Our suggestion is to design chat creation, ongoing reminders, sharing, and archiving as separate decisions. Users should understand who can see which context, whether proactive reminders stop when a task ends, how archived material can be retrieved, and which information the main agent will continue to use. In this case, archiving means putting a conversation away; it does not establish that the product deletes its data or revokes permissions.
Counterexample and acceptance checks. Nikunj also finds the product too proactive, showing how automatic chat creation can itself add management work. Start by checking one trip: does the system recognize its beginning and end correctly, are reminders useful, is sharing restricted to the selected activity, and can the user easily correct or revoke it? Do not count only the chats created; also observe mistaken creation, interruptions, and the time users spend organizing conversations. Relationships requiring a stable identity and genuinely ongoing projects should not be forced to end merely to make an interface look tidy.
Source: https://x.com/nikunj/status/2112219327881761008
2026-10-21 增补：消费 Agent 的定位还要问“谁付费、为谁优化”
王凯提出一个产品假设：个人及垂直 Agent 除了按任务区分，也可能像消费渠道一样，按会员费或广告、服务偏好、安全要求、价格敏感度及供应链组织形成不同定位。他举出会员管家、广告支持、强调安全或低价、围绕线下场景组织统一会员等设想。这里记录的是其判断，不是对任何产品条款或市场结果的核验。
可用于方案比较的问题是：谁付费、推荐或排序为谁优化、用户是否知道商业关系，以及产品能否稳定交付承诺的服务。会员制不自动保证无广告或完全中立，免费也不自动意味着背离用户利益，仍要检查具体条款和实际行为。供应链或会员网络可以作为待验证的服务假设；能否拿到供给、维持品控和完成履约，不能从一个 Agent 界面推导出来。
这补充了“相同任务也可能有不同商业取向”的观察，可与权限、主动提醒和任务验收原则结合使用。关于低门槛和市场不易垄断的预测不作为市场结论。
English
Wang Kai proposes a product hypothesis: personal and vertical agents may differ not only by task but also by membership or advertising models, service preferences, safety priorities, price sensitivity and supply-chain organization, much as consumer channels do. His examples include a paid concierge, ad-supported services, agents emphasizing safety or low prices, and unified memberships around local services. These are his hypotheses, rather than verified product terms or market outcomes.
Useful comparison questions are who pays, whose interests recommendations or rankings optimize for, whether users understand commercial relationships and whether the promised service can be delivered consistently. Membership does not automatically ensure an ad-free or neutral service, and free access does not automatically imply misaligned interests. Terms and actual behavior still need checking. A supply network or membership system can be a service hypothesis; access to supply, quality control and fulfillment cannot be inferred from an agent interface.
This adds the observation that the same task can support different commercial orientations, alongside permissions, proactive assistance and task acceptance. Predictions about lower entry barriers and limited monopolization are not adopted as market conclusions.
English edition
Shensi: AI Agent Company Case Library
When to use this note: you want to understand how agent companies build, consider an agent startup, or examine agent business models. The original collection organizes about 76 Shensiquan case articles into horizontal agents, vertical agents, infrastructure and business models.
The original organizing thesis: Cursor combines training, its product environment, microVMs and reinforcement learning; Anthropic's discussion shifts attention from intelligence to permission; Imbue illustrates general-agent investment; and sales, support, recruiting, law, healthcare, insurance, HR and financial/data work illustrate vertical opportunities.
Historical evidence notice. Company valuations, funding, revenue, adoption, performance and forecasts in the early sections are claims or headlines in the archived collection, not current facts independently checked for this translation. A translated headline does not endorse its claim. Later additions distinguish interpretation from verification more explicitly.
0. Four broad agent-company types
| Type | Examples in the collection | Approximate mentions |
|---|---|---|
| Horizontal/general agents | Imbue, Manus, Devin, OpenAI Operator | 10+ |
| Coding agents | Cursor, Lovable, Devin, Replit, Codex | 15+ |
| Vertical agents: sales, support, recruiting, law, healthcare | Harvey, 11x, Eve, Decagon | 30+ |
| Agent infrastructure | LangChain, GitHub Spec Kit, insurance, memory, browsers | 15+ |
1. Cursor: “training is the product”
This section follows the archived November 2025 Cursor account.
1.1 The central claim
The collection attributes to Cursor AI researcher Sasha Rush at Ray Summit 2025 the claim that Composer approaches top frontier-model quality while generating tokens four times as efficiently. The intended product benefit is speed that preserves flow, with an example of a response in two seconds. These are reported internal claims, not a benchmark reproduced here.
1.2 Three technical challenges
| Challenge | Approach described |
|---|---|
| Match training and inference | Thousands of GPUs, mixture of experts, microscaling FP8 and custom kernels; a reported 3.5× Blackwell improvement |
| Very long rollouts | 100,000–1,000,000 tokens and hundreds of tool calls; a single Ray controller handles stragglers |
| Keep training aligned with production | Use the same cloud-agent microVM environment for training and the product |
1.3 A key design decision
The reported arrangement uses the same agent-server environment for cloud-agent operation and reinforcement learning. The model therefore learns to operate in the product's actual setting during training, rather than being adapted to it only afterward.
1.4 Cursor as described in the Q1 2026 archive
The historical note lists a reported $50 billion valuation, a March 2026 Kimi promotion as a multi-model-routing example, an interview with its lead designer about AI-native design, and an account of Cursor, Perplexity and Lovable choosing an “anti-framework” approach. These entries describe the archived coverage, not a current company profile.
2. Anthropic: permission as an AI moat
This section follows the archived May 2026 account of Jaya Gupta's argument.
2.1 The central distinction
Gupta's reported thesis is that enterprise AI's scarce resource is moving from intelligence toward permission.
- Adviser: supplies recommendations.
- Operator: takes action—writes code, merges PRs, opens or closes tickets, changes production configuration, sends messages or triggers downstream systems.
Before that boundary the model is an assistant; after it, the model becomes part of the operating system of the organization.
2.2 Permission means organizational trust, beyond IAM and SSO
The relevant question is whether legal, risk and board-level decision makers will authorize a model to act in real systems. Identity and sign-on mechanisms alone do not establish that trust.
2.3 The historical playbook: sell capability and governance together
The note uses four analogies:
- Google changes a control layer, illustrated by Privacy Sandbox.
- Microsoft occupies the identity layer, illustrated by Entra ID and Security Copilot.
- AWS sells infrastructure with safeguards.
- Palantir binds deeply into operational settings, raising replacement difficulty.
2.4 Two proposed differences for AI
- Capability can also create risk: improving a model's ability to fix vulnerabilities may improve its ability to exploit them. The archive attributes this warning to Anthropic's model-release discussion.
- Repeated use may build organizational context. Unlike a simple infrastructure subscription, replacement may require reconstructing accumulated knowledge about the company. This is the author's argument, not proof of an unavoidable switching barrier.
2.5 Other Anthropic coverage in the collection
| Archived headline or topic | Angle |
|---|---|
| “Forty-plus people driving 130 billion in revenue” | A self-growing black-box narrative; currency and measurement are not established by the headline |
| Sixty-nine Anthropic employees using AI in businesses | Internal use/dogfooding |
| Valuation doubling in three months and exceeding OpenAI | Investor and eventual-listing narrative |
| Entering finance | Verticalization |
| A 2025 talent report claiming 80% retention | Talent competition |
| One person replacing a marketing department | AI-assisted marketing narrative |
| Why agents fail to reach production | Agent engineering |
| Claude Code's wider ambition | Skills and an operating-system strategy |
These are topics and claims in the historical reading list, not newly verified financial or corporate findings.
3. General and horizontal agent companies
3.1 Imbue
The cited Shensiquan headline describes a $1 billion valuation and $200 million financing for a next stage of agents.
3.2 Manus
The collection treats Manus as a Chinese company's international expansion case. The related newtype agent-architecture note discusses its vulnerabilities and positioning.
3.3 Devin / Cognition
The note groups Cursor, Devin and Claude Code as prominent coding-agent examples and includes coverage of another fast-growing entrant after them. This describes the collection's framing rather than a definitive current market ranking.
3.4 Operator and computer use
OpenAI and Anthropic illustrate computer-use approaches. A cited a16z prediction says agents may work like people and exceed human efficiency within eighteen months; this remains a forecast.
3.5 A browser-agent operating system
An archived article describes a $22 million Accel-led round and interest among YC founders. It concerns a browser-agent “operating system,” distinct from the multi-account browser arrangements in the overseas-marketing and Wang Kai agent-matrix notes.
4. Three business-model patterns
4.1 “Agents end the era of X”
| Archived case | Incumbent/category targeted | Pitch in the coverage |
|---|---|---|
| A “Claude Code for sales,” with a reported $35 million Peter Thiel investment | Salesforce | End the Salesforce era |
| AI-native ERP, with a reported $25 million Sequoia US round | Traditional finance software | Replace existing financial software |
| AI rebuilding law firms, backed in the account by Sequoia US | Legal SaaS that sells tools | Rebuild the service directly, rather than sell another tool |
4.2 Infrastructure built for agents
| Archived example | Role |
|---|---|
| Agent insurance, reported $15 million | Who pays when an agent makes a mistake? |
| Git for the agent era, associated with a former GitHub founder and a reported $17 million a16z round | Version control for collaboration |
| Agent email, reported $6 million from YC | An email identity for an agent |
| A 2025 AI-memory-system comparison | Memory infrastructure |
4.3 Agents with subscriptions
The reading list includes an iMessage personal assistant with two-step setup and a $49 monthly price, a highly specialized AI sales-training company with a reported $50 million round, and a former AppSumo CEO's argument that founders must move from building engines to designing engines. Prices and rounds are historical source claims.
5. A failure case: 11x
The early collection records controversy and substantial customer churn around the AI sales/SDR company 11x in 2024–2025. A later headline describes another digital-employee company raising $25 million after that controversy.
The original note's interpretation is that automating sales-development tasks alone is insufficient; organizational trust and permission also matter. This is a lesson drawn from the coverage, not a new investigation of 11x. The later June addition preserves a separate, more positive reported operating example without erasing the earlier dispute.
6. Eight vertical markets
See the related Shensi AI B2B verticals note for the detailed cases. Figures below reproduce the historical list, not independently verified current rounds.
| Market | Cases or figures in the collection |
|---|---|
| Sales | A $50 million Sequoia-backed Salesforce alternative; a $35 million Peter Thiel case; a 23-year-old founder's “zero to 800 million” headline, whose metric is not clarified here |
| Customer support | A Chinese-founded $200 million case at a reported $1.5 billion valuation; another $50 million round; a $21 million Danish case |
| Recruiting | A $50 million integrated product; a $20 million case claiming 50,000 users in six months; a service used by Inflection and Anthropic |
| Legal | Harvey-like products; a 25-year-old former esports player's “700 million” headline, without a clarified metric here; Draftwise's reported $20 million |
| Healthcare | A $24 million copilot; a $42 million family-doctor case; Shimmer's reported $2.2 million |
| Insurance | A reported $30 million over six months; $15 million in agent insurance |
| HR | A reported $15 million AI generalist and vertical model |
| Finance | A reported $43.5 million case led by former Google/Meta scientists; $50 million for next-generation infrastructure |
7. Engineering practice in the Shensi collection
7.1 Training as product development
Cursor's example in section 1 aligns the production environment with training so learned tool use transfers directly.
7.2 The anti-framework approach
An archived account of Cursor, Perplexity and Lovable argues for writing lower-level systems rather than relying on general frameworks such as LangChain, AutoGen or CrewAI, seeking control and speed. This is the article's design argument, not a universal framework ranking.
7.3 Reaching production
The Anthropic production-engineering article discusses permission, context, error handling and monitoring. The historical note points readers to the original archive for details.
7.4 Sales and marketing practice
The collection also includes an account of the LangChain team's use of AI agents for sales and marketing.
8. Reading paths by goal
| Goal | Main case | Starting point |
|---|---|---|
| Build a coding agent | Cursor's training/product alignment and microVMs | RL, custom kernels and cloud agents |
| Understand an AI moat | Jaya Gupta's Anthropic discussion | Permission and organizational trust |
| Build a vertical agent | The eight-market overview | Sales, support, recruiting, law and healthcare |
| Build agent infrastructure | Section 4.2 | Insurance, Git, email and memory |
| Avoid a failure like the 11x account | Section 5 | Address trust and permission as well as task automation |
| Explore an anti-framework design | Section 7.2 | Understand direct implementation rather than assuming LangChain is required |
The collection's recurring principles are training/product alignment; permission alongside intelligence; vertical opportunity interpreted through organizational trust; capability as both benefit and risk; and data/context accumulated through use. Its “unicorns in every vertical” language is an organizing investment narrative, not evidence that any particular new venture will succeed.
9. Reference collection
The Shensi author overview is the collection entry point. The original archive contains roughly 76 articles mentioning Agent, Cursor or Anthropic. Related notes cover integrated agent architecture, newtype's Manus/Profile perspective, the January 2026 architecture research report, Wang Kai's Chrome-MCP practice, coding-agent companies and B2B verticals. Publicly resolvable source and related-note links are retained in the reference list accompanying this edition.
June 2026 addition: vertical workflow defenses and agent commercial infrastructure
This section follows full reading of two Chinese Shensi/SenseAI interpretations dated June 1 and June 5. One recounts a16z's Joe Schmidt IV; the other interprets Stripe's Emily Sands. Both are secondary accounts and author analysis. Company status, metrics and availability were not independently checked. Additional image-caption text was preserved separately without replacing the old archive.
1. Combining general connectors is not a vertical business system
Schmidt's “yellow brick road” metaphor describes products that directly overlap model providers: combine a general model, standard Drive/Slack/CRM connectors and a coordination layer. If customers need only one retrieval and can judge the answer themselves, packaging alone may offer little enduring difference.
Legal review, insurance underwriting and complex sales involve multiple systems, multiple approvers, legacy software and explicit error costs. The advantage may lie in engineering and governance deep inside the business rather than the next model. Three tests help assess an opportunity:
- Steps: one or two general calls, or reliable completion of multiple roles and stages?
- System: does the customer rely on you to coordinate the whole job, or use you as a temporary add-on? A high contract value is a clue, not proof of irreplaceability.
- Business result: are you judged on model leaderboards or on qualified leads, risk detection and contract processing? The latter connects capability with a reason to pay.
2. Four defenses must be realized operationally
| Defense | What must actually accumulate | What it does not automatically mean |
|---|---|---|
| Data feedback | Escalation rules, exceptions, human rewrites and their reasons | Logs automatically confer data rights or a moat |
| Model management | Cross-provider selection, upgrade regression tests, prompts and customer edge cases | A generic router cannot be copied |
| Cost control | Frontier models for hard work, cheaper options for routine tasks, small models only after narrow validation | Using the most expensive model everywhere preserves margin |
| Governance | Who may authorize, permitted actions, actual actions and responsibility for failures | Writing “compliance” satisfies an industry's requirements |
FurtherAI's insurance example treats workflow as operational memory. Similar intake, review, quotation and underwriting stages hide company-specific risk weights and rules for conflicts. Deterministic software handles repeatable steps, agents handle variation and exceptions, and accountable judgments remain with people. Escalations and rewrites feed later rule improvements.
The 11x sales example separates prospect selection, enrichment, account research, CRM context, copy, qualification and delivery. Its CEO says roughly half the steps are deterministic ranking, filtering or querying, and reports a fourfold increase in positive replies over several months. This is a case claim, not a universal ratio, and does not erase section 5's earlier controversy. Ask which stage really needs a model, which needs stable rules and who maintains it as feedback changes.
3. Separate payment responsibilities when agents become buyers
The Stripe interpretation treats agents as participants buying services, deploying applications and consuming compute. The following is a June 2026 product narrative, not a current integration guide.
| Component | Responsibility described | Boundary to preserve |
|---|---|---|
| MPP, a machine-payment protocol | Program-readable prices and payment flows in place of human checkout pages | Automatic execution still stays within prior authorization |
| Link wallet | Authorized agent spending without directly exposing credentials; traceable purchase notifications | Notification does not imply either a manual click for every purchase or unlimited authority |
| Stripe Projects | Manage deployment-related services through a CLI | Fewer screens do not remove account and permission review |
| Metronome and Tempo | Coordinate usage measurement and settlement, exploring charging as consumption occurs | Correct metering, successful collection and valid authority are different questions |
| Radar | Detect trial abuse and nonpayment after consumption | The article does not establish that a category of fraud has been solved |
4. Design cost, billing and risk together
Using Lovable and ElevenLabs, the article describes starting with simple subscriptions and later combining included usage with overage charges. AI costs rise with use. Subscription revenue alone is insufficient without understanding heavy-user consumption. Usage-based billing requires meaningful units that can be defined and tracked.
Free trials also cost money: false accounts may consume capacity and disappear. Pure prepayment can interrupt legitimate customers; end-of-month billing increases bad-debt exposure. The article's streaming-payment proposal tries to shorten the interval between consumption and collection. It is an option to assess, not proof that stablecoins solve every problem.
Two issues remain unresolved: data rights, feedback scale and competitors' shortcuts affect the durability of vertical defenses; the article does not explain how an ephemeral agent inherits a credit history and accountable legal actor. Treat these as validation questions, rather than assuming that a complete commercial diagram proves an operating business.
October 8, 2026 addition: remove temporary steps after model upgrades; retain goals, permissions and acceptance criteria
Based on Shensiquan's October 7 Chinese interpretation of an interview with Tibo. It combines interview reporting, media reporting and the author's interpretation. The original program, images and current product state were not independently verified in this review. This addition extracts design methods; connector counts, subscription coverage, speed multipliers and price ratios are not used as selection evidence.
Separate two types of workflow steps
Some steps compensate for a model's limitations at a particular time, such as repeated reminders or manual decomposition of a task the model could eventually handle at once. Others express necessary business conditions: required results, accessible data and who may approve publication. Re-test and simplify the first group as capabilities improve; retain explicit conditions in the second.
Rationale. The reported interview describes agent teams expanding and contracting as capabilities change. The transferable lesson is not that a single agent always beats multiple agents. Temporary workarounds should not become permanent product requirements by default. Compare each upgrade on the same real tasks, measuring quality, human intervention and cost. Restore the previous arrangement if simplification hurts results. Remove steps because of task evidence, not merely a model announcement.
Design proactive reminders and proactive changes separately
The production incident in the article describes an agent connecting timing, activity and a service anomaly, then asking the owner for permission to repair it. The owner did not permit direct action. This account can inspire reminders; it does not establish reliable autonomous production repair.
Separate detection, impact explanation, proposal preparation and execution, with distinct permissions and result records. Show users why something matters now, which task is affected and what action is proposed before execution. Timely reminders do not confer permission to change code, send messages or purchase services. Evaluate missed alerts, false alarms, interruptions and unauthorized actions together.
Less configuration still requires inspection and correction
Hiding model selection and loop configuration can reduce learning effort, but the platform then owns those decisions. Users should understand the objective, information used and actions already taken, and know how to change the objective, stop subsequent actions and revoke permissions. Otherwise complexity has merely become invisible.
Monitoring is a continuing cost. If another system must check agents for anomalies and intercept risks, include that work in the total cost per successful task. A model call's price does not represent the whole service. A warning, a paused task and an external effect already produced are different states. Stopping further execution does not automatically reverse earlier actions.
Keep distribution claims as questions to verify
The article reports possible emphasis on retention and usage quality in plugin recommendations, alongside spoken claims about revenue sharing and platform scale. Without complete rules and primary verification, these are not a guaranteed acquisition channel. First test repeat demand, stable results and clear authorization. Whether the platform recommends the product, how much exposure it delivers and whether exposure converts to payment require separate evidence.
Source: Article used for this addition.
October 13, 2026 addition: define launch blockers, then check the complete experience
This section draws only product-review methods from Shensi's Chinese account of an interview with the Muse team. The original interview, team size, growth rankings and corporate transactions have not been independently verified here; this section does not assess Muse's actual performance.
Tie “not ready to launch” to a specific user task
An impressive demonstration does not establish reliable performance in everyday use. Break the intended user tasks into observable behaviors and distinguish two types of criteria before testing: conditions that must be met before launch, and aspects of the experience that can continue to improve. Every requirement in the first group must be satisfied; strong performance elsewhere cannot compensate for a failed requirement.
For example, an assistant may organize meeting action items well but mistakenly send a draft to an unconfirmed recipient. Even with excellent speed and interface design, recipient selection and confirmation may remain launch blockers. This is an editorial application example, not a tested case reported by the source. A checklist should specify the triggering conditions, expected result and failure behavior, rather than subjective labels such as “useful” or “intelligent.”
Recheck each iteration under the same conditions to identify what a change fixed and whether it broke something that previously passed. When to use this: before moving from a prototype to real-user trials, replacing a model or adding actions the assistant can execute. Counterexamples: lowering thresholds at the last minute to make every row appear to pass, or treating every minor imperfection as a blocker so that launch has no clear conditions. The consequences of user tasks and the product's commitments should determine how requirements are classified.
Check whether the features fulfill the same promise
Features can each work in isolation yet create a confusing combined experience. In addition to checking individual requirements, walk through a complete real task to test whether the goal, interface feedback, executable actions and human confirmation are consistent. If one feature increases automation while another makes it impossible for users to tell what has already happened, the team needs to reconsider that tradeoff.
A coherent experience requires explicit product judgment and someone accountable for decisions. It does not mean every suggestion belongs in the release or that small teams automatically build better products. The source's observation about a single point of view can help identify conflicts between features; team size and a leader's taste cannot replace user validation. For the related enterprise questions of evaluation and delivery responsibility, see Agent-native products and enterprise AI.
Source: Shensi: Why did the Muse team build what it describes as the fastest-growing AI product since ChatGPT?. The growth ranking in the source title is a source claim, not a verified fact adopted by this section.
October 15, 2026 update: Decide how personal context can be used before choosing local or cloud execution
Evidence scope: The full Shensi article on why Perplexity is betting on small businesses and local compute. It combines a retelling of an interview with the author's analysis; the original program was not independently checked for this update. Hardware prices, profits, future inference costs, and growth forecasts are not conclusions of this section.
Execution location and data permissions are separate decisions. A personal assistant may need files, usage habits, and long-term work context. Before choosing local or cloud execution, specify who owns the material, what the current task may read, and what information will leave the device. Running a model locally does not entitle it to read all personal information. Sending a task to the cloud does not mean the service already has complete context or ongoing access rights.
Which costs can local compute reduce? The article discusses using local compute for ongoing work and calling different capabilities as tasks require. Local execution may reduce recurring cloud inference bills, but it still requires device resources, maintenance, and recovery. Cloud services offer other capabilities and operating arrangements, with network dependencies, data transfer, and recurring charges of their own. The two locations can share work; being local does not by itself establish that a system is cheaper, safer, or more effective.
Editorial application: Compare the same task. Hold the input material and completion criteria constant. Check whether each approach produces the correct result, whether the user can see which data is being used, who restores service after a failure, and the total cost of ongoing operation. If a device is unavailable, context is missing, or an action needs approval, make the waiting state explicit. Requiring extensive prompting and troubleshooting from users is also a product delivery cost. The earlier discussion of model routing still applies; see enterprise AI delivery responsibilities for operational ownership. This section adds the boundaries around context location and execution responsibilities.
Source: Shensi: Why Perplexity is betting on small businesses and local compute.
Addition: Check personal-agent data use at every service
This addition draws on a Chinese report about Persona collected on October 12. The report mixes company statements, media accounts and the author's interpretation. Product terms, certifications and downstream contracts have not been independently verified. The following are review questions, not findings about Persona's current practices.
A promise not to train an in-house model does not explain the full data chain
The existing article discusses personal context, deployment location and permissions. This addition examines where data goes after entering the product. The entry service, its persistent memory, third-party models and transaction services may have different responsibilities. A company's promise not to train its own models does not establish downstream providers' retention or training policies. One chat interface does not imply one data processor.
For each data flow, record the recipient, purpose, retention period and deletion mechanism. Using an email to draft a reply and deriving a lasting preference from it are different purposes. Deleting a conversation also raises questions about derived memories and data already passed downstream. Where terms or evidence of actual controls are unavailable, leave the point unverified instead of filling the gap with a general privacy promise.
Review incentives and transaction authority separately
The report discusses a design combining advertised products with neutral recommendations. Saying that the model does not know which products are advertisements describes only one part of the process. Candidate selection, ranking criteria and the effect of commercial agreements on presentation still need explanation. One proposed test is to compare recommendation reasons and candidate coverage for the same request and check whether commercial content is identifiable. This is an editorial testing proposal; no such experiment was performed on the product.
A recommendation matching a user's preferences and an authorized purchase are separate conditions. Review the product rationale, price and payee, action confirmation and failure handling separately. Permission to read an inbox must not be expanded into permission to pay. The source's broad statements about legal liability were not verified and are not presented as general legal conclusions.
Use this review when evaluating personal assistants with persistent memory, multiple model services or commercial recommendations. Map the actual data route before deciding what to share. If only marketing material is available, retain the open questions; financing and founder credentials do not replace verification.
Addition — October 20, 2026: Give topic chats a task lifecycle
Evidence scope: the October 20 Builders digest’s account of Nikunj Kothari’s personal experience with Wabi 2.0. This is one user’s description, not a product test or retention experiment, and it cannot represent other users. The acceptance checks below are editorial suggestions drawn from the case.
Keep a continuous main entry point while allowing individual tasks to end
A personal agent need not put every activity into one indefinitely growing conversation, or create a permanent new character for every task. A main agent can coordinate work while purpose-specific topic chats handle a trip, a tax year, or a period of school-related activity. Archiving a conversation when its task ends lets the active workspace reflect what still needs attention, reducing the effort spent finding and managing chats.
In Nikunj’s example, Wabi noticed a flight and created a New York trip chat, then archived it after the trip. His 2025 taxes followed a similar pattern. A school-related chat could be shared with his wife. The reusable product idea is organizing context around a specific activity and allowing that activity to end. His greater interest in the new version is a personal experience, not evidence that this design generally improves retention.
Sharing a task need not mean sharing the entire assistant
Sharing can be scoped to a particular topic conversation rather than all of the main agent’s memories. Our suggestion is to design chat creation, ongoing reminders, sharing, and archiving as separate decisions. Users should understand who can see which context, whether proactive reminders stop when a task ends, how archived material can be retrieved, and which information the main agent will continue to use. In this case, archiving means putting a conversation away; it does not establish that the product deletes its data or revokes permissions.
Counterexample and acceptance checks. Nikunj also finds the product too proactive, showing how automatic chat creation can itself add management work. Start by checking one trip: does the system recognize its beginning and end correctly, are reminders useful, is sharing restricted to the selected activity, and can the user easily correct or revoke it? Do not count only the chats created; also observe mistaken creation, interruptions, and the time users spend organizing conversations. Relationships requiring a stable identity and genuinely ongoing projects should not be forced to end merely to make an interface look tidy.
Source: https://x.com/nikunj/status/2112219327881761008
October 21, 2026 addition: consumer-agent positioning depends on who pays and whose interests it serves
Wang Kai proposes a product hypothesis: personal and vertical agents may differ not only by task but also by membership or advertising models, service preferences, safety priorities, price sensitivity and supply-chain organization, much as consumer channels do. His examples include a paid concierge, ad-supported services, agents emphasizing safety or low prices, and unified memberships around local services. These are his hypotheses, rather than verified product terms or market outcomes.
Useful comparison questions are who pays, whose interests recommendations or rankings optimize for, whether users understand commercial relationships and whether the promised service can be delivered consistently. Membership does not automatically ensure an ad-free or neutral service, and free access does not automatically imply misaligned interests. Terms and actual behavior still need checking. A supply network or membership system can be a service hypothesis; access to supply, quality control and fulfillment cannot be inferred from an agent interface.
This adds the observation that the same task can support different commercial orientations, alongside permissions, proactive assistance and task acceptance. Predictions about lower entry barriers and limited monopolization are not adopted as market conclusions.