Durable execution without history replay | Trigora

Trigora Technology Demo Research Blog Docs GitHub Technology Demo Research Blog Docs GitHub Get early access → Get early access → Blog Durable execution without history replay Omar Abdelrahman · 9 September 2026 Most 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
Load retained history → re-execute the prefix → reconstruct the current position
TCC
Load committed continuation → restore live execution state → resume
External effects remain explicit durable operations. Completed durable work is not repeated after recovery, and unsupported language constructs fail during compilation rather than producing ambiguous runtime behaviour.
The current prototype supports durable effects, external waits and events, child executions, cancellation, structured concurrency, and crash recovery.
What changes
TCC does not make recovery constant-time. Recovery remains sensitive to the size and structure of the live continuation.
The intended change is in what recovery depends on.
With replay, recovery is influenced by the execution history retained to reconstruct the current position. With TCC, recovery is influenced primarily by the state the program still needs.
A program that has performed ten thousand operations but retains a small live continuation should not necessarily become harder to recover simply because its past is long.
Preliminary evaluation
I ran a controlled comparison in which live continuation state remained approximately fixed while durable-boundary depth increased from 10 to 1,000.
Recovery latency vs prior durable-boundary depth 1ms 10ms 100ms 1s 10 100 1000
durable-boundary depth

TCC recovery

Temporal reconstruction
Controlled evaluation · ~4 KB live state
In that evaluation, TCC recovery remained between approximately 0.6 and 0.9 milliseconds. Fresh-worker replay reconstruction in the evaluated Temporal baseline increased from approximately 61 milliseconds to 1.7 seconds.
Worker creation was excluded, the live state was approximately 4 KB, and these results should not be interpreted as a general production-speedup claim. They demonstrate a difference in recovery scaling under the tested conditions, not that every TCC workload will outperform every replay-based system.
Methodology and limitations
I have also exercised the execution semantics across 50,000 generated cases, with no observed semantic failures in the evaluated subset.
What remains difficult
Turning the prototype into production infrastructure still involves substantial work:
Portable continuation representationProgram and checkpoint versioningEfficient handling of larger live statesDurable storage and commit protocolsOperational observabilityCompatibility across language frontendsFramework integrationsLong-running correctness and failure testing
There are also design questions around checkpoint retention, branching from previous continuations, migration between runtime versions, and how much of the execution representation should remain stable across languages.
I’m building Trigora around this model, initially for long-running AI agents. The broader question is whether continuation-based recovery can provide a better execution substrate for dynamic, long-lived software.
The architecture, semantics, benchmark setup, and current limitations are described in more detail in the technical paper. You can also see continuation recovery in action in a controlled demonstration of the current TCC compiler/runtime.
I’d be particularly interested in criticism from people who have worked on workflow engines, compilers, checkpointing systems, or distributed runtimes.
See continuation recovery in action. Trigora is building the
execution layer for long-running AI agents.
[email protected] TRIGORA Durable execution for the agent era. Technology TCC Research Blog Whitepaper Benchmarks Developers Docs GitHub Company About Contact Privacy Terms © 2026 Trigora [email protected]

Most durable execution systems typically recover from failures by replaying retained execution history: a fresh worker loads the history and re-executes the program until it reconstructs the current position. While this model provides durable progress and allows workers to be ephemeral, it incorporates accumulated history into the recovery path. This approach presents a noticeable trade-off for long-running agents that involve dynamic changes, waiting for external events, creating child executions, and shifting direction, leading to increasingly complex execution shapes.

To address this, the author proposes a different recovery primitive called Transparent Continuation Checkpointing, or TCC. TCC operates by capturing the live continuation—the control state required for the program to continue from its current position—at durable boundaries enforced by the compiler and runtime. When execution resumes after a failure, the runtime loads this committed continuation and restores the live execution state directly. The fundamental distinction between the two methods lies in what recovery depends upon: history replay reconstructs the current position by loading retained history and re-executing the prefix, whereas TCC restores the committed continuation and resumes the execution.

This difference ensures that external effects remain explicit durable operations, meaning completed work is not repeatedly executed upon recovery. Furthermore, TCC avoids producing ambiguous runtime behavior resulting from unsupported language constructs during compilation, unlike history replay. Although TCC recovery is not constant-time and remains sensitive to the size and structure of the live continuation, the recovery mechanism shifts its dependence from the execution history to the state the program still requires. The author suggests that this means recovery is less influenced by the length of past operations and more directly related to the necessary continuation state.

Preliminary evaluation demonstrated a clear advantage for TCC in terms of recovery scaling. In a controlled comparison, when the live continuation state was approximately four kilobytes, TCC recovery latency remained very fast, between approximately 0.6 and 0.9 milliseconds. In contrast, fresh-worker replay reconstruction showed significant latency increases, ranging from 61 milliseconds up to 1.7 seconds as the depth of the durable boundary increased from ten to one thousand. These results indicate that TCC exhibits superior scaling in recovery performance under tested conditions, demonstrating a significant advantage in recovery speed compared to history replay.

Despite these positive results, transforming the TCC prototype into production infrastructure requires substantial development. Remaining challenges include establishing portable continuation representation, implementing efficient program and checkpoint versioning, handling larger live states, developing durable storage and commit protocols, ensuring operational observability, and achieving compatibility across different language frontends. Further design questions remain regarding checkpoint retention, branching from previous continuations, migrating between runtime versions, and maintaining the stability of the execution representation across languages. The overall goal is to use this continuation-based recovery model to build an execution substrate for dynamic, long-lived software, particularly for long-running AI agents.