同一个人，在标识清楚的地铁站里，可以很快找到换乘方向；进入出口编号混乱、指示牌缺失的车站，却可能反复走错。人的能力没有突然下降，变化的是环境提供信息的方式。改善寻路表现，可以训练人记住路线，也可以重新设计标识；标识是否有效，又取决于使用者能否看见和理解它。
主体实际表现出的能力，发生在它与环境的交互中。因此，理解和设计一个持续行动的智能系统，需要将智能体、环境以及两者之间的交互共同建模。
共同建模需要表达：环境中的哪些信息能够被主体感知，主体可以采取哪些行动，行动会改变什么，以及结果如何返回下一轮判断。主体能力与环境条件需要通过这些关系对应起来，才能判断困难出在哪里、应该改进哪一部分。随着主体积累经验、环境被行动改变，这种对应关系也需要持续更新。
当讨论 Agent 如何进入现在的工作系统时，这个思路会暴露一个长期被人承担、因而容易被忽略的问题。
企业中的软件、表单和流程能够运转，往往依赖人不断补充解释和协调。“采购完成”究竟指下单、到货还是验收入库，两张表里的物料是不是同一批，交付日期变更后谁需要调整计划，这些问题可能由熟悉业务的人临时确认，却没有成为系统中稳定的定义与关系。业务能够靠人运行，并不意味着系统已经完整承载了使它得以运行的业务逻辑。
要求 Agent 判断订单能否按期交付，就需要知道订单对应哪些物料和生产任务、当前状态是什么、哪些依赖会影响交付。如果这些关系从未被明确记录，那么换一个更强的模型，也不能保证它每次都恢复出同一套业务事实。 此时值得改进的，包括对象定义、状态承载和依赖关系，而不仅是 Agent 的推理过程。
更进一步，有些内容连业务本身都尚未确定：不同部门对“完成”的标准并不一致，例外由谁决定也没有约定。这样的空缺需要相关主体作出业务决定。模型可以识别歧义、提出方案，但它自行补出的解释，不能直接当作组织已经达成的共识。
如果每个 Agent 都在自己的上下文里补全这些空缺，局部任务即使能够完成，彼此的判断也可能建立在不同前提上。某个 Agent 认为采购已经完成，另一个却仍在等待物料。增加消息交换，可以帮助它们发现分歧；要稳定解决分歧，还需要明确它们共同引用的对象、状态与规则，并确定由谁维护。
因此，Agent 的设计需要同时回答环境一侧的问题：哪些事实由系统持续提供，哪些规则需要业务先定义，哪些判断交给 Agent，哪些结果需要人确认，以及执行后如何更新共同使用的状态。这些选择决定了 Agent 实际需要承担多大的理解与判断负担。
共同建模的价值，是让我们能够判断：哪些困难值得交给更强的智能解决，哪些困难应该通过重新组织环境来消除。 当同一份结构需要被反复推断、同一个歧义需要被反复解释时，把它明确下来并持续维护，本身就是对整个智能系统的改进。