Long-running agent jobs fail in a different way than short tasks. The problem is often not that the agent did nothing; it is that the final report compresses an hour of decisions into a few vague sentences. A checkpoint summary gives the run enough structure that a reviewer can see what changed, what was verified, and where uncertainty entered.

A checkpoint is not a raw transcript. It is a small public-safe digest written at useful boundaries: after discovery, after the first change, after a failed verification loop, before deployment, or before stopping on a blocker.

Summarize state, not chatter

A good checkpoint answers four questions:

  • Goal: what was the agent trying to accomplish during this segment?
  • Evidence: what observations changed the agent's understanding?
  • Action: what was edited, generated, skipped, or intentionally left alone?
  • Next gate: what check must pass before the agent continues?

That format keeps the agent from narrating every command while still preserving the decisions that matter. For example:

Checkpoint: pre-deploy readiness
Goal: confirm the public content build is safe to publish
Evidence: content validation and local build completed successfully
Action: regenerated public indexes; no generated files were hand-edited
Next gate: deploy only if the live article, feed, sitemap, and robots routes verify

The summary is portable because it names evidence classes instead of private paths, account identifiers, raw logs, or environment-specific details.

Place checkpoints before irreversible steps

Checkpoints are most valuable just before a run crosses from local work into a visible or hard-to-reverse action. Publishing, deleting, rotating, notifying, migrating, or overwriting should all have a short pre-action checkpoint.

Useful runbook language looks like this:

Before any external side effect, write a checkpoint containing the intended action, the latest successful verification, and the rollback or stop condition. If the checkpoint cannot name the verification, stop and report a blocker.

That rule forces the agent to prove it is still following the runbook before it acts. It also gives humans a compact audit trail when the final result needs review.

Keep the final report small

The final report should not repeat every checkpoint. It should reference the important ones: what passed, what changed, what was blocked, and what was deliberately not attempted. When a run succeeds, checkpoints become the source for verification receipts. When it fails, they become the map back to the last known-good state.

Rule of thumb: if a long-running agent job would be hard to explain after the fact, add checkpoints before the explanation is needed.