Chaining prompts: multi-step workflows

The wall of the single prompt

Every month, Sofia produces the Planiresto newsletter: research across three sources, an editorial angle, a 600-word article, an email subject line that makes people want to open. Armed with chapter 4, she wrote a masterful forty-line prompt asking for everything at once. The result: a text that's correct but oddly flat, research takeaways skimmed over, an angle chosen by default — and no way to know which part of the prompt to fix, since everything comes out as one block.

Chapter 3 already gave the principle: decompose. This chapter turns it into a tooled method: prompt chaining, where each step produces an intermediate artifact — a list, an outline, a draft — that becomes the input of the next step. The difference with the improvised decomposition of chapter 3: here, the chain is designed in advance, documented, and reused identically every month. It's a production process, not a conversation anymore.

Why does a chain systematically beat the mega-prompt on complex jobs? Three reasons. Quality: each step gets the model's full attention, instead of sharing a single effort. Control: you can inspect and fix each artifact before it contaminates what follows. Diagnosis: when the final result disappoints, you know which step to look at — exactly like the debugging tree of chapter 5, but applied to an entire process.

Designing the chain: steps, artifacts, checkpoints

A chain is designed backwards, starting from the deliverable. For the newsletter: you need a finalized article; so before that, a critiqued draft; so before that, a draft; so before that, a validated angle; so before that, research takeaways. Five steps, four intermediate artifacts. For each step, note three things: what it receives, what it produces, and who validates — you or nobody.

flowchart LR
  A["Research sources"] --> B["Step 1: key takeaways"]
  B --> C["Step 2: three proposed angles"]
  C --> V{"Human validation of the angle"}
  V -->|"Angle chosen"| D["Step 3: full draft"]
  D --> E["Step 4: targeted critique"]
  E --> F["Step 5: final version + subject line"]

Look at where the validation is placed: after the angle proposals, before the writing. That's the point of maximum leverage: the most structuring decision (what are we talking about, from what angle) is made on a short artifact readable in thirty seconds, before hundreds of words get written in the wrong direction. Validating earlier would control nothing (the raw takeaways are factual); validating later would be expensive (rewriting 600 words because the angle was wrong). Always place your validation where the decision is still small and its consequences still large.

Step 1: extracting the takeaways

You are a research analyst for a company making scheduling software for restaurant owners.

Here are three research pieces, each between delimiters:
--- SOURCE 1 ---
{{article 1}}
--- SOURCE 2 ---
{{article 2}}
--- SOURCE 3 ---
{{study 3}}
--- END ---

Task: extract the 5 most useful takeaways for restaurant managers, citing the source of each.

Format: numbered list; each takeaway = 1 sentence of fact + 1 sentence "why it matters for a restaurant owner" + the mention [Source N]. Only what appears in the sources: if a point is an interpretation, flag it with [interpretation].

The whole course converges in this step prompt: role with audience (chapter 4), delimited sources (chapter 1), strict format with traceability (chapter 4), and a guardrail against invention ("only what appears in the sources"). The artifact produced — the sourced list — is short, verifiable in two minutes, and becomes the input of the next step. That's the key property of a good intermediate artifact: quickly inspectable.

Steps 2 and 3: the artifact as a baton pass

Here are the validated takeaways from this month's research:
{{list from step 1, corrected}}

Task: propose 3 editorial angles for the monthly newsletter, from the safest to the boldest.

Format for each angle: a working title, the main takeaway it exploits, the promise to the reader in 1 sentence, and the risk of this angle in 1 sentence. Do NOT write the article: only the angles.

Two details make this link robust. "Here are the validated takeaways": Sofia pastes the list she has reread and possibly corrected — the chain transports controlled information, not a machine's raw output. And "do not write the article": without this boundary, the model happily spills over into the next step, and you receive an article based on an angle you didn't choose. Each step must do its job, all of its job, and nothing but its job.

Step 3 — the writing — follows the same relay pattern, and it's the one that benefits most from the upstream work: the substance has been validated twice, the model only has to write well. That's the mental inversion of chaining: secure the thinking first, the writing second — whereas the mega-prompt did everything at once, and everything averagely.

