# A workflow that cannot resume is still a demo.

What long-running AI and media jobs taught me about state, artefacts, failure, and the real meaning of progress.

- **Canonical URL:** https://vidhata.me/notes/a-workflow-that-cannot-resume-is-still-a-demo
- **Author:** Vidhatanand V. (Vid)
- **Role:** Fractional CTO and AI Systems Architect

**Published:** 01 Sep 2026 | **Reading time:** 10 minute read

## Why I hold this position

A short demo can keep its entire world in process memory. The user clicks a button, the model responds, and the result appears before anything important has time to fail. A real workflow has a longer memory. It crosses tools, machines, providers, approvals, and hours of work. That is where a convincing demo often reveals that it was never an operating system.

I learned to treat progress as data. If a six-hour job fails after five hours, the useful question is not whether the process can be restarted. It is whether the system can prove what completed, preserve the artefacts, understand what is safe to repeat, and continue without corrupting the result.

## A process is not the same thing as a workflow.

A process is alive while the machine, container, or function is alive. A workflow must survive the death of any one of those things. Its state belongs in durable storage. Its stages have identities. Inputs and outputs are addressable. A person can see what happened without reading a wall of logs.

This matters quickly in AI systems. One stage may collect evidence, another may call a model, another may render media, and another may wait for approval. Costs accumulate before the final output exists. Some steps are deterministic, some are probabilistic, and some depend on external systems that will eventually time out. Treating the whole chain as one request makes every interruption expensive and obscure.

## I design the recovery path with the happy path.

For each stage I want to know its input contract, idempotency boundary, checkpoint, output artefact, retry policy, and cancellation behaviour. A retry should be a deliberate decision, not the default response to every error. Some failures are transient. Some inputs are invalid. Some providers have charged for work that produced no usable result. The workflow needs to distinguish those states.

Cancellation deserves the same care. A user who stops a job is expressing product intent. The system should stop work that has not begun, signal work already running, preserve completed artefacts, and record the final state. A cancel button that only changes the interface while workers continue spending money is not control.

## Artefacts make progress inspectable.

I prefer first-class artefacts to anonymous blobs passed between steps. An artefact has a type, source, owner, timestamp, relationship to the run, and enough provenance to explain how it was produced. It can be reviewed, reused, invalidated, or replaced without rerunning the entire pipeline.

This becomes especially important in computational media. A script, voice track, shot plan, image, timeline, render, and quality report should remain connected. If the final video fails review, the team should be able to return to the wrong decision rather than generate everything again. The same principle applies to research, data products, and agent workflows. An output that cannot be located and understood later is barely an output.

## Operational UX is part of the workflow engine.

Queues and checkpoints are not enough if only the person who wrote the backend can understand them. Operators need a product surface for runs, stages, approvals, costs, failures, artefacts, and recovery actions. The interface should answer what is happening, what already happened, what needs attention, and what action is safe now.

The takeaway I carry into every long-running system is that resumability is not an infrastructure feature added before launch. It is a product promise. When state, artefacts, and recovery are designed early, failure becomes an ordinary event the system can explain. Without them, even an impressive workflow remains a demo waiting for the first expensive interruption.

## What I take into the next build

- Persist stage state outside the process that performs the work.
- Define idempotency, retry, and cancellation per stage.
- Make every valuable intermediate output a first-class artefact.
- Give operators a readable account of progress and recovery choices.

## Continue reading

[All Fractional CTO field notes](https://vidhata.me/notes)

## Work with Vid

Start with the actual technical pressure: [bring the problem](https://vidhata.me/hire).