Determinism and replay describe how a durable runtime makes non-deterministic agent runs reproducible: every step result — each LLM response, tool output, and decision — is recorded as it happens, so the run can later be reconstructed step by step from the record instead of re-executing the model or its side effects.
Why determinism and replay matter
Two production problems share one root cause. The first is reproducibility: a model given the same prompt twice may answer differently, so investigating an agent failure by re-running the agent produces a different conversation than the one that failed. The bug being chased may simply not happen again. The second is recovery: when a process dies halfway through a run, resuming it — the heart of crash recovery — is only safe if the runtime can restore the exact position of the run without executing anything twice. Re-executing a completed payment step charges the customer again.
Both problems dissolve if every non-deterministic result is recorded the moment it is produced, and the run can be rebuilt from those records at will.
How it works
The mechanism is record-and-replay, inherited from durable workflow engines:
- During live execution, every non-deterministic operation — each model call, tool call, and external read — runs exactly once, and its result is appended to the run record.
- The orchestration logic around those operations is kept deterministic: given the same sequence of recorded results, it always takes the same path through the control flow.
- To replay, the runtime walks that control flow again, but wherever a recorded operation appears it substitutes the stored result instead of executing it. No model is called, no side effect repeats, and the walk arrives at the identical state every time.
- Replay stops at the first step with no recorded result, and live execution takes over from there — which is exactly how a resumed run continues after a crash.
Replay vs. re-run
A re-run executes everything again: new model calls, new tool calls, new side effects — and, because the model is non-deterministic, quite possibly a different outcome. A replay executes nothing external. It reconstructs a past run from its recorded step results, so it is fast, free of side effects, and lands on the same state every time. A re-run answers what would happen now; a replay answers what happened then. Confusing the two is expensive: re-running an agent that already sent an email sends it twice.
In practice
In a durable runtime, recording is not an optional debugging mode but the substrate of durable execution itself: each step result is checkpointed into the execution history, and replaying from that history is how a healthy worker resumes a run that a dead one left behind. The same records support evaluation of prompt or logic changes against real past runs rather than synthetic tests. For the rationale behind recording every step, see why a durable runtime.