Turning One Good Result Into a Workflow

The most common shape of AI use in professional life is a series of unconnected wins. Something works well on Tuesday. It's genuinely useful. On Friday the same kind of task comes round and the whole thing starts from nothing — a fresh request, a fresh iteration, a fresh discovery of what the model needed to know.

Nothing is retained, so nothing accumulates. Two years of that produces two years of one-off results and no more capability than the first month.

The gap between occasional wins and compounding ones is roughly twenty minutes of writing, done at the right moment.

Capture at the moment it works, not later

The right moment is immediately after a result you were pleased with, while you can still remember why it worked. An hour later you'll remember that it worked; a week later you'll remember only that it did.

What to write down is smaller than "the prompt":

• The brief that produced it, including the constraints you added along the way. Most of the value is in the third and fourth message, not the first.
• What you had to correct, because those corrections are the template's real content — they're the context the model was missing.
• What made it good, in two or three checkable properties. This becomes both the standard and the next brief.

Twenty minutes. It pays back on the second use.

Separate what changes from what doesn't

A template that only fits the exact case it came from will be used once. What makes one reusable is knowing which parts vary.

The audience varies. The source data varies. The deadline varies. What almost never varies: the structure you want, the standard for done, the things you always have to tell it, the format it should come back in.

Write the fixed parts as fixed and mark the variable ones plainly. Something as basic as square brackets around the bits you swap out is enough — this doesn't need tooling, and reaching for tooling here is usually procrastination.

Then add the steps around it

A template is a single good request. A workflow is the steps either side of it, and that's where the reliability comes from:

What has to be true before you start. The data assembled, the brief confirmed, the previous version to hand. Most workflow failures are missing inputs, not bad prompts.

Where the checkpoint goes. One place where a person looks, chosen deliberately — usually just before anything leaves your control. One good checkpoint beats three that get skipped.

What happens to the output. Where it goes, who sees it, what it feeds. Steps that end in "and then someone does something with it" quietly stop happening.

Three steps is a workflow. Most of what people actually need is three steps, and the elaborate versions tend to be abandoned by month two.

Test it on the boring case

The natural test is the interesting example. That's the wrong one — interesting cases get attention regardless.

Run it on something routine, ideally something slightly annoying: the awkward client, the month where the data arrived late, the version with a missing field. Routine cases are where a workflow either holds or reveals that it only ever worked because you were paying attention.

Know when to stop

Not everything should become a workflow. Three signals that it shouldn't:

• You've done it twice in a year. Setup won't pay back.
• The judgement is the task. Automating the shell around a decision saves nothing and adds a maintenance burden.
• The inputs change every time. Then it isn't a repeated task, it's a category of task, and templating it produces something too vague to help.

Most people have five or six genuinely repeated tasks. That's the list, and it's shorter than the enthusiasm suggests.

Rosa — the twenty minutes

Rosa is a bid manager at an engineering firm. She'd been writing tender responses with AI for a year, well, and from scratch every time.

After one that went unusually smoothly she spent twenty minutes writing down the brief, the four corrections she'd made along the way, and the three things that made it good.

The next response took under half the time — not because the template did the work, but because the four corrections were exactly what she'd otherwise have rediscovered. She now has six templates and describes the collection as the actual asset, more than any individual output.

Tunde — the boring case that broke it

Tunde runs finance operations at a distributor. His monthly reporting workflow worked beautifully on the example he'd built it from.

It broke the first time a subsidiary submitted late, which happens most months. The workflow assumed complete data and had nothing to say about partial data, so the output was confidently based on an incomplete set.

He rebuilt it around the awkward month instead of the clean one, adding a single explicit step: check what's missing, and either stop or state the omission on the output. His view is that testing on the clean case had told him nothing he didn't already know.

The one thing

Wins that aren't written down don't compound. Capture immediately after something works, separate what varies from what doesn't, and add the three steps around it — inputs, one checkpoint, destination.

Then test it on the boring case, because the interesting one was never the problem.