Turning a workflow into a system that runs on its own

A workflow is something a person runs. A system is a workflow that runs itself. Something happens, such as a file landing in a folder, a form being sent or a clock reaching six in the morning, and the work starts with nobody pressing a button. When it goes wrong, the system tells somebody. The difference between the two has almost nothing to do with the creative work, and sits instead in the parts around it, which are the trigger, storage, error handling, logging, spending limits and a way to tell when something is broken. This lesson walks through those parts in the order you meet them, so that you can decide whether your studio needs one.

Picture a homeware shop that adds about thirty products a month. Each time the team uploads a new product photograph on white to its catalogue, it wants four lifestyle images for the product page and two vertical ones for stories. As a workflow, a designer does that by hand every Friday. As a system, the upload itself is the trigger. The system checks the file, sends it with the approved prompt template to an image model, waits for the results, runs automatic checks on them, saves the survivors with a record of how each was made, and messages a person to approve them. Friday becomes ten minutes of choosing.

Two ideas hold the whole thing together. The first is the contract, the written agreement about what goes in and what comes out. For the homeware shop it might say a JPEG at least 2,000 pixels on its long side, on a white background, with a product name attached, and six images back at stated sizes. Anything that breaks the contract is turned away with a clear reason instead of being half-processed. The second idea is the API, the door a program uses to ask a model for work. A system never types into a chat app. It sends a request that names an exact model version, and that model's documentation tells you what it will accept, how often you may call it and how it bills.

Generation is slow by the standards of the web. An image takes seconds and a video can take minutes, and many web servers give up on a request long before that. So a system does not keep the person waiting on an open connection. It accepts the job, puts it in a queue, answers at once, and lets a separate worker pick the job up and store the result when it is done. IBM's explanation of message queues gives the reason, which is that messages wait safely until the receiving program is ready, so nothing is lost when a network or a worker fails. Failures still happen. Google's guidance for its own cloud storage is to retry only temporary errors, such as a timeout or a rate limit, with waits that grow longer each time, and to retry only steps that are safe to run twice.

A system also has to judge its own output, because nobody is watching when it runs at six in the morning. Automatic quality checks, later in this module, builds that gate from cheap measurements and narrow questions to a vision model. Whatever passes is stored with its record. That record names the model, the prompt, the references and the person who approved it, and Content Credentials, a standard hosted by the Coalition for Content Provenance and Authenticity, can attach part of that history to the file itself.

Most studios should stop at a good workflow. Crossing into a system is a decision to take on software upkeep, and it pays only when the same job runs often enough that the upkeep costs less than the labour it saves. The arithmetic fits on paper. A job that runs twenty times a month at forty-five minutes each is fifteen hours of work. If the system needs four hours a month of watching, fixing and checking bills, it saves eleven, which makes it worth building. If the job runs twice a month, a well-documented workflow that a person starts is the better tool, and it costs nothing to keep.