6. When One Prompt Is Not Enough
Same notes, same model. The one shot email never mentioned the competitor. Splitting it into analyze-then-write pulled the deadline forward and addressed the risk directly.
The WJS Desk
Sep 7, 2026 ยท 7 min read

Some jobs do not fit in one prompt. Not because they are too long, but because the first half changes what the second half should be.
Chaining means splitting the job: one prompt that works something out, then a second prompt that uses the answer. It sounds like extra effort for the same result. On the test we ran, it was the difference between an email that would have lost an account and one that might save it.
The same task, one step and two
We used the customer call from lesson 5. One shot first: notes in, email out. That produced an email opening with "Thanks for taking the time to chat today" and containing "Export performance at scale is something we take seriously." It committed to an update by Thursday, which is what the notes said.
Then we split it. Step one deliberately refused to write anything:
Here are notes from a customer call.
[notes]
Do not write the email yet. First, list what is at stake
in this account, what Dana actually needs to hear, and what
I should avoid saying. Be blunt.
What came back was not an email and was much more useful:
Mentioning competitors twice = they're seriously considering it. 6 weeks to renewal means you're in the danger zone. A "I'll check with engineering" holding pattern until Thursday loses them.
It also specified what Dana needed: a real engineering assessment within 48 hours, and either a fix date or a workaround, with the note that they need specifics rather than "we'll look into it".
Step two fed that analysis back in and asked for the email. The result moved the commitment from Thursday to Tuesday, offered pagination or filtered exports as an interim workaround, and acknowledged the competitive situation directly.
| One shot | Chained | |
|---|---|---|
| Opens with | Thanks for your time | I escalated this morning |
| Commitment | Thursday, as in the notes | Tuesday, pulled forward |
| Workaround offered | No | Yes, specific |
| Addresses the competitor | Not at all | Directly |
Why the split changes anything
When you ask for an email, everything gets optimized for being a good email: it must be polite, it must flow, it must not be awkward. Sharp observations like "a holding pattern until Thursday loses them" do not survive that, because they are not polite and they do not flow.
Splitting removes the pressure. Step one has no audience, so it can be blunt. Step two receives that bluntness as an input it has been told to act on, rather than as something it has to invent while also being diplomatic.
A single prompt makes the model do the thinking and the diplomacy at the same time, and diplomacy wins. Separating them lets the thinking survive contact with the writing.
When to reach for it
Not everything needs two steps. The signal is when the job contains a genuine decision that the output then depends on:
| One prompt is fine | Split it |
|---|---|
| Fix the grammar in this | Decide what this document is missing, then write the missing part |
| Summarize this thread | Work out who is blocked on what, then write each person their action |
| Rewrite this shorter | Work out which argument is weakest, then rewrite around that |
| Translate this | Identify the phrases with no clean equivalent, then translate with notes |
The right column shares a shape: a judgement, then work that depends on the judgement. That is what one prompt handles badly.
The three useful chains
Analyze, then produce. The one above. The most generally useful, and the one to try first.
Step 1: Do not write it yet. Tell me what matters here,
what the reader needs, and what I should avoid.
Step 2: Now write it, using that.
Produce, then critique, then revise. For anything going somewhere public.
Step 1: Write the draft.
Step 2: [new chat] Here is a draft. What is wrong with it
and what is missing? Do not rewrite it.
Step 3: Here is the draft and the critique. Revise.
Step two belongs in a fresh conversation. We tested this in the Super Beginner course and the finding was clear: the same model defended its own arithmetic in the original chat and demolished it when the same text arrived with no history attached.
Extract, then act. For messy input.
Step 1: Pull every date, name, number and commitment out
of this, as a list. Do not interpret.
Step 2: Here are the extracted facts. Now build the summary.
Splitting extraction from interpretation gives you a checkpoint. You can look at the extracted list, see that it missed something, and fix it before that error propagates into the output.
Doing it without extra work
Chaining sounds like it doubles the effort. In a chat interface it does not, because the conversation already carries the previous step:
You: [notes] Do not write the email yet. Tell me what is
at stake and what to avoid.
AI: [analysis]
You: Good, but the renewal risk is bigger than you have it.
Now write the email. Under 150 words.
That middle turn is the whole technique, and it is where you get to correct the analysis before it hardens into a draft. You are not writing two prompts. You are refusing to accept the first output as final.
The habit worth building. When a task feels important, make your first message forbid the deliverable. "Do not write it yet" costs one line and buys you a look at the reasoning before it is buried inside a polished paragraph.
The checkpoint is the point
The strongest argument for chaining is not output quality. It is that a chain gives you somewhere to intervene.
In our test, the analysis step said the renewal risk was serious and the Thursday commitment was too slow. Suppose we disagreed. Suppose we knew Dana well, knew the competitor mention was a negotiating habit rather than a real threat, and that Thursday was fine. We could say so:
The competitor mention is how Dana always negotiates, it
is not a real threat this quarter. Thursday is fine.
Rewrite the analysis with that, then write the email.
A one shot prompt gives you no such moment. You get a finished email built on an assumption you never saw, and the only way to find the assumption is to reverse engineer it from the draft.
That is the general shape: a chain converts hidden reasoning into something you can argue with. Everything else it does is secondary.
Chaining across a whole piece of work
The technique scales past two prompts, though not as far as people try to take it. A real four step chain we use for anything long:
1. Here is the raw material. Pull out the facts, the
numbers and the commitments. Do not interpret.
2. Here are the facts. What is the single most important
thing here, and what would a reader most want to know?
3. Now write it, leading with that. [constraints]
4. [fresh chat] Here is a draft. What is missing that a
reader would expect? Do not rewrite it.
Note where the checkpoints are. After step 1 you can see whether it missed a fact. After step 2 you can disagree about what matters. After step 4 you decide whether the criticism is fair. Three places to intervene, in a job that a single prompt would have done invisibly.
Beyond four steps this stops paying. Each link inherits everything the previous one got wrong, and by step six you cannot tell where a mistake entered. If a job seems to need six steps, it is usually two jobs.
Where chaining goes wrong
- Splitting something that was never two jobs. An analysis step on "fix this typo" produces a paragraph about typos.
- Not reading the middle step. The checkpoint is the value. If you skim it and say "now write it", you have paid for two calls and got one.
- Letting the analysis leak into the output. Say what the output should be. Without that you sometimes get an email with a strategy section attached.
- Chaining in one chat when you needed a fresh one. For critique specifically, history biases the result. Start over and paste.
- Too many links. Two steps is usually enough, three occasionally. Beyond that each step compounds the previous step's errors and you lose track of where a mistake entered.
Try it now
Take something you are going to write this week that has a decision inside it: a reply to a difficult message, a proposal, a piece of feedback for someone.
Write the notes. Then send exactly this: "Do not write it yet. Tell me what is actually at stake, what they need to hear, and what I should avoid saying. Be blunt."
Read what comes back before you ask for anything else. In our test that step was where the useful thinking was, and it never would have survived being asked for an email.
Next
Lesson 7 is about working with documents too long to read, and about a limitation we went looking for and could not find.


