Building workflows · Lesson 5 of 8
Multi-step workflows
Design repeatable workflows that combine AI steps, code and human checkpoints — with clear hand-offs, validation and failure handling.
You're learning as a guest — everything is open. Sign in to save progress, earn XP and pick up where you left off.
From one prompt to a process
Decomposition gives you a list of sub-tasks. A multi-step workflow is how you run them reliably, again and again: which step happens when, what passes between steps, where checks happen, and who (or what) does each part.
A workflow can live in a chat ("first do A; when I approve, do B"), in a spreadsheet with an AI function, in an automation tool, or in your own code. The design principles are the same.
The building blocks
A useful mental model is that every step is one of four kinds:
| Step type | Example | Good at |
|---|---|---|
| Model step | Classify a support ticket, draft a reply | Language, judgement, messy input |
| Code step | Parse JSON, look up an order, compute a total | Exactness, speed, cost |
| Retrieval step | Fetch relevant help-centre articles | Bringing in current or private facts |
| Human step | Approve a refund, edit a press release | Accountability, high-stakes judgement |
Good workflows use each where it fits. A frequent mistake is asking the model to do things code does better (arithmetic, date maths, lookups) or skipping humans where mistakes are expensive.
Example: a support-ticket workflow
1. [Model] Classify ticket -> {category, urgency, needs_order_lookup}
2. [Code] Validate JSON; if invalid, retry once, then route to human queue
3. [Code] If needs_order_lookup, fetch order status from the database
4. [Retrieval] Fetch the 3 most relevant help articles for the category
5. [Model] Draft reply using ticket + order status + articles
6. [Model] Check draft: does every factual claim appear in the sources?
7. [Human] Agent reviews and sends (auto-send only for low-urgency FAQs)Notice what each model step receives: only what it needs. Step 5 gets the actual order status from the database, not the model's guess. Step 6 is a separate verification pass.
Designing the hand-offs
The joints between steps are where workflows break. For each hand-off, define:
- The format. Structured outputs (JSON with fixed keys, or clearly tagged sections) are far easier to pass along and validate than free prose.
- The validation. What does code check before moving on? Required fields present, values within allowed options, length limits.
- The failure path. Retry? Fall back to a simpler prompt? Escalate to a person? Decide in advance.
Classify this ticket and tell me what kind it is and how urgent.
Classify the support ticket in <ticket>. Return ONLY a JSON object with these keys: - "category": one of "billing", "shipping", "technical", "account", "other" - "urgency": one of "low", "medium", "high" - "needs_order_lookup": true or false - "reason": one short sentence Use "high" urgency only for: payment taken without an order, safety issues, or account lockouts. If the ticket fits no category, use "other" — do not invent new categories. <ticket> {{ticket_text}} </ticket>
The improved prompt produces output your code can validate against a fixed list, with a defined fallback for odd cases.
Tip: Many APIs support structured outputs or tool/function calling with a schema. Where available, use them — and still validate in code.
Where to put humans
Put a human checkpoint where an error would be costly, public, or hard to reverse: sending money, emailing customers, publishing, deleting data, legal or medical content. Make the checkpoint easy: show the reviewer the draft and the key inputs it was based on, so approval is a real check rather than a rubber stamp.
Handling non-determinism
The same prompt can produce different outputs on different runs, and even at low temperature settings exact repeatability isn't guaranteed. Workflows should tolerate this:
- Validate structure rather than expecting identical text.
- Make steps idempotent where possible (re-running doesn't cause duplicate side effects).
- Log inputs and outputs of every model step so you can debug and evaluate later.
Agents vs fixed workflows
You'll hear about "AI agents" — systems where the model decides which tools to call and in what order. A fixed workflow, where you decide the order, is simpler to test and more predictable. Agentic designs make sense when the path genuinely can't be known in advance. A sensible default: start with a fixed workflow, and give the model more freedom only where you've seen the need.
Watch out: Every extra model step adds cost, latency and another chance of error. A five-step workflow where each step is right 95% of the time is not 95% reliable overall. Keep workflows as short as the task allows, and add validation where errors compound.
Common mistakes
Mistake: Letting a model guess facts (order status, prices) that a code or database step could supply.
Fix: Fetch facts with code or retrieval and pass them into the model step as context.
Mistake: Passing free-form prose between steps and hoping the next step parses it.
Fix: Use structured outputs with fixed keys and validate them before continuing.
Mistake: No plan for when a step fails or returns something unexpected.
Fix: Define retries, fallbacks and escalation to a human for each step up front.
Practice exercise
Design a content-repurposing workflow
Design a workflow that turns a long blog post into a LinkedIn post, three tweet-length posts and a newsletter blurb. List each step, label it Model / Code / Retrieval / Human, define what passes between steps, and note at least one validation and one human checkpoint. Then write the full prompt for the first model step.
Your draft stays in this browser tab — it isn't sent anywhere.Open the Playground
Hints
You can do the whole exercise as a guest.Sign in to save progress
Knowledge check