Checkpoints for Long AI Agent Tasks: Resume Without Repeating Work

A checkpoint is a saved, verifiable record of a completed step in a long agent task, written before the next step starts. When a run fails partway through, the agent restarts from the latest checkpoint that passed verification, so finished work is not repeated and unfinished work is not skipped. The design decisions are where the checkpoints sit, what each one records, and how the restart decides what is already done.

Key takeaways

• Place checkpoints after steps that are expensive to repeat, change systems outside the agent, or produce output that later steps depend on.
• Record what a restart needs: inputs, outputs, status, external reference IDs, versions and the next action.
• Make every external write safe to repeat with a stable key, and record the intent before each call.
• On resume, check the outside world before retrying any step that may already have taken effect.
• Test resumption by interrupting real runs at each checkpoint and comparing the result with an uninterrupted run.

Why long agent tasks break in the middle

A task that runs for days touches many things that can fail independently: a model API that starts returning errors, a tool that times out, a source document that changes under the agent, a deploy that rewires a connection, or a host machine that restarts. Most of these failures are temporary. The real risk is what the agent does next. Without checkpoints, a restart has two options, and both are poor. It can start from the beginning, which repeats work and can send the same customer message twice or create duplicate records. Or it can try to continue from whatever it remembers of its progress, which invites skipped steps whose results were never saved.

Rate limits are a common trigger. A run throttled late in its sequence should not force a rerun of every earlier step. For the throttling side of this problem, see API rate limits and AI agents once you have mapped where your task spends its time.

Where should the checkpoints go?

Not every step needs one. Checkpointing everything adds storage, review burden and noise, and it makes the record harder to read. Place a checkpoint at a step when at least one of these is true:

• The step is expensive in time, money or model calls, and repeating it would be noticeable.
• The step changes something outside the agent, such as a record in a system of record, a message to a customer or a file in a shared folder.
• Later steps depend on its output, so a wrong result would pass silently into the rest of the run.
• The step closes a stage that a person may review or approve before work continues.

Steps that are cheap, read-only and deterministic can sit inside the boundary of the previous checkpoint. If repeating them costs almost nothing and produces the same result, leave them out.

Illustrative scenario: a parts distributor asks an agent to reconcile a month of supplier invoices against purchase orders. The task has four stages: collecting invoices from a mailbox, extracting line items, matching them to purchase orders and posting exceptions to an accounting queue. Checkpoints go after extraction, after matching and after each batch of posted exceptions. Collecting invoices is cheap to repeat and read-only, so it does not need its own checkpoint.

What should each checkpoint record?

A checkpoint is only useful if the restart can trust it. At minimum, each one should hold:

• A task identifier and a step identifier, so a checkpoint cannot attach to the wrong run.
• A status of verified, failed or in progress. A restart should only trust verified checkpoints.
• A pointer to the output, stored outside the model's context, such as a file path or a row reference. Store the artifact itself, not a summary of it.
• The versions that produced it: instruction version, tool schema version and model identifier. If the model changes between checkpoints, you need to know which steps ran on which version.
• For each external action, the provider's reference ID and the idempotency key that was sent.
• The next action, written as one plain sentence.
• A timestamp and a fingerprint of the inputs, so a resume can detect when the source material has changed.

Many of these fields overlap with an audit trail, and the two should be designed together. The audit trail fields every action needs cover that overlap. Keep checkpoints small enough to read. A checkpoint that stores the entire conversation is hard to inspect and tends to carry stale instructions forward into the next step.

Making every write safe to repeat

Resumption is only safe if repeating a step does not change the outside world twice. The common approach is an idempotency key: a stable identifier derived from the task and the step, sent with each external write. If the same request arrives again, a well-built API returns the original result instead of performing the action a second time. Stripe documents this pattern for its own API, and the discipline is worth copying even when your tools do not offer it natively.

Where a provider has no idempotency support, record the intent first. Before calling the external system, the agent writes a line such as that it is about to create a record under a given key. After the call, it records the outcome. On resume, if an intent exists without a matching outcome, the agent must look up that key in the external system before deciding whether to retry. Guessing at this point is the most common source of duplicate entries.

