Gumloop v10.19.0 "Tilting"

功能详情

1. Agents for Your Whole Slack Workspace（Enterprise · Service Accounts）SPEC 深度分析 →

新功能

💡 此前任何人在 Slack 里 @ 一个 Gumloop agent 都需要自己的 Gumloop 账号——因为 agent 运行在该人凭据上。这让"全公司 helpdesk agent"无法落地：绝大多数员工永远不会登录 Gumloop，但需要随时问 agent

"Share agents with everyone in a connected Slack workspace, including teammates without a Gumloop account. Register your workspace in org settings, then opt in each agent from its share settings."

[文档已验证] 原名 Organization Service Accounts for Slack Agents。核心机制：创建组织级 service account（合成非人类 Gumloop 身份，邮箱 *.gumloopserviceaccount.com，不可登录，角色只能是 plain member 不可提权），注册 Slack workspace（per-workspace 授权，Grid 不继承），逐 agent 开启 "Allow Slack members without Gumloop accounts" 开关。无账号成员消息运行在 service account 上而非个人凭据。

fail-closed 设计：三条件（service account 存在 + workspace 注册 + agent 开关）任缺一即回退注册提示，默认对所有 agent 关闭。

凭据铁律：service account 是全新身份无任何已连 app，不能借 admin 或 Slack 用户的连接——agent 的 connector 必须设为 agent-owned，否则请求失败报错。

运行归属：权限/Custom Role/org policy 对 service account 求值，但原始 Slack actor（workspace ID + user ID + 显示名）记录在对话旁；消耗组织 credits；所有 setup 变更进审计日志。

三级撤销：关 agent 开关（单 agent）/ 移除 workspace（单 workspace）/ 删除 service account（全组织一次性停）。

排除项：未注册 workspace 成员、Slack Connect 外部组织、单/多频道 guest、停用用户/bot、DM（DM 永远走个人 Gumball）。

应用场景：(1) IT/HR agent 让全公司 Slack 成员（含不登录 Gumloop 的）能问问题 (2) 不预配账号的 Slack-first 大规模推广 (3) 所有请求命中同一身份同一行为，而非每人各自的 connector

📄 帮助中心源：https://docs.gumloop.com/enterprise-features/slack_agent_access.md

2. Gong in Company Brain（销售/对话洞察源）

新功能

💡 销售对话洞察（call recap、transcript）锁在 Gong 里，Brain 不知道"客户电话里实际谈了什么"——agent 回答客户问题时不掌握第一手对话上下文

"Sync Gong call recaps and transcripts into Company Brain. Pick which workspaces to sync, and everyone only sees calls they already have access to in Gong."

[文档未记录，基于 Changelog] Gong 作为 Brain 新数据源，索引 call recap（会议摘要）和 transcript（完整逐字稿）。权限继承：遵循 Gong 访问权限——用户只看到其在 Gong 中已有权访问的 call。可按 workspace 选择同步范围。延续 v10.11.0 Zendesk（客服域）、v10.13.0 any-connector-as-source（平台化）的 Brain 数据源扩张，本次进入销售/对话洞察域。

⚠️ 截至 2026-08-10，brain.md 尚未收录 Gong 章节，后续需重新抓取验证。

应用场景：(1) 销售问 agent "上次和 Acme 的 call 客户最关心什么"——agent 从 Gong transcript 引用 (2) 客户成功 agent 带 Gong 上下文回答 churn 风险 (3) 销售经理让 agent 汇总某客户全部 call 的共同主题

📄 帮助中心源：https://docs.gumloop.com/core-concepts/brain.md（Gong 章节待收录）

3. Outlook Email and Calendar Triggers

改进

💡 此前触发器覆盖 Gmail/Google Calendar 但不覆盖 Outlook——用 Outlook 的企业无法用邮件/日历事件触发 agent

"Trigger agents from Outlook. Run on new email in a chosen folder, or around calendar events — before they start, when they start, or after they end."

[基于 Changelog] 触发器扩展到 Microsoft Outlook。邮件触发：指定文件夹新邮件到达即触发。日历触发：围绕日历事件——开始前 / 开始时 / 结束后三个时机。与 v10.20.0 Gumball Works with Outlook 配对，形成 Outlook 全栈支持。

应用场景：(1) Outlook 收件箱新邮件触发分类/回复 agent (2) 日历事件前自动触发会议准备 agent (3) Microsoft 365 企业接入 Gumloop 触发器

