AI Guides › Skills & Agents
The Difference Between A Workflow And A Skill, When You Actually Need Both
By Nigel Guy · 3 min read
The words get used loosely enough that people build one when they meant the other, or try to cram an entire multi-stage process into a single skill because nobody drew the line between "one reusable procedure" and "an ordered sequence of several." The result is either a skill that's really an unwieldy workflow in disguise, or a workflow that never gets written down because each of its parts already felt like "a skill," so surely that was enough.
The rule: a skill is one reusable procedure with a single point; a workflow is the ordered sequence that decides which skills run, in what order, and what happens between them — most real processes need both, and conflating them is what makes either one hard to maintain.
The mechanism
- Ask whether you're describing a thing or a sequence. "Summarise a document into three bullet points" is a thing — one skill, one point, reusable wherever a document needs summarising. "Take in a new client, summarise their intake form, draft a welcome email, and flag it for review" is a sequence of several distinct things, in order — that's a workflow.
- Keep each skill inside the workflow single-purpose. The summarising step and the email-drafting step are different skills, each with its own one-sentence rule, even though they're both part of the same workflow. Mixing them into one document is how you end up with a skill that has two unrelated points and neither stated clearly.
- Let the workflow own the ordering and the handoffs, not the individual skills. Each skill should be usable on its own, without knowing it's part of a bigger sequence. The workflow document is where you write "step two only runs if step one didn't flag an issue" — that logic doesn't belong buried inside either skill.
- Put review checkpoints at the workflow level, not just inside each skill. A workflow's real risk is usually at the seams — the moment where one skill's output becomes the next skill's input, unreviewed. Decide explicitly where a human looks at the output before it moves on, rather than assuming each skill's own care is enough.
- Build the skills first, prove each one, then assemble the workflow. Trying to build and test the whole sequence at once makes it hard to tell which link actually failed when something goes wrong. A workflow assembled from already-trusted skills is much easier to debug than one built and tested as a single unit.
What to skip
Skip writing a single skill that secretly does three or four different jobs in sequence — split it, and write the sequencing separately as the workflow it actually is. And skip building elaborate workflow tooling around something that's genuinely just one skill used repeatedly; not every repeated task needs orchestration on top of it.
Guardrails
- The seams between skills in a workflow are where errors compound — a small mistake in an early step can move a genuinely bad output through several downstream steps before anyone checks it, if the checkpoints aren't placed deliberately.
- A workflow inherits the maintenance tax of every skill inside it, plus its own sequencing logic — that's a larger, not smaller, ongoing cost than any one skill alone, and worth weighing before assembling several skills into one.
- This distinction is about clarity of design, not a rule that every process must be split this way regardless of size — a genuinely tiny two-step sequence may not need the full ceremony of a separate workflow document.
All 751 AI guides · JulieMango plans from £17/mo