When an AI Workflow Stops: Check Before You Retry

Imagine an AI workflow stops while preparing a client update. A teammate finds an error message and a document that might already be finished. They ask you whether to run it again.

Now the work depends on you twice: first to reconstruct what happened, then to decide what is safe to repeat.

A useful recovery process gives the next person enough evidence to make that decision within clear limits. Start by checking the actual state of the work. Then continue only the part that still needs doing.

Keep an unknown result separate from a failed step

An error can describe what the caller experienced without establishing what happened at the destination.

AWS illustrates this in its guidance on idempotent APIs: a request receives no response, leaving the caller uncertain whether the operation completed. Repeating it could create a duplicate. The caller may need to reconcile the result, meaning determine what actually happened. Read AWS on retries and uncertain outcomes.

For a business workflow, use three practical labels:

• Confirmed: The evidence identifies the intended result and lets someone inspect it
• Failed: Reliable evidence establishes that the step did not achieve its intended result; record any partial effects separately
• Unknown: The evidence is missing, conflicting or cannot connect a result to this attempt

These labels are a proposed working convention. An error message alone does not necessarily tell you which label applies.

If the result is unknown, keep it unknown while you investigate. A search that returns no document may reflect a delay, a filter or missing access. It does not automatically prove that no document exists.

Reconstruct the smallest useful history

Ask the authorized workflow owner to prevent competing attempts while recovery is underway. Check whether the original attempt is still running or has automatic retries pending. Starting another copy can make the history harder to understand.

Keep the original work-item identifier, the attempt identifier where available, and the time of the interruption. Then inspect the relevant system through read-only checks:

1. What was the last confirmed step?
2. What did the next step attempt to do?
3. Is there an output or activity record tied to that attempt?
4. Does the output contain the expected version and required content?
5. What remains unfinished or uncertain?

A filename by itself is weak evidence. It might belong to a previous attempt. Look for identifiers, version history and the actual contents together.

Preserve any existing draft while investigating. Do not overwrite reviewed work or delete apparent duplicates just to make the queue look clean. Record the discrepancy and let the authorized owner resolve it.

Walk through a fictional draft-only recovery

Consider a small consultancy preparing an internal client-update draft. The workflow can read an approved project summary, compose a draft and save it in a review workspace. It cannot send messages, change project dates or make commitments to the client.

This example is illustrative. It describes no customer, deployed system or measured result.

The saved history shows:

• The approved project summary was retrieved
• Draft text was produced
• The save request returned a timeout
• The review handoff has no completion record

The save step is initially unknown. The coordinator checks the workspace and finds a document whose version record matches the attempt. They open it and verify the expected project summary, unresolved questions and draft status.

Now they can record that the draft was saved. Generating it again would add no value. The remaining job is to make the verified draft available for internal review, using the workflow's approved handoff process.

If the coordinator cannot connect the document to this attempt, the save remains unknown. The next step is an investigation by the workflow owner. It is not an automatic restart.

Write the retry rule before the next interruption

Google Cloud's retry guidance distinguishes temporary failures from persistent problems and evaluates retry safety alongside an operation's idempotency. Some operations are safe to repeat only under documented conditions. Read Google Cloud's retry strategy.

Ask the implementer to document the rule for your particular workflow:

• Which failures permit another attempt?
• Which exact step can be retried, and under what conditions?
• How are completed steps and existing outputs protected?
• What limits and waiting intervals apply?
• Could built-in retries and the workflow's own retries multiply each other?
• When does the attempt stop and reach a named person?

The same Google Cloud guidance warns against retrying persistent errors and layering retries without understanding the total number of attempts. Its specific settings apply to Cloud Storage; use your own tool's documented behavior.

An idempotent operation can be repeated without adding the same side effect again under its documented contract. That property does not make an action authorized, free or harmless. Repeating the same prompt is not proof of idempotency, and generating another draft may produce different text.

Missing permission, unresolved approval and an invalid request need the underlying issue addressed. Repetition does not supply authority or fix missing information.

If a tool can only restart the whole workflow, have the implementer establish the safety of every repeated step before allowing a restart. If that cannot be demonstrated, keep the work paused and route the exception.

Copy this recovery note

Use the note below for one interrupted work item. Keep only the information needed for recovery, with links to approved systems rather than copied sensitive records.

Work item and intended result:

Attempt identifier, workflow version and interruption time:

Current state: confirmed, failed or unknown for each relevant step:

Evidence checked, existing output and any partial effects:

Remaining work and permitted next action:

Recovery owner and decision needed:

Next checkpoint and consequence of waiting:

Final result, verification and anything still open:

The checkpoint should reflect a real dependency or deadline. If review must happen before a client meeting, make that visible. If no urgent commitment is affected, the owner can use the normal exception-review rhythm.

Make recovery part of the handoff

The FlowOS operating-layer approach brings context, workflows, exceptions and outcomes together. A recovery note applies that idea to one stalled job: carry the evidence with the work and route the unresolved decision to the right person.

The founder does not need to become the default historian for every interruption. A coordinator can inspect a draft; an implementer can investigate a save failure; the person who owns the commitment can decide whether a delay needs action.

Close the recovery only after someone checks the intended result. Record which attempt produced it, which action resumed the work and what remains unresolved. A restarted run is still work in progress.

Choose one recent interruption and write its recovery note. If another authorized person can use it to determine the next safe step, you have made one recurring dependency easier to hand over.

That is attention you can direct deliberately, instead of spending it reconstructing the same uncertainty again.