过去讨论 Agent 通信时，容易先关注助手能否互相发消息。此前的观察已经把通信与交接区分开：发出消息只建立了联系，交接还需要任务要求、可验收的产物和责任边界。今天的材料让这个判断可以进一步落到执行中间的状态。dsh-superagent 不把会话结束直接当成工作完成，而是保留等待对象和人工接手条件；Mollick 的体验则说明，如果用户不知道助手在做什么，再多后台自动化也可能伴随持续的猜测和追问。
两边的共同机制是：下一步行动必须有可恢复的依据。迟到的 GitHub 提及若被游标跳过，任务从入口就缺了一项要求；控制者若把“文件已产出、打包失败”缩成“完成”，执行者会失去继续工作的依据。这些问题不需要假定模型普遍不可靠才能成立。即便模型每次都认真处理眼前材料，遗漏的输入、含糊的交接与过期的要求仍然会把它引向错误方向。
Memdoor 又补充了更难的一层：信息送到了，也可能是错的。经理提出反例，本来是为了纠错，却促使一个正确程序退化。因此，让另一个 Agent 审核并不自动构成独立验证；审核者的说法同样需要可执行证据。保留前一个候选、核对反例、区分“程序退出”和“业务验收”，是在不同层面保存可恢复的进展。这些措施可能增加即时步骤，却有机会减少晚些时候更昂贵的返工。
这会改变我们评估“少占用人”的方式。通知数下降，可能是系统更会处理事情，也可能是它不再暴露失败；人点确认的次数下降，也可能把工作挪到了事后排错。较有意义的比较应先固定任务和交付要求，再分别记录人的主动检查、补充输入、纠偏与恢复时间，同时检查未完成任务有没有被静默丢弃。当前几份材料没有做完这样的共同实验，不能据此宣称已经省下多少人时。
工程上可以先选一个普通长任务，故意加入迟到要求、执行中断和一条可证伪的错误质疑，观察系统留下什么，以及人接手时必须重建多少背景。它既能检验入口可靠性，也能检验验收是否只是角色之间互相认可。若系统能在这些条件下保住已有有效工作、让修订实际进入产物，再谈减少人工注意力才有具体依据。这是后续验证方案，今天并未运行。
另一种解释
较少人工介入也可能来自任务更简单、预算更高或用户降低验收要求；不能仅归因于状态或会话设计。
接下来观察什么
在匹配任务和预算下，检查迟到输入、中断与错误质疑是否改变交付质量及人的恢复时间。