Replay as a primitive
“Replay” can mean at least two different operations, and confusing them makes agent debugging less trustworthy.
The first reuses recorded work. The second executes work again.
Cache replay
tine replay result.tine --mode cache --save replayed.tine
Cache mode materializes recorded steps without repeating their model or tool calls. It is useful for inspection, artifact workflows, and preserving known provenance. It does not prove a stochastic provider would return the same answer today.
Version 0.4 makes that distinction visible in identity, too. Cached replay deliberately uses a reproducible fork identity. A live rerun instead executes a fresh run with a new run ID.
Explicit rerun
A live rerun needs an execution environment:
tine replay result.tine --mode rerun --harness codex --save rerun.tine
Native runtimes and harnesses define what can actually resume or execute. This makes capability scoped instead of suggesting that any flat trace contains enough state to restart any agent.
Fork plus replay
The useful primitive appears when replay combines with a graph fork:
tine fork failed.tine --from-step 3 --save candidate.tine
tine replay candidate.tine --mode rerun --harness codex --save repaired.tine
tine diff failed.tine repaired.tine
The shared prefix is evidence. The new suffix is an experiment. The diff records the result.
Composition
That pattern can support regression investigation, model comparisons, prompt repair, or audit review. The semantics stay the same:
- identify trusted recorded history;
- choose whether to reuse or re-execute;
- preserve the new branch;
- compare it with the baseline.
Replay becomes a primitive when its mode and provenance are explicit enough for other workflows to build on it.