GoKawiilMost durable execution systems recover by replaying retained execution history. After a worker fails, a fresh worker loads the history and re-executes the program until it reconstructs the current position.
This is a useful model. It provides durable progress while allowing workers to remain ephemeral. But it also makes accumulated history part of the recovery path.
That tradeoff becomes more noticeable for programs that operate for hours or days, call many tools, wait for external events, create child executions, and change direction dynamically. Long-running agents increasingly have this shape.
I’ve built and evaluated a different recovery primitive: checkpointing the program continuation instead of reconstructing it from history.
Transparent Continuation Checkpointing
I call the approach Transparent Continuation Checkpointing, or TCC.
At durable boundaries, the compiler and runtime capture the live continuation: the control state required for the program to continue from its current position. When execution resumes after a failure, the runtime loads the committed continuation and restores the program directly.
History replay reconstruct TCC resume History replay reconstructs the current position. TCC restores the committed continuation and resumes.
The distinction is:
History replay
... continue reading