Checkpoint

Saving a checkpoint does not automatically make external side effects safe to retry; if the agent had already initiated a refund through a payment API before crashing, replaying from the checkpoint could result in a duplicate refund.

A checkpoint should contain a stable run or thread identifier, the current workflow step and task status, intermediate results of completed actions, pending actions with retry counts and timestamps, and the schema or workflow version.

MissionFlow's state checkpoints occur mid-reasoning and contain the mission definition, reasoning trajectory, current context, and next-step plan, and are used for recovery after an Agent crashes or times out.

The two design pillars of the workflow are checkpoints and gates; gates are mandatory checks that every piece of work must pass, and work that does not pass cannot proceed to the next task.

After Helix reads one screen of the old app, it breaks the work down into smaller task units called checkpoints.

Shopify's rule is that the next checkpoint cannot begin until the previous one has been completed correctly, and checkpoints are arranged in order of increasing complexity.

The checkpoint mechanism allows an agent to save its state at critical steps, so that on error it can recover from the most recent checkpoint rather than starting over.

Checkpoint granularity is a trade-off: too sparse means large losses on failure, while too dense significantly increases storage and serialization overhead.

Designing a sound checkpoint system requires solving the idempotency problem, meaning that re-executing certain steps after recovering from a checkpoint will not produce side effects.