设想一份正在准备的建议书：研究员工补充了一个适用限制，内容员工却仍依据旧结论写作；负责人发现以后，又要找到原材料，解释限制，指定哪一段重写。两位员工都做了工作，协调仍然回到了人手里。
这种失败发生在工作的连接处。谁对更新负责，下一位应该依据哪一版，已经写好的内容需要重看什么，光靠几个并行窗口很难回答。执行者增加以后，如果这些问题仍全由人记住，团队越大，转述和核对可能越多。
Teloa 要组织的，是能够延续的责任。一次交办完成以后，原负责者、采用依据与交付结果还要找得到；下一次相似工作开始，已经修正的方法也要有地方继续使用。
为什么下一次仍然找它
一位临时助手可以把这份建议书做得很好。长期研究员工的意义，要到下一次合作才更清楚：用户已经认可的来源标准、对不确定条件的处理方式和交付检查，可以继续围绕同一个岗位维护。
“研究员”这个名字本身提供不了这些东西。真正值得保留的是工作约定：调查到什么程度，哪些结论需要依据，材料不足时怎样交代，交给下一位以前还要检查什么。职责、知识、技能与工具共同帮助它履行这项约定。
岗位身份因此比一次运行存在得更久。客户资料和本次期限会变，研究方法可以修订，原负责者与历史交付仍有联系。人的纠正有了维护位置，下次就有机会从已经形成的标准开始合作。
什么责任值得成为岗位
建立长期员工也有成本。每增加一个岗位，都要判断职责是否重叠，资料与方法由谁维护，交付怎样接给别人。一个偶尔出现的小问题，未必值得留下整套长期配置。
社区版支持从主聊交办独立通用工作，用户可以先完成一件事。等同类要求反复出现、交付标准逐渐稳定，再保留为岗位。形成员工的理由，应当是有一项值得持续负责的工作，而不是目录还缺一个职业名称。
执行量也可以临时扩大。一位研究员工需要核查多组独立材料时，可以采用任务内的临时助手，原负责者继续整合结果。准备输入、等待和解决冲突都会增加成本；高度相关的问题，留在一起处理可能更合适。是否拆分，取决于工作瓶颈，长期岗位名单无需跟着每轮执行膨胀。
交接时，把冲突一起带过去
回到开头的建议书。研究第一版支持较短交期，第二版增加了“仅适用于资料齐全的标准项目”。内容员工已经写好的承诺，需要重新判断。把新版文件发过去，只完成了材料传递，还没有解决它与旧正文之间的冲突。
群讨论可以让研究说明限制、内容追问影响，负责人再决定采用怎样的表述。讨论保留理由，明确交办让修改有人负责。这两种需要相接，也都值得保有适当的轻重：一句追问可以继续交流，一项明确交付则进入关联任务。
一次有用的交接，至少要交代三件事：
- 采用依据：使用哪份成果、哪一版，新增限制在哪里。
- 待处理差异：旧内容哪些地方与新依据不一致，哪些问题还没有决定。
- 交付责任：由谁继续，返回什么，谁判断这次修改是否合适。
当前群工作可以把前序结果与相关资料固定为输入，所需条件不足时保留原工作等待。相关内容是否正确吸收了变化，仍要沿具体交付核对。保存版本与关联关系，是为了让这次核对有明确对象，而不是让一条更新消息自动替所有后续内容作出判断。
让结构承担协调，给人留下判断
项目围绕共同目标组织相关工作，任务承接具体交付，群保留讨论，成果保存内容版本。它们在这里各有用处：负责人发现一句承诺不妥，能够回到原依据和负责者，继续处理同一件事。
这些结构值得保留到什么程度，要看它们减少了哪项协调负担。一个人带领 AI 团队，仍然要决定目标、风险和接受什么结果；产品则尽量承担找回来源、辨认版本与连接原工作的事务。社区版先在一人工作空间中推进这件事，无需为了拥有团队而先复制一家公司完整的层级制度。
下一次研究再出现同样的适用限制，理想的起点是岗位已有的检查标准；下一次交接发生分歧，负责人能直接看到差异与待决定之处。人仍然作判断，合作却可以少一些从头转述。这才是保留一支团队，比每次重新打开几个 Agent 更值得的地方。