The worker can stop. The work can continue.

What the next worker reads

Shopify’s Aquifer keeps session identity and an append-only event log in Postgres. An idle worker can exit; a fresh worker reads the same conversation when the next interaction arrives. [1]

Sentry’s Junior pauses near a serverless deadline and queues a continuation task. Its intended pause point is the end of a tool result. This describes task continuation; it does not document recovery of every local file. [2]

Sierra’s Agency restores a hibernated runner by replaying ordered events from its last checkpoint. The application-specific runner decides what goes into the checkpoint and subsequent events. That choice determines what replay can restore. [3]

Conversation, files, and effects

These mechanisms preserve different records. A restored conversation does not imply that a workspace file survived. A restored file does not establish whether an earlier request completed in another system.

Our inference is that recovery needs to identify which of these records the next worker can trust. For an external action, a receipt or an idempotency mechanism may be needed to distinguish a completed request from one that needs retrying. The reports above do not establish that their session recovery provides this property for every connected tool.