When an AI Workflow Fails, What Is Safe to Retry?
An AI workflow prepares the copy, generates images and starts a video render. The final request times out. Clicking “start again” feels reasonable, but some of the paid work may already be complete. The timeout describes what the caller received. It does not tell you everything the other services did.
Before you approve an automation project, ask for a demonstration of this moment. You should be able to see what finished, what failed and what the next attempt will repeat.
A lesson from our own media workflow
In September 2026, we revised the recovery path behind our Jido media drafts. Source preparation, image work, narration, provider status reads and rendering have separate steps. Selected transient failures receive two further attempts, after 5 and 15 seconds. Completed media and provider references remain available to the same draft.
The crucial boundary is the paid submission. An uncertain submission stops for investigation; the system does not automatically send another paid creation request. The scheduler also no longer restarts the whole generation request after a partial failure. Those are implementation choices in our own system, not evidence that every provider offers the same protection.
In a controlled production check, we introduced a failure before rendering, then recovered the same draft through its retry action. It produced one draft record and an 18.5-second video with no paid media generation. That verifies this recovery path. It does not establish a fleet-wide success rate or prove that unknown provider submissions are always recoverable.
Give each outcome a different next action
Finished: keep the saved output and verify that it belongs to the current input.
Temporary failure during a safe operation: retry that step within a time and attempt limit.
Rejected input, review failure or exhausted budget: stop and explain what must change.
Unknown external outcome: check the provider's existing operation before deciding whether another creation request is safe.
A short error message should identify the failed step and preserve access to finished work. “Try again” needs a defined scope. The operator should not have to guess whether it means checking status, rendering existing files or buying another set of generated assets.
A request reference is useful only if you reuse it
Some APIs support an idempotency key, a reference that lets a retry identify the same logical operation. Stripe, for example, documents that repeating a request with the same key returns its stored result, including failures. Its retention and parameter rules matter. Read the provider's contract before assuming a retry is protected.
An internal job ID alone does not give an external API that behavior. Keep the external operation reference, the input version, the saved result and the current state together. If the customer changes the input, make that a deliberate revision so old assets cannot silently stand in for new work.
Ask the supplier to demonstrate four failures
Use synthetic inputs and stubbed external writes where a real action would cost money or contact someone. Agree on the expected result before the demonstration:
The browser loses its response: reopening the job shows the existing attempt rather than creating another one.
A later step fails: recovery keeps earlier verified outputs and repeats only the necessary work.
The provider may have accepted a request: the job exposes that uncertainty and checks the existing operation, or pauses for a person.
The problem cannot be retried away: invalid input, a rejected output or the spending limit ends the attempt with a useful explanation.
For each demonstration, inspect both the user-facing result and the downstream records. Count created jobs and external writes. A green status badge alone does not prove that a duplicate draft, charge or message was avoided.
Put recovery in the acceptance criteria
Your brief can be short: “After a partial failure, show completed work, preserve the attempt's identity, explain any uncertain external action and provide a bounded recovery path. Demonstrate that path with the agreed failure cases.”
Name the person responsible for unresolved jobs and decide how they will notice one. Keep the human review step attached to the actual proposed output. If recovery changes that output, the earlier approval may no longer describe what would be delivered.
To discuss a workflow with us, bring one recurring task, its current failure point and the result someone needs to receive. Describe the workflow. We can use those details to scope an assessment; they are more useful than a list of models to install.