Last time, in What is an AI Workflow?, we watched the Runner follow a fixed recipe. Every morning: collect the sales figures, pass them to the Librarian for a summary, send the summary by email. Same steps, same order, every single time. It worked beautifully — until the day the figures arrived as a PDF instead of a spreadsheet. The recipe said "open the spreadsheet." There was no spreadsheet. The recipe broke.
This is the crack in every rigid workflow: the moment the inputs change, the instructions no longer fit.
This is article nine in the AI in Plain English series. If you are just arriving, we have one image running through the whole series: a genius Librarian who sits behind a wall with a mail slot. They have read every book ever written. They can finish any note you slip through the slot. But they cannot open files, check the internet, or press buttons — so you hire a Runner to do all of that mechanical legwork on your behalf.
The problem with a single recipe
Imagine the Runner's desk after six months of use. One folder holds the morning sales recipe. Another holds the customer-query recipe. A third holds the weekly report recipe. Each recipe is a neat list of steps: open this type of file, pass it through the slot, format the reply, send it here.
Now the business starts receiving files in three formats: PDF, Word, and plain text. And sometimes the output needs to be a document, sometimes a webpage, and sometimes an image for the company newsletter.
Three input types times three output types gives nine possible combinations. Writing nine separate recipes is miserable and fragile. Change the email address and you have to update nine files. Hire a new tool and you update nine files. Someone's handwriting (meaning: someone's code) varies across nine files, and bugs creep in.
There has to be a tidier answer.
Enter the instruction sheet
Here is what a sensible person does instead. They take all the little ready-to-run scripts — one for PDF, one for Word, one for plain text, one for document output, one for webpage output, one for image output — and drop them all into a single folder. Then they write one plain-English instruction sheet on top:
"Goal: convert an incoming file into the requested output format. Look at the file type first. If it is PDF, use the PDF script. If it is Word, use the Word script. If it is plain text, use the text script. Then look at the requested output. Use the matching output script. Carry on."
They hand the Runner this folder and say: "Whenever a conversion job comes in, read the instruction sheet first, then carry on."
That folder — the instruction sheet plus the ready scripts — is what the industry calls a skill. At its heart, it is just a saved set of instructions the Runner loads only when it is relevant. The Runner does not carry it everywhere. When a conversion job arrives, the Runner picks up the folder, reads the sheet, picks the right script, and gets to work. When the job is done, the folder goes back on the shelf.
The ladder from rigid to flexible
It helps to see the whole progression laid out clearly, because "skill" sits in the middle of a spectrum that runs from completely locked-down to completely free.
Hardcoded tools — libraries like LangChain — are the most rigid end. A developer writes every step in code ahead of time. Changing even one detail means opening the code and rewriting it. These are powerful and precise, but they bend only if a developer bends them.
Drag-and-drop workflows — visual tools where non-programmers connect boxes on a screen — are a step more accessible. You can redesign the recipe without writing code. But the recipe is still fixed: every job follows the same path.
Skills are the next step up. The instruction sheet tells the Runner how to choose its own path depending on what it finds. The Runner reads the inputs, consults the sheet, picks the right script, and adapts without a developer touching anything. New file type arrives? Add a script to the folder and update one line of the instruction sheet. Done.
A fully free agent sits at the flexible end. It has no fixed recipe and no instruction sheet — it reasons from scratch every time, deciding its own steps based on the goal alone. Tremendously capable. Also unpredictable, occasionally spectacular in its failures, and uncomfortable if you need a process to be auditable or repeatable.
The skill is the everyday sweet spot. Flexible enough to cope with surprises. Controlled enough to stay predictable. You can read the instruction sheet and know exactly what the Runner will do — the logic is written down in plain language, not buried in code or in the Librarian's unknowable chain of reasoning.
What about a really messy sub-errand?
Sometimes the Runner is handling a big job, and one piece of it is genuinely complicated. Say the main task is "prepare the monthly client report" — but buried inside that is "audit every invoice from the past thirty days and flag any anomalies." That audit is its own mini-investigation: open file after file, compare values, apply several rules, write a summary. If the Runner tries to do all of that while also running the main report, the main desk gets cluttered. Notes pile up. Things get confused.
The clean solution: the Runner sends a subagent to handle the audit separately. A subagent is simply a junior runner dispatched on a sub-errand. It goes away, does its messy investigation, and comes back with only the result: "Three invoices flagged: dates X, Y, Z." The main Runner drops that result into the report and carries on. The main desk stays tidy.
A subagent is not a different species of AI. It is the same kind of Runner, running the same kind of loop — slip a note through the slot, use tools, collect results — but on a contained, separate task. When you hear "multi-agent system," that is usually what is happening: one main Runner dividing a complicated job into pieces and handing each piece to a junior runner so nothing gets tangled.
Skill versus MCP — are they rivals?
You may have come across MCP (Model Context Protocol) in the previous article on function calling and MCP. MCP is the standard handshake the Runner uses to talk to outside tool-shops — calendars, databases, search engines. It answers the question: "What tools does this shop offer, and how do I ask for them?"
A skill answers a different question entirely: "Given this job, how should I approach it and which tools should I reach for?"
They sit on different floors of the same building. A skill is an instructions-loader. It can point to MCP tools as part of its instructions: "to do step three, call the search tool via MCP." They are not rivals; they are neighbours. Confusing them is like confusing a recipe with a shopping list. The recipe describes what to cook and in what order. The shopping list tells you where the ingredients live. You need both.
The picture to hold onto
Think of the Runner's desk one more time, but now with a tidy bookshelf behind it. On the shelf are labelled folders — "conversion jobs," "invoice audits," "weekly summaries," and so on. Each folder holds an instruction sheet and a set of ready scripts.
When a job arrives, the Runner pulls the right folder, reads the sheet, picks the matching script, and gets to work. If the job involves a messy sub-investigation, the Runner calls over a junior runner, hands them a folder of their own, and sends them off.
The Librarian behind the wall never changed. The genius stays exactly where it was. What changed is the organisation on the Runner's side: instead of one rigid recipe, there is a whole shelf of smart instruction sheets, each one flexible enough to handle the unexpected.
That shelf — those skills — is what turns a useful-but-brittle tool into a genuinely reliable assistant.
What comes next
The next and final article in this series — Decode Any AI Buzzword — hands you the one universal trick for making sense of any new AI term you encounter, and takes a quick look at what is coming next in the world of AI assistants.
This is article 9 of 10 in the AI in Plain English series. Start from the beginning at aitutors.me or read the previous piece: What is an AI Workflow?.