Reliable by Design · 05.16
Replay & Partial Recovery
Restarting a run from a node, a failed branch, an edited node, or a checkpoint — deterministic partial replay.
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.
Continue
Manual, cron (natural-language to UTC), webhook, and persistent-listener triggers — how a run actually starts.
How parallel agent work gets its own git worktree, so a swarm or a converge cohort never steps on another branch's changes.