Checkpoint

Persisted run state that lets a workflow resume, replay, or diagnose work after interruption without relying only on in-memory progress.

A checkpoint may record completed work units, cursor position, input and code versions, intermediate artifacts, and external-effect identifiers. Its frequency balances recovery cost against write overhead. Saving 'step complete' separately from the external effect can still create duplicates or skips after a crash, so idempotency or transactional boundaries remain necessary.

Builder example

Checkpoints improve recovery for long jobs, but resuming against changed inputs, prompts, tools, or code may be unsafe. A workflow should detect version drift and decide whether to continue, restart, or migrate the saved state.

Common confusion: A checkpoint records how far a run got so it can resume; a backup copies your data so you can restore it later. What separates them is purpose: a checkpoint tracks step-by-step run progress to avoid repeating work, while a backup preserves the underlying records themselves.