A durable workflow for a multi-step AI chain

From LIVEDAB, a SaaS where a visitor at an event uploads a photo and gets back a branded AI image or video.

The problem

The pipeline is a chain of steps per campaign layer: background removal, face swap, image-to-video, then a video render. Several minutes end to end, with three or four external providers in the middle. Until mid-2026 that chain ran in the visitor’s browser. Close the tab, lose the job. On a phone at a trade fair, tabs get closed all the time.

What changed

The chain moved to a durable server workflow. The rules that make it hold up:

• The workflow body is deterministic. Every side effect, every provider call, lives in a memoized step that is retried on its own. If the face-swap provider times out, only that step runs again.
• Providers that answer asynchronously are polled with a durable sleep, so a wait of ten minutes costs no running process.
• Every step has a budget: ten minutes for the render, twelve and a half for each asynchronous transform. A step that blows its budget fails cleanly instead of hanging forever.
• The result is delivered by a token-based result page and by email. The visitor can leave and come back.

Two details that mattered

A durable step is not free. Each one is a full orchestration round-trip, so the planning step is skipped entirely when the kickoff already says there are no transforms to run. Cheap jobs stay cheap.

Timing is recorded per transform and per phase and stored on the generation record. When a provider gets slow, it shows up in the data the same day, not in a support ticket a week later.

What I would tell someone starting this

Decide early where the job lives. If it lives in the browser, every closed tab is a lost customer. If it lives on a server with retries and budgets, most failures become delays, and delays are survivable. See also every AI step falls back to its input.