Work items
已上线，公共 API一个工作单元，包含简述、来源、依赖、验收标准、决策、负责人及自身事件历史；它持久保存，并由 REST、CLI 与进程内调用方共享的同一份命令文档驱动。
modules/sessions/work_model.go · modules/sessions/work_api.go
产品 · work plane
并非访问地图的另一半
本站大部分内容讲的是智能体能够触及什么。本页讲的是智能体与会话如何协调工作本身，以及每个组件目前的实际覆盖范围。
它为何存在
没有 work plane 的治理，只是一块无事可管的仪表板
Olivares AI 有两个部分，并随同一个二进制文件交付。一部分运行并连接工作；另一部分观察并治理工作。任何一部分都不是另一部分的装饰：没有治理的 work plane 会产生事后无人能说明和追责的工作；没有 work plane 的治理，则只是一块无事可管的仪表板。
这一部分所解决的问题并非假设。这个项目在自身开发过程中就吃过这些苦头：会话之间彼此不可见，状态互相偏离，工作重复执行，以及只存在于一个终端中、终端关闭便随之丢失的决策。
什么确实存在，什么并不存在
逐一说明每个组件的实际覆盖范围
边界由代码强制执行，而不是停留在文字承诺中。如果组件的范围比概念本身更窄，这里会明确写出限制，并由测试将其约束在该范围内。
Leases
已上线，公共 API以受 fencing 保护且会到期的权限表示归属：获取、续期、释放、接管、撤销。持有过期 lease 的主体无法继续操作 work item；并发获取时恰好只有一个胜者。
modules/sessions/work_lease.go
消息、确认回执与交接
已上线，范围经明确限定绑定到 work item 的持久化对话，支持 replay，并拒绝过期 epoch。确认回执尤其值得停下来说明：协调失败更常见的原因，是消息已被看到却没有得到行动，而不是消息从未送达；“已读”和“已回复”不再是同一个意思。
它在编排工作流之内确实存在。通用的跨域收件箱被有意保持为未接线状态；这一边界由系统强制，而非停留在承诺中：启动测试固定了启动过程所绑定的权威源及其顺序；四种已知的预备性激活中任何一种出现时，测试都会失败。这不是穷尽式 allowlist——未来若出现采用其他 selector 的路径，需要自己的测试用例——但误接任何已做好接线准备的路径，结果会是测试变红，而不是上线后才出现意外。
modules/sessions/communication_model.go（数据结构）· communication_ack_service.go 与 communication_ack_apply.go（确认回执路径及其 epoch 检查）· cmd/olivares/communicationauthorityboot_test.go（保持公共 plane 未接线的启动测试）
针对 work item 的启动
已上线，范围经明确限定先预留、取得 lease，然后才启动会话——持久化 work、epoch、fence 与 execution，使重试保持安全，而不会变成第二次执行。
仅通过编排提供，不作为独立入口。
modules/sessions/runtime_work_launch.go
通过 A2A 远程执行
已上线，范围经明确限定在已授权 peer 上规划、测试、启动、观察和取消工作，并持久保存所委派内容及返回内容的回执。
仅在已配置目的地时挂载。没有已授权目标时，接合点完全不会挂载——不存在仅因配置文件提出请求，就把工作派发给任意 peer 的路径。
cmd/olivares/wire.go · cmd/olivares/orchremote.go
影子模式与工作的最终决定权
不存在；无此实现先与当前运行的系统进行双份报告，并通过比较器对照，然后才可能由 work plane 作出决定。
这并非“即将推出”，也不是“部分实现”：它不存在。目前的部署无法把会话的最终决定权交给 work plane；产品中的任何内容都不应被理解为提供了这项能力。如果它将来确实出现，也会同时带来有效性证据——与现有来源进行比较的观察窗口，而不只是版本号变化。
仅有设计
如何阅读本页
对“智能体相互交谈”的如实说明
Work items 与 leases 是目前即可操作的普通 API 表面。智能体之间的对话确实存在并会持久保存，但仅限于编排工作流；不存在面向任意智能体的通用消息总线。远程委派可以工作，并会拒绝未知 peer。
不存在的内容不会在界面中列为“即将推出”，而会像上面一样明确标为不存在。否则，您会在集成时花掉整整一个下午才发现它；本项目拒绝作出这类断言。另请参阅信任中心以及 Claude Code 的治理方式。