Temporal 团队介绍了 pi-temporal，让 Pi 编码 agent 运行在一组 Temporal Worker 上。当机器在执行命令中途故障时，另一个 Worker 可接手当前轮次，同时保留 Pi 的会话、工具和终端界面。其关键处理是：对结果不明的工具调用，不自动重跑，而是交由模型检查当前状态后决定下一步。
据 Temporal 介绍，自动接管适用于通过 /background 或命令行启动、交给 Worker 执行的任务。在终端界面中直接进行的一轮对话仍运行于本地 pi 进程；进程崩溃后，用户需要重新打开 pi 恢复。
文章将这项实验与 Earendil 团队发布的 Pi Durable 作了对照：后者提供任务检查点、带请求 ID 的去重提交，以及先记录意图再执行外部操作等机制。据 Temporal 转述，Pi Durable 内置的持久化后端同一时间由一个进程持有存储，没有跨进程锁；默认 SQLite 配置可应对进程崩溃，但断电或宿主机故障可能导致最新提交丢失。换机恢复需要取得幸存存储，并由新进程重新打开。
pi-temporal 则把一个会话映射为一个 Workflow，将模型调用、单次工具调用和步骤结果记录拆为 Activity。对话状态仍保存在 Pi 会话文件中，每个 Activity 开始工作前都从文件重建当前轮次。项目文件通过 Git bundle 在 Worker 间传递，保存在共享存储的会话文件旁，Temporal 本身不存储项目文件。
机器失联不意味着命令没有执行。文章举例说，git push 可能已经成功，只是结果尚未记入会话。因此，执行器会在调用工具前写入 claim，命令返回后再保存结果：重试时若找到结果，就直接复用；若只有 claim，则报告“结果未知”，要求模型检查状态后再决定是否发起新调用。
对于超时后仍在运行的旧尝试，系统通过租约检查拦截其后续会话追加。但文章明确指出，这只能阻止过期尝试写入对话记录，工具仍可能产生外部影响。
发布方的 chaos demo 在 Docker 中启动 Temporal 开发服务器和三个 Worker，提交一次多步编码任务，每隔 15 至 40 秒杀掉正在工作的 Worker，全程不重新提交任务。作者称，在其测试过的运行中，当前轮次最终完成，目标文件内容正确。
上述结果属于发布方测试。文章同时限定，跨 Worker 恢复需要相关基础设施持续可用；不自动重跑结果未知的调用，也不代表被中断的命令没有产生影响。
