Imagine your child has a stack of English handouts from school — PDFs, all text, no pictures — and every week they need to translate each one into Chinese so a grandparent can read along. The task is exactly the same every time: open the file, pull the words out, translate them, save the result. Week after week. Identical errand.

Now think about what you have been learning in this series. You know there is a brilliant Librarian sitting behind a mail slot who has read every book ever written and can answer almost any question you write on a note. You also know there is a Runner — an agent — who does the legwork the Librarian cannot: fetching files, saving things, clicking buttons.

So here is the obvious question: if this errand is always the same, do you really want to invent it fresh every single time?

The Errand, Step by Step

Let us walk through the PDF-to-Chinese job properly, because doing so reveals something important.

Step 1: Open the PDF and pull out all the text. Step 2: Translate that text from English into Chinese. Step 3: Save the Chinese text as a new file.

Read those three steps again. Only one of them requires any real intelligence. Step 1 — pulling text from a PDF — is a mechanical task a computer has been able to do since the 1990s. Step 3 — saving a file — is even simpler. Neither of those two steps needs a genius. Neither of them needs the Librarian at all.

Only Step 2, the translation, actually benefits from slipping a note through the mail slot. That is the one place where the Librarian's vast reading pays off.

Why Letting the Runner Improvise Every Time Is a Bad Idea

In article 7 — where you meet AI — we saw that the Runner can handle the whole errand by improvising: figure out what to do next, ask the Librarian for help when needed, use the right tools along the way. For one-off, unpredictable jobs, that flexibility is exactly what you want.

But for a job that is identical every single week? Improvising is wasteful. The Runner has to think through the steps each time. The Librarian gets bothered for things it does not need to be bothered for. Small mistakes can creep in — maybe one week the Runner saves the file in the wrong folder, or names it differently. It is a bit like hiring a brilliant chef to butter your toast every morning. They can do it perfectly, but it is not a good use of anyone's time.

There is a better way.

Fix the Recipe

If the errand is always the same, write it down once and follow the written version every time.

Step 1: Run the PDF-text-extractor program. (Hardcoded. No thinking needed.) Step 2: Take the extracted text and slip it through the mail slot with the note: "Translate the following from English to Chinese." Wait for the note to come back. (This is the one step that needs the Librarian.) Step 3: Save the returned Chinese text to a file called translation-[date].txt. (Hardcoded. No thinking needed.)

That fixed sequence of steps — written down, locked in, run the same way every time — is what techies call a workflow. The Runner follows the recipe exactly. The Librarian is only consulted at the one step where a genius is genuinely needed.

Everything else is just plumbing.

Two Ways to Build One

You can write a workflow in two main ways, and neither is better in all situations.

The first way is code. A programmer writes the recipe in a programming language, spelling out every step precisely. One popular toolkit for this is LangChain — a library of ready-made pieces (for calling an AI model, for reading files, for chaining steps together) that a developer can snap together quickly. If you have heard someone mention LangChain and wondered what on earth it was, now you know: a toolkit for writing AI workflows in code.

The second way is low-code or drag-and-drop. Some tools let a non-programmer build a workflow by dragging boxes on a screen and drawing arrows between them. "When a new PDF arrives in this folder" connects to "extract the text" connects to "send to AI for translation" connects to "save the result here." No programming required. These tools go by names like Zapier, Make, or n8n.

Both approaches produce the same thing: a fixed recipe that runs reliably every time you press go.

The Great Strength — and the One Big Weakness

Workflows are wonderful precisely because they are predictable. Run the recipe on Monday and you get a consistent result. Run it again on Friday and you get the same process, step for step. There is no improvisation, no drift, no forgetting to save the file. For repetitive tasks, that reliability is golden.

But here is the catch, and it matters enough to say plainly: a workflow is rigid. It can only handle exactly what you planned for when you built it.

What if one week the PDF arrives as a scanned image instead of real text? The text-extractor step breaks immediately, and the whole recipe grinds to a halt.

What if the translation needs a note at the top explaining who wrote the original document? There is no step for that, so it does not happen.

What if sometimes the file is an email instead of a PDF? The workflow does not know what to do. It simply falls over.

A workflow is like a very reliable but very narrow-minded assistant. Tell them exactly what to expect, and they will execute flawlessly for years. Show them something unexpected, and they freeze.

This is not a flaw, exactly — it is the trade-off you accept. You get consistency in exchange for flexibility. For tasks where the input is always tidy and identical, that is an excellent deal. For tasks where the input keeps changing, you need something more adaptable.

Where This Fits in the Bigger Picture

Think back to the series so far. We have a Librarian who can finish your notes brilliantly but cannot leave the room. We hired a Runner to do all the legwork. In article 6 we saw how the Runner and the tool-shops shake hands via MCP. In article 7 we saw the Runner improvise freely when given an open-ended task.

Now we have seen something in between: the Runner following a script. Not improvising — just executing a fixed plan, consulting the Librarian only at the one intelligent step.

That is the workflow. At one end of a ladder: every step hardcoded in code, no AI at all. At the other end: a free Runner improvising everything. The workflow sits in the middle — mostly hardcoded, with one carefully chosen slot where the Librarian's brilliance is let in.

A ladder is forming: hardcode everything, then workflow, then something more flexible still.

What Comes Next

Which brings us to the obvious follow-up question. What do you do when the inputs keep changing? What if some PDFs are in French, some are in Spanish, and the grandparent sometimes wants a summary instead of a full translation? What if the task is similar but never quite identical?

A workflow, being rigid, cannot cope with that on its own. But there is a technique for giving the Runner a set of standing instructions and ready-made scripts it can reach for on demand — something more flexible than a fixed recipe, but still far more organised than pure improvisation.

We call that a skill. And that is exactly what article 9 is about.

This article is part of the AI in Plain English series — ten short pieces that give any curious parent or student a solid map of the AI landscape, one idea at a time.