A bigger context window is not a recovery plan.
It may let an agent hold more information at once. It does not guarantee that the right information survives a crash, a handoff, a system change or a long-running job.
That distinction matters when an agent moves from an impressive prototype into a real business process. A prototype only needs to complete the demonstration. A production workflow needs to preserve intent, evidence and authority when something goes wrong.
The answer is an agent context checkpoint.
A checkpoint is a versioned record of the job at a specific moment. It tells the recovering agent what it is trying to achieve, what has already happened, what evidence supports the work, which decisions have been made, what permissions still apply and what action is allowed next.
It turns context from a large prompt into recoverable operational state.
The seven fields a useful checkpoint needs
### 1. Objective
Record the outcome the workflow is responsible for, not just the latest instruction. The objective should be specific enough that a different agent or process can recognise whether the resumed work is still heading towards the same result.
### 2. Completed steps
List what has actually been completed and verified. Do not treat generated text, attempted API calls or planned actions as completed work. Recovery depends on knowing the difference.
### 3. Evidence and provenance
Preserve the sources, system records and artefacts behind the current state. A plausible summary is not enough. The recovering workflow needs to know where each important fact came from and whether it can still be trusted.
### 4. Decisions and exceptions
Record the decisions already made, the reasoning that matters and any unresolved exception. Without this, an agent can repeat old debates, reverse a deliberate choice or quietly route around a problem.
### 5. Permissions
State what the workflow is allowed to read, change, send, spend or publish. Authority should never be inferred from the existence of a checkpoint. Sensitive permissions need to be checked again when the job resumes.
### 6. Next allowed action
Define the smallest safe next step. This prevents a recovering agent from improvising its way from a stale summary into a material action.
### 7. Expiry and verification rule
Every checkpoint needs a condition that makes it stale and a test that proves it is safe to resume. Prices change. Records change. People withdraw approval. Systems move. Recovery has to begin with verification, not confidence.
Resume is a test, not a button
Most recovery designs stop at persistence. They prove that the workflow can load an old state and continue producing output.
That is not enough.
A safe resume test asks:
- Does the objective still apply?
- Do the referenced systems and records still match the checkpoint?
- Are the evidence and decisions still current?
- Does the workflow still have the authority recorded at the time?
- Is the next action still safe and relevant?
If one of those checks fails, the workflow should pause, refresh its state or escalate. Continuing fluently is not the same as continuing correctly.
What a context checkpoint prevents
It reduces repeated work because completed steps are explicit. It limits context drift because decisions and evidence have provenance. It makes handoffs safer because the next operator inherits a structured state rather than a conversational summary. It also protects authority because permissions are treated as expiring operational facts, not permanent assumptions.
The checkpoint does not make an agent infallible. It makes failure visible, diagnosable and recoverable.
That is the real threshold between a demo and an operating system.
Test one workflow before scaling autonomy
Choose a workflow that takes long enough to be interrupted and matters enough that a bad resume would hurt. Stop it halfway through. Change one relevant system value or permission. Then attempt recovery.
The test is successful only if the workflow recognises the stale state, preserves the verified work and refuses the wrong next action.
Foundry Works reviews the context, checkpoint and recovery design behind production agent workflows. We test whether the work can survive interruption without losing intent, evidence or authority.
Book an agent context and recovery review.
Need to know whether an agent workflow can recover safely after interruption?
Book a strategy call →