Chosen and validated angle: {{angle 2, adjusted after review}}.

Write the full draft of the April newsletter.

Constraints:
- About 600 words. Structure: introduction, 3 titled parts, conclusion with a call to action.
- Direct, concrete tone, address the reader directly, one example or figure per part.
- Rely ONLY on the validated takeaways below, without adding outside facts:
{{list of validated takeaways}}
- Do not write the email subject line or any variants: only the body of the newsletter.

Note the last constraint, another step boundary: the email subject line is deliberately postponed to step 5, after the critique. Why? Because a good subject line is chosen on the final version of the text, not on a draft that will still move — and because the subject line deserves its own prompt regime: at step 5, Sofia asks for "8 subject lines under 50 characters, from the most sober to the most intriguing", an open implicit-temperature phrasing (chapter 4), whereas writing the body demanded a closed temperature. A well-designed chain tunes the regime of each step to its nature: locked-down factual for research, unbridled creative for the subject line.

Step 4: the generator-critic loop

The fourth step applies the self-critique of chapter 3, but specializes it: rather than a vague "reread and improve", the critique receives a precise grid — and that's where the personas of chapter 6 come back on stage.

Here is the draft of our newsletter:
---
{{draft from step 3}}
---
Critique it along 4 axes, without rewriting it:
1. Hook: does an overwhelmed restaurant owner read past the first sentence? Why?
2. Concreteness: does each part contain a usable example or figure?
3. Tone: spot any sentence that sounds corporate or hollow, quote it.
4. Action: does the ending give a clear reason to click?

Format: for each axis, a one-sentence verdict + a quote of the passage concerned + a concrete suggestion. End with the 2 priority fixes.

Keep the critique well separated from the rewrite: a prompt that asks for both at once produces a complacent critique and a timid rewrite. In two stages — critique first, then "apply fixes 1 and 3, leave the rest" — you keep control over what changes. And the "quote the passage concerned" forces the critique to be verifiable: a critique without a quote is an opinion, a critique with a quote is a diagnosis.

One conversation or several? The context question

Should you run the chain in a single conversation or open one per step? Both work, with a trade-off. A single conversation keeps the context (the model remembers past steps), but the history gets heavy and old instructions lose weight — the drift seen in chapter 4. Separate conversations start clean, but you must re-paste the input artifact yourself each time.

Sofia's practical rule: separate conversations for the critical steps (the step 4 critique is more honest when the model didn't write the draft itself in the same thread — it doesn't have to defend its own work), a single conversation for short sequences. And in all cases, each step prompt explicitly re-pastes its input artifact: the chain must never depend on the conversation's memory to work. That's what makes it replayable the following month.

Parallel variants and the documented chain

Chaining has a cousin: parallelization. At step 3, rather than one draft, Sofia sometimes asks for two on the same angle — one classic, one bolder — then submits both to the step 4 critique and keeps the better one. Generating variants costs a few seconds; choosing between two critiqued versions almost always gives a better final than improving a single version. Reserve this luxury for high-stakes content: it's extra review time.

What remains is to capitalize. A chain that has proven itself gets documented like a chapter 5 template, but at process scale: a "Newsletter chain" document listing the steps, each step's prompt with its {{ }} fields, the expected artifact, and the validation point. The next month, Sofia unrolls the document instead of reinventing — and every improvement found along the way is carried back into the document. Her newsletter went from a painful full day to two calm hours, with a quality her old mega-prompt never came close to.

One last reflex to mature your chains: measure them. Note, at every run, the time spent per step and the place where you corrected the most. These two numbers designate the next improvement without debate: if step 4 sends you the same two critiques every month, the step 3 prompt should integrate those requirements upfront; if the angle validation has taken you thirty seconds for three months, maybe it can be lightened. A chain isn't a monument: it's a process that gets refined through use, exactly like a template — and the document that describes it is where that refinement accumulates instead of evaporating.