从单人对话到团队协同:为什么开通企业级 AI 后大家依然各聊各的?
把 AI 主要用于个人私聊时,往往局限在独立对话框内;从各自单聊走向跨角色的团队协同,需要看清人机协作的真实增益、工程目标与权限边界。
把 AI 主要用于个人私聊时,跨角色协作仍需人工搬运信息,带来上下文损耗与流程割裂。
多人协同 AI 的核心价值在于让团队跨端接续同一共享任务,并将人机交互中的纠偏沉淀为可复用的技能与资产。
过去十几年,办公软件大多完成了向多人协同的转变:写文档从邮件来回抄送 Word 附件,变成了多人在线实时编辑;做界面设计从各自导出本地文件,变成了全团队在同一个画布上协作;日常沟通也从封闭的个人收件箱,迁移到了按项目公开讨论的工作群组。
但引入大语言模型后,团队使用方式却常常退回到各自单聊:企业统一采购了 AI 账号,大家依然是在各自桌面上打开独立的对话框提问。一个人摸索出的好用提示词、排查出的关键业务陷阱,基本都留在了自己的聊天历史里,其他人看不到,也接不上手。
要理解这种脱节,可以先看两个基础概念:
-
智能体(Agent):不同于只能被动回答文字问题的传统聊天机器人,智能体被授予了调用工具的能力,可以根据指令读取代码库、查询数据库、调用软件接口(API),并在外部系统中执行具体操作。
-
共享会话(Shared Session):它不是把聊天记录导出为网页链接供同事只读浏览,也不是多个人盯着同一块屏幕,更不是让进入会话的所有人自动继承相同的系统权限;而是在各自权限受控的前提下,让不同角色(如产品、研发、运营)共同接入一个持续运行的任务环境,随时查看任务进度、共享上下文,并能从各自常用的工作工具中向同一个运行中的任务追加指令与反馈。
从单人各自开窗口走向支持团队协同的人机协作,需要弄清楚人际协同与 AI 结合的真实价值,以及背后的工程目标与安全边界。
一、单人对话模式的实际瓶颈
很多团队以为给全员开通账号后效率就会自然倍增,但在跨岗位的复杂业务中,单人对话很快会遇到两重阻碍。
1. 跨人流转的“上下文税”(Context Tax)
当智能体只能与单个员工绑定时,员工就不得不充当不同模型、不同同事之间的“人工中继器”。
以常见的产品定价调整为例:
-
市场运营人员在 AI 对话框中梳理出一套新版定价方案;
-
她将生成的结论复制到即时通讯工具,发送给研发负责人;
-
研发为了评估对结算代码的影响,把这段文字复制进自己的 AI 窗口,追问改动范围与依赖项;
-
研发确认后通过邮件回复说明;
-
测试人员收到邮件,再把内容复制进第三个 AI 窗口生成测试用例。
在这个链路中,团队付出了隐性的流转成本:
-
前置约束损耗:第一位同事在多轮对话中确认的业务边界和推导逻辑,在复制出来的简略结论中被省略,后续同事只能看到断章取义的结果。
-
重复解释背景:每个新介入的同事,都必须向自己的 AI 重新编写提示词,把前置背景重新描述一遍。
-
工作节奏割裂:原本连贯的任务,在多次人工复制与等待回复之间被打散成了碎片。
2. 个人电脑宿主的局限
当 AI 具备了调用脚本和操作文件的能力时,如果依然沿用个人模式,有些技术人员会选择在自己的笔记本电脑上运行自动化智能体。这在团队协作中会带来两个实际问题:
-
缺乏连续可用性与可接手性:个人电脑会面临休眠、断网或因系统配置而暂停进程等情况。一旦设备失联,运行中的任务可能中断,其他团队成员既无法随时查看最新执行状态,也无法在原上下文中直接接手继续推进。
-
权限与审计边界模糊:个人电脑通常直接保存着员工本人的浏览器登录态、各类系统凭证与本地配置文件。若缺乏统一的访问控制与出站网络审计,一旦智能体在处理外部数据时出现误操作,容易在本地环境混淆使用权限,事后排查与追溯也更为困难。
将团队协同任务部署在独立的服务环境或受控沙箱中,主要是为了保障任务的连续可用与团队成员随时接手,并建立统一的权限边界与审计记录,而不是断言本地系统天然不安全或云端必然绝对安全。
二、现有方案做到了哪一步?
面对这种割裂,企业通常会采购企业版账号,或在内部工作群中接入对话机器人。这两种做法各有价值,但并未完全解决协同连续性的问题。
| 常见方案 | 当前支持的能力 | 仍存在的协作断层 |
|---|---|---|
| 企业版/团队版项目 (如 ChatGPT Projects 帮助文档 所支持的功能) |
支持团队统一结算与权限管理;可在项目内共享自定义提示词、工作区参考文件与会话;成员可以查看已有对话并建立分支(Branching Chats)独立探索,分支与原聊天并列保留。 | 共享资料与分支历史,不等于具备跨入口接续同一任务的实时运行状态。 成员从历史会话开启分支后,各自分支是彼此独立的衍生对话,并不支持技术、运营等不同角色在各自的工作软件中共同驱动同一个正在执行的任务。 |
| 群聊接入机器人 (如 Slack 或飞书等群聊中的 @AI 助手) |
入口公开、门槛低;在群聊成员已有访问权限的前提下,所有人都能看到提问与回答过程,有利于经验的公开流动。 | 交互通常脱离了实际业务系统。 核心业务数据分布在代码仓库、文档系统、工单平台和数据库中;若机器人无法直接联动这些系统执行操作,员工仍需手动在专业软件与群聊窗口之间复制粘贴数据。 |
因此,群聊机器人迈出了公开化的一步,但团队协同的核心不在于聊天窗口设在何处,而在于不同角色能否跨系统接入同一个具有工具执行能力的任务上下文中。
三、实证与案例:人际协作加 AI 带来了什么?
团队协作与 AI 的结合,究竟能产生怎样的实际改变?学术研究与企业实践给出了两组参考。
1. 宝洁实地对照实验:冲击顶尖成果
哈佛商学院等机构的研究人员在宝洁公司开展了一项实地对照实验,成果收录于 NBER 工作论文。这项研究涉及 776 名专业员工,他们在为期一天的产品开发工作坊中完成真实业务任务的设计。实验对比了四组条件:个人独立工作、个人使用 AI(GPT-4/4o)、商业与研发各一人的跨职能双人团队无 AI、以及跨职能双人团队使用 AI。
实验发现了两层重要结果:
-
在方案平均质量上:AI 显著拉升了产出质量,使用 AI 的单人表现追平了无 AI 的双人团队;而团队使用 AI 后的平均质量与单人使用 AI 相比,在统计上并没有显著差异,表明在该任务中未检出团队相对单人加 AI 的平均质量优势。
-
在冲击前 10% 的顶尖方案上:表现截然不同。以单人无 AI 组为基线,其产出顶尖方案的基准概率为 5.8%;而跨职能团队配合使用 AI 时,产出顶尖方案的概率相对该基线增加了 9.2 个百分点(达到 15% 左右),提升至基准的近三倍。相比之下,在该实验中,单人配合 AI 在冲击顶尖成果上的提升幅度并不显著。
该实验结果表明,在具体产品开发任务中,跨职能人际协作(商业洞察与技术研发的结合)与 AI 的结合更有利于冲击顶尖成果。需要指出的是,该研究说明仅针对该实验设置,且实验使用的是常规模型对话界面,而非专门的多人共享会话软件,它反映的是跨职能人际协作结合 AI 的放大效应,不能直接等同于某种特定软件架构的必然证明。
2. Shopify 的实践:公开交互的车间效应
在企业实践中,电商平台 Shopify 内部推行的 AI 助手“River”提供了一个观察窗口(相关情况由《多人协同 AI 宣言》转述自其创始人 Tobi Lütke 的公开说明)。
Shopify 将 River 限制在授权员工可见的内部公开 Slack 频道中,而非一对一私聊。推行一个月内,公司内部约有八分之一(1/8)的代码合并请求(PR,即向主代码库提交修改的审查申请)包含了 River 的协作参与。
这种在企业内部公开使用智能体的方式,被形容为“车间现场学习”:当员工与智能体的交互过程在授权组织范围内可见时,优秀的提问思路、业务约束定义以及排查问题的方法,能够自然地被其他同事观察并复用,展现了开放交互对经验传播的实际价值。
四、多人协同 AI 的五项目标与实现条件
以下五条原则是多人协同 AI 的核心设计目标,它们代表了团队人机协作的演进方向,而不能当成购买现有工具就能直接拥有的现成功能。理清这些目标,有助于团队看清人机协同的真实需求与落地条件:
原则 1:减少人工复制粘贴(Never copy-and-paste)
智能体不应孤立在单独的网页标签页中,而应接入工作发生的场所(代码库、项目文档、工单系统)。参与同一项目的成员,无论身处即时通讯、邮件还是文档工具,都应能够介入同一个处于运行状态的任务中。
图注:跨系统接续任务的设计示意。展示多角色从不同入口接入同一个运行中的任务,由智能体联动代码库与通信工具,减少人工搬运信息。
在上述示意中,市场人员在即时通讯中询问新版定价 PR #482 的修改详情;智能体自动读取代码并发现年付折扣被设为了 15%,与规划方案要求的 20% 不符;研发负责人在邮件端回复要求修正;智能体随即向代码仓库提交代码修改(Commit),并在公开频道中同步完成通知。整个过程不需要人工反复搬运中间状态。
同一任务的流转方式对比
以 PR #482 折扣修正(将年付折扣由 15% 调整为 20%)为例,对比各自聊天与共享任务的流转差异。本对比为概念演示,各自聊天路径为示意过程。
各自聊天
- 运营人员在个人聊天窗口中让 AI 读取 PR #482,发现年付折扣被设为 15%,与规格要求的 20% 不符。
- 运营人员将排查结论手动复制并发送给研发负责人,原本多轮对话沉淀的业务背景被留在个人窗口中。
- 研发负责人在自己的 AI 窗口中重新整理提示词交代背景,追问改动涉及的代码文件并确认方案。
- 研发确认后通过邮件回复并手动提交代码,支持人员随后再次复制邮件摘要到新窗口生成对客文案。
共享任务
- 运营人员在群聊中向任务提问,智能体调阅代码库比对 PR #482,指出年付折扣被设为 15% 而非 20%。
- 研发负责人在邮件中直接回复该任务,在已有上下文中补充指令,要求修正代码并通知市场。
- 智能体在已有工具权限与必要批准下向仓库提交修正代码,并在团队公开群同步完成状态说明。
- 支持人员在同一任务中直接查看最新处理进展并跟进排期,全流程无需团队跨窗口反复复制粘贴。
两者的根本差异不在于沟通工具,而在于任务上下文能否连续保持。在已有工具权限与必要批准的前提下,共享任务可以减少跨岗位反复解释背景与人工转述的摩擦,让团队围绕同一运行中的任务协同。
原则 2:在透明环境中工作(Work with the door open)
私密对话容易让使用经验局限在个人手中,而向组织内有权限的成员开放交互过程,有助于经验扩散。
计算机科学家理查德·汉明(Richard Hamming)曾提到:关起门来工作,短期内手头的事情可能推进得更快;但开着门工作的人,更容易看清哪些问题真正重要。在企业内部,允许有权限的成员查看同事与智能体的交互记录,能够加快优质提示词与排查方法的流动。
原则 3:纠错沉淀为可复用技能(Continuously improve)
人类对智能体输出的调试与纠偏,应当沉淀为可继承的知识,而不是随着对话窗口关闭而遗失。
-
一次纠偏应该保存什么:系统需要沉淀的不是散落的文字记录,而是结构化的技能配方(Skill)——明确输入条件、业务规则与约束(例如“修改年付定价时必须对照最新的定价策略表”)、期望的输出格式,以及执行结果的检查步骤。
-
一次纠错不能未经检验直接变成全局规则:在某个具体场景下的修正,往往依赖特定的上下文;如果未经检验就直接对全员生效,很可能干扰其他正常任务。因此需要配套基准评测集(Evals),用历史真实案例进行回归检验,确保新规则不会引起意外偏差。
-
高频任务需要持续追踪评测:评测集不仅是在规则制定初期跑一次验收测试;随着业务环境与调用场景的演进,高频工作需要随时间持续追踪评测表现,及时发现准确率下降或逻辑漂移。
原则 4:人不充当消息路由(People are not routers)
在日常协作中,骨干员工经常花费大量时间回答各类事务性状态,例如“某客户的测试环境何时到期”、“某份合规报告是否有效”、“预算负责人是谁”。
凡是智能体通过连接内部系统能够准确回答的客观信息,应由智能体直接处理与同步,人类员工则集中精力于需要业务判断、权衡取舍与架构决策的核心事务。
原则 5:项目历史随时接续(Nothing starts from scratch)
当任务的执行过程持久保存在系统中时,设计文档、测算表或代码修改都会伴随一份活的操作上下文。
新成员接手一个已有项目时,可以通过关联的会话记录,了解该项目当时达成了哪些结论、排除了哪些备选方案、遗留了哪些待办风险。这无法替代必要的业务培训,但能有效降低从零还原历史背景所需的时间。
五、工程落地与安全防线
搭建一个支持多角色、多系统协同的人机环境,必须处理好底层的工程约束与安全规则:
1. 运行环境:连续可用与团队接管
将需要长期运行或跨角色协作的智能体部署在独立的服务环境或云端沙箱中,主要出于稳定运行与权限管理的考虑:
-
保障服务连续:任务不会因员工个人电脑休眠、关机或网络断开而失去响应;
-
支持随时接管:授权团队成员能够随时查看进度,并在原任务中继续操作;
-
规范凭证范围:通过受控的服务凭证调用外部接口,避免直接使用员工个人工作站上的各类凭据。
2. 安全边界:防范外部诱导与出站校验
当智能体被授予跨系统操作权限,并需要读取外部邮件、第三方文档或网络页面时,必须防范数据被诱导外泄的风险(例如外部文本中隐藏诱导性指令,诱使智能体调取并转发内部未公开信息)。
针对这种风险,系统通常会配置网络出站白名单(Allowlist)限制外联域名,并对关键写操作设置人工审批。但这并不意味着配置了白名单就能高枕无忧:白名单只能限制数据不被发往未批准的外部服务器;如果目标服务本身属于合规的白名单服务(例如公司内部使用的协作软件或邮件系统),智能体依然可能在已获准的服务中把敏感数据发送到错误的公开频道或非授权人员。因此,获准接入的各个系统内部,依然必须具备严格的权限与对象校验。
3. 权限交集陷阱与历史信息隔离
这是多人共享会话中最容易出现疏漏的环节:当不同权限的员工进入同一个会话时,系统如何展示数据?
所谓“权限交集”,是一种可选的保守策略:共享任务只调阅所有参与者均有权访问的资料范围;系统也可以采用按人区分可见内容的策略。但无论采取哪种方案,都不是加入会话就自动授予全部资料或操作权限。
图注:共享会话中权限隔离的设计示意。展示成员介入会话时,智能体对未授权数据拒绝复述的交互逻辑。
在多人共享会话中,仅仅让智能体在生成新回复时“拒绝复述未授权内容”是不够的。如果一位成员此前在会话中查询了敏感数据(例如包含商业底牌的客户邮件或报价),随后另一位未获授权的同事加入同一个会话,若界面依然显示先前的完整历史记录、任务摘要或会话附件,敏感信息依然会暴露。
因此,协同环境中的权限控制必须覆盖整个会话生命周期:不仅在生成时判断当前提问者及所有能看到回复的接收者是否有权调阅数据,对中途加入的成员,还需要对历史消息卡片、中间推理摘要和附件文件进行动态脱敏或视窗隔离;调取受限数据时,应当由有权批准的数据负责人显式授权,而非由调用者单方决定。
4. 架构解耦与弹性
大语言模型更迭迅速,团队在架构上可以考虑将业务逻辑与具体模型适当解耦,根据任务难度按需匹配不同算力(例如常规信息检索使用轻量模型,复杂逻辑推导使用高阶模型),并在单个供应商出现故障或接口变动时保留切换的弹性。
5. 审计追溯与资产可控
在面对合规要求或业务排查时,团队必须能完整复盘任务执行的四项要素:调用的智能体版本、发起操作的人员、调阅的数据范围、对生产系统做出的实际写入改动。
在落地路径上,自研、采用开源方案或采购商业工具三条路线都可行。搭建一个基础版本往往能较快跑通,但要实现完整顺畅的协同体验需要大量工程投入,容易挤占主业精力。真正的难点在于长期维护跨工具的任务接续、权限隔离与审计追溯。
无论团队选择哪条路线,核心都在于确保关键数字资产具备明确的可掌控与可迁移性:在日常业务运转中沉淀的工作流经验、验证过的技能配方(Skills)以及针对自身业务建立的评测基准(Evals),应当属于团队自主可控的数据资产,能够以通用格式导出、迁移和备份,避免被绑定在任何单一厂商或封闭平台内。
团队 AI 协同能力自检清单
请选择一个具体的实际业务项目,逐项核对并勾选团队已验证的协同能力,在对应项后记录真实业务证据,并在文末梳理当前现状与下一步改进计划。
维度一:任务接续与跨端协作
核对重点:团队成员是在孤立窗口中重复沟通,还是能基于统一任务上下文接力推进?
维度二:纠错沉淀与持续评测
核对重点:对 AI 的纠偏是否能转化为团队可继承的资产,并随时间持续检验?
维度三:运行环境与连续可用
核对重点:自动化任务是否具备脱离个人设备的连续可用性,便于团队接管?
维度四:多人权限与历史隔离
核对重点:多名不同权限的成员介入同一任务时,敏感信息是否能有效防护?
维度五:资产掌控与可追溯性
核对重点:团队核心数据与技能是否自主可控,任务执行过程是否可审计查验?
团队实际项目协同复盘
已核对 0 / 15 项
《多人协同 AI 宣言》(The Multiplayer AI Manifesto)Sergey Karayev 与 Superconductor 团队,系统讨论多人协同 AI 的核心目标与工程考量。
NBER 工作论文 w33641: The Cybernetic Teammate:Fabrizio Dell’Acqua、Ethan Mollick 等,关于宝洁 776 名员工跨职能团队与 AI 协同实验的研究论文。
Ethan Mollick 关于该研究的专栏说明:研究作者对实验设计与结果意义的详细解析。
OpenAI 官方文档:Using Projects in ChatGPT:关于 ChatGPT Projects 共享提示词、参考文件与会话分支功能的官方说明。
多人协同 AI:落地机制、实证边界与安全底线
企业引入 AI 后的单聊割裂,本质在于缺乏受控环境让不同角色跨系统共同驱动同一个运行中任务;协同中智能体可调用工具执行操作,但共享任务并不等同于共享全部权限。
01单聊模式瓶颈与现有方案断层
单人单聊迫使员工充当人工中继器,多轮推导的前置约束在复制中损耗;个人电脑运行智能体受制于休眠断网,且凭据混杂缺乏统一审计,他人无法随时接手。
共享资料和项目分支本身不等同于接续运行任务;群聊机器人若未接入代码与数据库等业务系统,仍需人工搬运信息,二者难以支持跨角色共同驱动同一正在运行的任务。
02实证检验与车间现场效应
776人实地实验中,在一天产品开发场景下,跨职能双人加AI使产出前10%顶尖方案的概率从单人无AI基线的5.8%升至约15%(单人加AI提升不显著);但团队加AI在平均质量上未显著优于个人+AI。实验基于常规对话框,不证明共享软件有效。
据企业实践案例口径(非独立实验),在授权公开频道部署AI助手,一月内参与1/8代码合并请求;公开交互使提问技巧、业务约束与排查方法在组织内被自然观察与复用。
03多人协同 AI 的五项设计目标
各角色跨IM、邮件或文档向同一任务追加指令;环境到期、合规时效等客观状态由智能体直连系统响应,员工专注核心决策。
授权公开交互加速经验流动;系统持久保存推导结论、排除项与遗留风险,新成员接续项目无需从零还原背景。
人工纠偏须沉淀为含输入、约束、输出与检查步骤的结构化技能;单次修正不能直接全局生效,必须通过基准评测集(Evals)回归验证并持续追踪。
04工程支撑与安全防线底线
独立沙箱保障任务不因员工个人设备休眠断网而中断并支持随时接手;入会严禁自动继承全权,对中途加入者的历史卡片、推理摘要与附件允许按权限隔离或动态脱敏,而非必须对所有人统一脱敏。
出站白名单不能防合规系统内部越权错发,接入系统仍须严格校验;合规追溯必须完整记录审计四要素:智能体版本、操作人、调阅范围、写入改动。
业务逻辑与具体模型解耦;沉淀的工作流经验、技能配方与评测基准属团队核心资产,必须支持通用格式导出与自主迁移,防止单一厂商绑定。
多人协同 AI 的落地不在于聊天窗口搬家,而是在受控沙箱中以评测检验技能,在保留权限边界的前提下依托同一任务上下文接续协作,并保持资产自主可迁移。
The Multiplayer AI Manifesto
What we think AI at work should look like. Five principles for multiplayer AI: never copy-and-paste, work with the door open, continuously improve, people are not routers, nothing starts from scratch.
Why we need this manifesto
Reason
We went from collaborative work to siloed AI chats
Collaborative features are a given in today’s apps. We went from email to Slack. From Word to Google Docs. But recently, we have drifted apart into individual AI chats.
Each of those chats is a closed room: whatever gets figured out in there stays with just one teammate by default.
Reason
Siloed chats come with a context tax
Today, Priya might work with Claude on a report, then send it to Marcus via Slack, only for him to put the report into ChatGPT and email the answer back.
With each handoff, the company pays a context tax that they wouldn’t have to pay if teammates could collaborate in the same agent session.
Reason
AI agents require org-wide security
AI has gone from answering questions to taking actions on your systems.
An AI agent running on an employee’s machine might inadvertently move sensitive data from one system it’s connected to into another — or worse, onto the public Internet.
Reason
Multiplayer AI improves outcomes
When employees of a large enterprise were allowed to collaborate both with each other and with AI, they achieved the highest proportion of top-quality outcomes in a Harvard Business School study.
And companies like Shopify found that allowing all employees to chat with AI agents in public was a boon to productivity. Within a month, 1 in 8 pull requests was already co-authored by their AI agent River.
Common misconceptions
Misconception
Isn’t my AI enterprise plan already multiplayer?
No, ChatGPT and Claude team/enterprise plans only let you share a few settings: prompts, skills, and integrations. They do not allow true multiplayer in the sense that Slack, Google Docs, Figma, and other modern tools do.
There is no chatting with a teammate’s agent. There is no learning from each other. Context is trapped in individual sessions, unindexed and short-lived.
Misconception
Can’t I just add an agent to Slack?
The simplest solution that allows your team to work with agents together is adding them to Slack. And indeed, Claude Tag and other solutions are great starts.
But a lot of work happens off Slack: in emails, Google Docs, GitHub, Salesforce, ServiceNow, etc. Truly multiplayer AI must enable reaching the same agent session from every work surface and every device.
We posit the following five principles for a true Multiplayer AI experience. This is a North Star to build toward. No vendor or internal platform that we are aware of currently satisfies all of them.
- Never copy-and-paste
- Work with the door open
- Continuously improve
- People are not routers
- Nothing starts from scratch
Principle
Never copy-and-paste
- Agents must live next to the work, instead of in their own chat or in Slack.
- Every person who is involved in the work must be able to chat directly with the same agent.
- Agents must be able to use every tool that a human on the team uses to do the work.
The same work as the context tax relay above, in one session.
Principle
Work with the door open
- When chat sessions stay private, best practices spread slowly. When chat sessions are shared, everyone gets better quickly.
- Tobi Lütke, Shopify CEO, called this “learning on the shop floor”. Shopify’s internal AI system (River) is only accessible via public Slack channels.
…if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don’t quite know what problems are worth working on; all the hard work you do is sort of tangential in importance.
Principle
Continuously improve
- When a teammate writes a great prompt and the agent gets it right on the first try, other teammates should learn how to write good prompts.
- When an agent needs correcting, a reusable skill should be created automatically, a saved recipe for that task that future agents use.
- When the same workflow is performed repeatedly, a benchmark should be automatically created and its score tracked.
Principle
People are not routers
- A human must never be asked a question that an agent already has the answer to.
- Chasing project updates and relaying answers is work for an agent, not a human.
- Humans must focus only on the highest value activities. The bureaucracy must be digitized.
Principle
Nothing starts from scratch
- When agent sessions live in the cloud, you can pick up every project exactly where you left off, with no context lost.
- Every artifact, whether a design doc, financial plan, or pull request, must have an agent session that can be resumed even months later.
- A new person joining a multiplayer AI team is productive on day 1.
Important considerations
Whether you build or buy, multiplayer AI is tricky to get right.
Consideration
Agents don’t belong on laptops
- Laptop agents can’t be accessed by the rest of the team.
- Laptop agents stop working when the lid gets closed.
- Laptop agents can gain access to everything that an employee has access to.
Consideration
Firewall every agent
- An agent tricked by a malicious email or document can send sensitive data to an outsider. Security people call this prompt injection.
- Every agent must be limited to the services you approve. That is only practical in locked-down cloud environments.
Consideration
Privacy pitfalls
- Agents are at their most useful when they have access to sensitive data such as emails, Slack messages, financial records, etc.
- When adding another teammate to a session that has exposure to sensitive data, it is important to handle permissions correctly.
- For example, the agent should only have access to integrations that every member of a shared session has access to.
Consideration
Stay provider-agnostic
- Some teammates prefer Claude, some prefer ChatGPT, and your CFO prefers open source.
- The most powerful model changes week by week, and most tasks do not require the most powerful model in the first place.
- When you bet your company on one model provider, you align yourself with their incentive structure, which is to bill you for as much usage as possible.
Consideration
Governance is non-negotiable
- Governance means being able to answer four questions about any session a year later: which agent ran, who asked it to, what data it touched, and what it changed. Regulated industries and anyone subject to GDPR cannot skip this.
- Auditors need a “black box” for agents, just as they have for every system of record: enough to check what happened without redoing the work by hand.
Session #4128 · audit recorda year later
Data accessedAcme contract, 3 decks, 4 ticketsChanges madeNone. A draft was saved.
Consideration
Build, buy, or open source
- There are compelling reasons for each one of building internally, running an open-source solution, or using a hosted platform.
- Most organizations find that while a basic version can be built quickly, getting to a fully-featured, seamless experience is a significant effort that detracts from their main goals.
- Whichever way you go, one thing is not up for negotiation: you must own your data — the learnings, skills, and evals your team creates by using the platform.
Compare solutions
No platform satisfies all of these principles at this time. But some are closer than others. We are building a detailed comparison, featuring leading platforms such as Buzz, Claude Tag, Superconductor, Viktor, and more.
Questions? Comments? Please reach out.