4. MCP Improvements: Ashby（招聘域）

集成

💡 招聘团队无法让 agent 直接操作 ATS——搜候选人、提交面试反馈、管理 hiring team 都停留在人工

"Search candidates, request and submit application feedback, manage hiring teams, and handle interviewer pools, pauses, and capacity limits."

新增 Ashby MCP，招聘域能力清单：

搜候选人及申请状态
请求/提交面试反馈（application feedback）
管理 hiring team
面试官池管理（interviewer pools / pauses / 容量限制）

应用场景：(1) agent 搜候选人并汇总 (2) 自动收集面试反馈 (3) 管理面试官负载与暂停

竞品分析

战略方向判断

v10.19.0 "Tilting"（纽芬兰渔村）是 Gumloop agent 分发范式的关键跃迁版，核心信号是 Slack Workspace Agent Access：

1. agent 分发从"按账号"走向"按渠道全员"。此前 Gumloop agent 的触达半径 = Gumloop 账号数。Service Accounts 打破这个约束——一个 agent 可以被整个 Slack workspace 的所有人使用，包括永远不登录 Gumloop 的员工。这是企业 agent 从"自动化工具"到"全公司公共服务"的范式跃迁。IT/HR/财务 helpdesk agent 终于可以落地：员工在 Slack 里问就行，零账号门槛。

2. "零账号访问"背后是严密的治理工程。值得重点研究的不是"能让无账号用户用 agent"这个产品决策，而是其 fail-closed 安全模型：service account 是隔离的合成身份（不可登录、不可提权、无自带连接）、必须 agent-owned 凭据（不能借任何人的连接）、运行归属 service account 但记录原始 Slack actor、三级撤销、所有 setup 进审计日志。这套设计让"开放访问"不牺牲企业可控性——开放与治理同时成立，这是企业级分发的真正壁垒。

3. Gong in Brain + Outlook 触发器延续两条主线。Brain 数据源扩张进入销售/对话洞察域（继 Zendesk 客服域）；Outlook 触发器与 v10.20.0 Gumball Outlook 配对，完成 Microsoft 365 全栈支持。这两条都是生态加深，非范式创新。

与我方对比

"无账号 agent 访问"是企业 agent 触达的必答题。Gumloop 的方案启示：用共享 service account + 渠道授权（per-workspace）+ agent 级开关 + agent-owned 凭据这套组合，让 agent 能服务整个 IM workspace 而不要求每个使用者有平台账号。我方若做企业 agent 平台，需思考：(1) agent 如何触达"不登录平台"的员工？(2) 共享执行身份如何与个人身份隔离又可审计？(3) 凭据如何避免"借 admin 或借用户"的安全坑？这三点是 Service Accounts 的设计精髓。

Gong in Brain 揭示"对话数据"是知识库的下一类源。文档/消息之后，call transcript（第一手客户对话）是企业最鲜活的知识。谁先把"销售/客服对话洞察"纳入 agent 知识层，谁就占据客户域 agent 的制高点。

★★★★★

agent 分发范式跃迁，战略级 · Service Accounts 11/13

关键功能深度点评

Slack Workspace Agent Access — agent 从"按账号分发"到"按渠道全员分发"的范式跃迁。这不是简单的"Slack 集成增强"，而是 agent 触达模型的根本变化。此前 agent 的用户基数 = 平台账号数，Service Accounts 让一个 agent 的用户基数 = 整个 Slack workspace 成员数（含无账号者）。真正的护城河在治理工程的密度：service account 合成身份隔离、agent-owned 凭据强制、运行归属与 actor 记录分离、fail-closed 默认、三级撤销、全审计——这套设计让"开放全员访问"不牺牲企业安全。11/13 判定：战略 3（分发范式跃迁）+ 护城河 2（治理工程密度）+ 用户 3（全公司触达）+ 复杂度 2 + 创新 1。下一个值得关注的是 Service Accounts 能否从 Slack 扩展到 Microsoft Teams——跨 IM 渠道的"零账号 agent 分发"才是终极形态。

Gong in Brain — 把知识层从"静态文档/消息"扩展到"动态对话洞察"。call transcript 是企业最鲜活的一手客户知识，纳入 Brain 意味着销售/客服 agent 能引用真实对话。延续 Zendesk→any-connector 路线，本次进入销售域，Brain 正在成为横跨文档/消息/客服/销售对话的通用企业知识平台。