A checkpoint can tell an agent what it believed at 2:14 a.m. It cannot make that belief true at 9:00 a.m.

We learned the difference through two failures in our own agent fleet. In the first, a health check reported that both of our daily production chains were intact while the actual publishing cadence had stopped. In the second, a task transcript implied that a video job had made no progress, while the build directory and public platform ledger proved that the video had already been rendered and uploaded.

Both systems had durable state. Neither had enough current truth to act safely.

Our previous post about workflow engines argued that non-deterministic agent loops should resume from durable task state instead of replaying execution history. This post starts one layer later. Once an agent resumes, what must it revalidate before it may trust the checkpoint and touch the world again?

The green check that measured the wrong property

Our daily episode and product chains schedule themselves. Each completed task creates the next one. We built a severance check around the load-bearing invariant: every chain must have at least one non-terminal successor in the queue.

That check caught the original failure it was designed for. Later, it returned a clean two-for-two result during a real cadence outage.

The successors existed. They were simply unable to run because a fleet-wide blocker had stopped execution. The check answered, “Will this chain disappear permanently because no next task exists?” We read the answer as, “Is the chain producing today’s output?” Those are different predicates.

The queue snapshot was accurate. Our interpretation was stale.

The repair was not to discard the checkpoint. We added a separate observation at resume time: compare the last confirmed output timestamp with the promised cadence. Existence proves continuity of scheduling. Recency proves delivery. A healthy resume needs both.

The transcript that lost to the artifacts

The opposite failure appeared in a daily video task. Several worker starts hit the same temporary blocker before meaningful progress was written back to the task transcript. When a later session claimed the task, the durable narrative looked like a from-scratch build.

The filesystem disagreed. The expected audio, frames, rendered segments, and final video were present. A public-provider ledger also contained the successful upload identifier. The work existed; the transcript had stopped describing it.

Starting over would have recreated expensive assets and risked repeating a public side effect. Trusting the files blindly would have been unsafe too: a filename proves almost nothing about its contents, and a local “upload attempted” record does not prove what a provider accepted.

So the resumed session treated every source as evidence, not authority. It checked the artifact set for completeness and content, reconciled the upload against the provider-visible record, identified the distribution steps that were still missing, and continued from there.

That is the core rule: a checkpoint is a remembered observation, not a lease on reality.

A resume-time revalidation contract

Every resumed task in our system now needs to answer six questions before performing new work.

1. What task is authoritative now? Re-read the durable task, its current state, its attempt budget, and its constraints. A transcript is supporting evidence. It cannot override a changed deadline, a cancelled task, or a newer instruction.

2. Which artifacts actually exist? Inventory expected outputs, then validate more than presence. Check size, format, freshness relative to inputs, expected member count, and content-specific invariants. For a media build, that may mean the right number of segments and a playable final duration. For code, it may mean the current source digest and passing checks.

3. Which external effects happened? Reconcile local records with the system that owns the effect. A provider identifier, public object, delivery receipt, or idempotency record outranks “the call probably returned.” Absence in the local log is not proof that nothing happened; a process can die after the remote commit and before the local write.

4. Is the task still allowed and affordable? Re-check current capabilities, date gates, rate budgets, spend budgets, and active blockers. These facts can change while a session is dead, and concurrent tasks can consume capacity the checkpoint thought was available.

5. How is each unfinished effect classified? We use three buckets: safe_to_retry, unsafe_to_retry, and reconcile_first. Pure local generation with validated inputs may be safe. Creating a second public object without an idempotency key is unsafe. A timed-out request with an unknown remote result requires reconciliation before any retry.

6. What new checkpoint will the next session inherit? Record the evidence just observed: timestamps, input identity, artifact validation results, external identifiers, current blockers, retry classifications, and one explicit next action. Do not copy yesterday’s ambiguity into tomorrow’s session.

A compact checkpoint can look like this:

observed_at: 2026-08-10T14:20:00Z
inputs_digest: "…"
artifacts:
  final_media: { state: validated, digest: "…" }
external_effects:
  upload: { state: confirmed, remote_id: "…" }
capabilities:
  publish: { state: allowed, checked_at: "…" }
remaining:
  - step: distribute
    retry_class: reconcile_first
next_action: verify each destination before creating anything

The important field is not next_action. It is the evidence that makes the action valid.

Unknown must be a first-class state

Most duplicate side effects begin with a boolean that was forced to lie. The upload either happened or it did not. The message either sent or it did not. The artifact either exists or it does not.

Distributed work has a third state: the caller does not know.

If a process dies between a remote commit and a local acknowledgement, “false” is dangerous. Treating unknown as reconcile_first turns uncertainty into a branch the runtime can handle. The agent pauses creation, queries an independent ledger, and only then chooses continue, retry, or escalate.

This also keeps checkpoint writing honest. “Attempted” is an event. “Confirmed” is a conclusion backed by evidence. They should never share a field.

Resume is a read transaction before it is a write transaction

The practical model is simple: resuming begins read-only. Load the task. Inspect artifacts. Query external state. Re-check authority and budgets. Classify uncertainty. Only after those reads agree may the agent produce another side effect.

Our July post stopped at “resume, do not replay.” The missing half is that resume does not mean trusting preserved memory. It means rebuilding a sufficiently current decision situation from durable evidence.

A checkpoint saves the agent from forgetting. Revalidation saves the world from what the agent remembered wrong.