Time travel & replay

Time travel is Cendriix's run replay capability. Because every run records a complete, deterministic snapshot, any past run can be re-executed step by step. This guide covers how replay works and what it is used for.

What time travel is

Every run captures everything needed to reproduce it: the workflow version, the agent definitions, every LLM prompt and completion, and the arguments and responses of every tool call. Time travel feeds that snapshot back through the orchestrator to reconstruct the run exactly, or to re-run it under different conditions.

How deterministic replay works

A replay does not call the LLM or the real services again. Instead the orchestrator serves the recorded completions and tool responses from the snapshot, so every step produces the same output it did originally. The result is bit-for-bit deterministic, the same run, every time, with no cost and no side effects.

# Replay a run and stop at step 3 to inspect state
cendriix replay --run run_a1b2c3d4 --step 3

# Full deterministic replay (safe, no side effects)
cendriix replay --run run_a1b2c3d4 --dry-run

Inspecting a past run

In the dashboard, the run view has a timeline scrubber. Drag it to any point in the run and the inspector shows the full state at that moment: which agent was active, the prompt it received, the tool it was about to call, and the accumulated cost. This is the fastest way to answer "what was the agent thinking when it did that?" for a run that finished weeks ago.

Testing policy changes

Replay can re-run history under a changed policy. You point a candidate policy at a real run, and the orchestrator replays it with the new rules active and side effects intercepted. The output tells you exactly which calls the new policy would have blocked or gated, proof, on real traffic, before you enable it.

cendriix policy test \
  --file .cendriix/policies/production-safety.yaml \
  --run run_a1b2c3d4

Synthetic runs

Every replay is marked synthetic. Synthetic runs appear in the run list with a distinct badge and never produce audit events that could be mistaken for real production activity. This keeps the audit log a faithful record of what actually happened, not what you replayed for debugging.

What replay cannot do

Replay reproduces a run; it does not branch it. You cannot edit a step's output and continue from there, the snapshot is immutable by design, because that immutability is what makes the audit trail trustworthy. To run the same work with changes, trigger a new run from the same inputs.

Next steps