Retries should follow a written policy, not the model's judgment at the moment of failure. Define which errors are retryable, how many attempts are allowed and when the agent must stop and escalate. An AI agent retry policy walks through the decisions in more detail.

How does the agent resume without repeating or skipping?

A resume should follow the same procedure every time, so that a person reviewing a failed run can predict what happened. A workable sequence looks like this:

• Load the most recent checkpoint with status verified, and ignore everything written after it.
• Compare the stored input fingerprint with the current source. If the source changed, stop and route the decision to a person rather than continuing silently.
• Check every write intent recorded after that checkpoint against the external system before retrying it.
• Confirm that the instruction and tool versions match the checkpoint, or record the change explicitly.
• Continue with the step named in the next-action field, and write a new checkpoint only after that step passes verification.
• If the same step fails on resume again and again, stop and escalate instead of retrying indefinitely.

The last point matters most. A resume that fails the same way each time is a loop, not a recovery. Stop conditions that actually work describe how to bound that behavior before it consumes a day of work.

How do you test that checkpoints really work?

A checkpoint that has never been interrupted is a hypothesis. Test it before the first long run depends on it, using a staging copy of the task and a small input that represents real cases:

• Run the task to completion without interruption and save the final outputs as the reference.
• Run it again and stop it deliberately after each checkpoint.
• Resume each interrupted run and compare the outputs and external side effects with the reference.
• Inject a timeout immediately after an external write and confirm the restart does not create a duplicate.
• Corrupt one checkpoint on purpose and confirm the agent refuses to resume from it.

Compare outcomes, not transcripts. Generated wording will differ between runs, so compare structured fields, record counts and external reference IDs. Traces and logs from each run show where a resume began, and the observability concepts described in the sources give a shared vocabulary for them. A test set built from real past cases makes the comparison meaningful, because it tests the steps that actually cause trouble.

How Be Human handles this, and where to start

Be Human designs and operates the agent infrastructure that makes checkpoints possible. In a first engagement, checkpoint positions, record fields, idempotency approach and approval boundaries are written into the role definition, so every restart follows rules the business has agreed to in advance. Managed operations then keep those rules working over time. That includes monitoring checkpoint writes and resume events, reviewing the permissions a long task holds, handling incidents when a run stops unexpectedly and adjusting checkpoint placement when tools or models change. The business decides which steps need human approval. Be Human makes sure the agent stops at those steps and leaves a record a person can read.

A practical starting point is to list the long tasks your team already runs by hand or with a fragile script. For each one, mark the steps that are expensive, touch an outside system or get checked by someone before work continues. Those marks form a first checkpoint map. Then choose one task with a clear success criterion and limited permissions, and run it in shadow mode before it writes anything. Running an AI agent in shadow mode explains how to build that evidence before giving the agent authority. Take the free Be Human AI diagnostic to find the first long task worth handing to an agent.

Frequently asked questions

How often should a long agent task write a checkpoint? Write checkpoints at the boundaries you defined, not on a fixed timer. A timer can capture a half-finished write, while a boundary checkpoint is written only after a step passes verification. A time-based heartbeat is worth adding only for a single step that can run unusually long.

Can the model's memory replace checkpoints? No. Model memory is not a reliable record of which external actions succeeded, and it can be lost when a session ends or a model changes. Checkpoints store verified state in systems you control, so a restart can check facts rather than reconstruct them from a conversation.

What happens if the source data changes between checkpoints? The agent should compare the stored input fingerprint before resuming. If the source has changed, the safe action is to stop and send the decision to a person, because continuing could mix results from two different versions of the same data.

Do checkpoints add significant overhead? They add some storage, a few extra writes and a verification step at each boundary. In most long tasks that overhead is small compared with repeating a day of work or cleaning up duplicate external records, and it is easier to judge once you measure the cost of a single restart in your own workflow.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.