From Prompt to Workflow: Chaining the Steps

A single prompt does one step. Real work is many steps: read the incoming request, pull the relevant data, draft a response, check it against policy, format it, log it. The leap in leverage comes from chaining — using AI across a sequence rather than for one isolated answer.

Start by decomposing the job on paper, before you open any tool. Write the steps a competent colleague would take, in order. Then mark each one: which need judgement (AI-assisted), which are purely mechanical (automatable outright), and which need a human signature. That map is the workflow. It's also what makes the result maintainable — you can fix or improve any single step without rebuilding everything around it.

Be honest in that marking, because the classic failure is handing AI a step that isn't actually a language problem. Moving a file, checking whether a number is above a threshold, looking up a record by ID — these are jobs for ordinary automation, which is faster, free, and deterministic. Use the model for the parts that genuinely need judgement: understanding, drafting, classifying, summarising, deciding between options.

Then wire it up. For light chains you can work inside one chat, feeding each step's output into the next. For anything recurring, move it to an automation platform — Zapier, Make or n8n — where a trigger (a new email, a form submission, a row added) starts the chain and the model handles the judgement steps in the middle. You don't need to code. You need to think in triggers, steps and hand-offs.

The discipline that separates a robust workflow from a fragile one is the hand-off: being explicit about what each step receives and what it must produce for the next step to work. Vague hand-offs are where chains break. Define the shape of every intermediate output — a clean summary, a filled table, a single yes/no flag, a JSON object with three named fields — and the whole thing holds together. If a step's output is prose that the next step has to interpret, you've built something that will fail in ways you can't predict.

Now the arithmetic that catches people out. Chains multiply error. A step that's right 95% of the time sounds excellent; six of them in a row is about 74%, which means one run in four goes wrong somewhere. This is why short chains beat long ones, why you should make the model's job at each step as narrow as possible, and why a wrong answer early is worse than a wrong answer late — everything downstream inherits it.

So design for failure explicitly. Validate at the hand-offs: if step three is supposed to emit a table with four columns, check that it did before step four consumes it. Give the model an escape hatch — "if the email doesn't contain an order number, output NEEDS_HUMAN and stop" — because a model with no way to say "I can't" will invent something plausible instead. And route anything uncertain to a person rather than letting it flow through.

Keep a human on anything consequential. Reading, classifying, drafting and summarising can run unattended. Sending, paying, publishing, deleting and anything customer-facing should stop for approval, at least until you've watched it behave for a few weeks. The best pattern is usually to have the workflow prepare the action completely and leave it one click away.

Finally, log what runs. Keep the input, the intermediate outputs and the final result for anything that matters. When a workflow does something strange in a month's time — and it will — the log is the difference between finding the broken step in ten minutes and rebuilding the whole thing on a guess.