Replay & Partial Recovery

You shouldn't have to re-run what already succeeded

Partial replay restarts a run from a specific point rather than from scratch: a chosen node, the branch that actually failed, a node that's since been edited, or an explicit checkpoint. This is what makes fixing one broken step in an otherwise-successful nine-step run cheap instead of paying for all nine steps again just to re-verify the eight that already worked.

Content-hashed graphs skip redundant re-validation

Snapshots are content-hashed, so replaying against an unchanged graph resumes directly without re-running validation that already passed against the exact same structure. Change the graph, and the hash changes with it — replay correctly treats that as a materially different situation rather than blindly resuming as if nothing moved.

Failed-frontier replay preserves successful ancestors

A failed-branch replay resets the failed node (or the nodes named by a deficient verdict's evidence) and every descendant that depends on it. Completed ancestors and unrelated completed branches remain immutable reuse inputs, and preserved trigger nodes are removed from the ready queue so the root cannot secretly fire again. If the verdict names no valid producer frontier, Agentis refuses to create a hollow replay rather than launching a child run that cannot progress.

Debug resumes automatically; root restart is a decision

agentis.workflow.run with debugRun:true now defaults to the latest same-graph failed or deficient frontier and reports resumedFromRunId plus the reused node ids. If a same-graph debug run is already active, the tool returns that run for awaiting or inspection instead of starting a duplicate. Pass restartMode:"fresh" to intentionally start from the trigger. Supplying replacement inputs also forces a fresh run, because cached outputs proven under different inputs are not safe to reuse.

Continue