Decompose and verify
Big prompts produce mushy outputs. Split the work into stages, make the model cite its sources, and exploit the way models read long context.
When a prompt is doing too much, the output gets blurry. The model is trying to research, analyze, write, and format all at once, and each step contaminates the others. The fix is to break the work into stages and run each one cleanly. This is also where the verification techniques live — cite-as-you-go, uncertainty flags, the "lost in the middle" effect, and when to attach a file versus paste it.
This is the longest of the five Essentials pages because it's the part most knowledge workers underuse.
Decompose: one big prompt → three small ones
The pattern that beats almost every monolithic prompt:
- Plan. "Outline the steps you'd take to produce [deliverable] from [inputs]. Don't do the work yet. Just the outline."
- Execute. "Now execute step 1." Then step 2, etc. — one message per step.
- Review. "Compare the final output against the outline from step 1. What did you skip, soften, or miss?"
Three turns. Each turn is doing one thing. The output is sharper because the model isn't context-switching between research and writing on the same generation.
This is essentially the plan-then-execute pattern from agent research, applied to a single conversation. The reason it works isn't mysterious — it's the same reason an analyst working from a written outline produces tighter work than one writing freehand.
When to decompose:
- The deliverable has multiple sections that draw on different sources.
- You've tried a one-shot prompt and the output is uneven (some sections strong, others vague).
- The work involves both research/analysis AND synthesis. These are different jobs; split them.
When NOT to decompose:
- Quick drafts where one-shot is good enough.
- Tasks the model handles cleanly in one pass — most polite emails, most short summaries, most extraction work.
Make it cite
The single cheapest hallucination control we have.
"For every numerical claim, quote the source line that supports it. For every named person or company, name the input file where you found them. If a fact isn't in the inputs, flag it with [INFERRED]."
A model with citations turned on will sometimes refuse to make a claim it would have happily fabricated otherwise — which is the entire point. The act of having to point at a source line filters out the things that don't have a source line.
Two tactical notes:
- Ask for quoted support, not just a page reference. "Page 3" the model will invent. A two-sentence quote it can only invent by lying explicitly.
- Use the
[INFERRED]tag (or your preferred marker) for anything the model is reasoning about rather than reporting. You want to see the inferences; you just want to know they're inferences.
Make it flag uncertainty
"Mark anything you're not fully sure about with [LOW CONFIDENCE]. If a piece of data is missing from the inputs and you're filling in based on general knowledge, mark it [GENERAL KNOWLEDGE]."
Models can self-report uncertainty if asked. Without the prompt, they default to a confident voice across the board — which is what makes silent hallucinations possible. With the prompt, you get back a draft that's annotated with where to look harder.
The tags also let you do the editing pass quickly: search the doc for [LOW CONFIDENCE] and [INFERRED], verify those passages, ship the rest.
The lost-in-the-middle fix
Models pay more attention to the beginning and end of a long prompt than to the middle. This is a known and measured behavior — the same instruction buried in paragraph six of a long prompt is more likely to be ignored than one at the top or the bottom.
Practical implications:
- Put the task at both the top and the bottom of a long prompt. Open with "Here's what I need you to do." Close with "Now, to summarize: do [task]." Same instruction, twice. It feels redundant. It isn't.
- Lead with the most important constraint. If the deliverable absolutely must be under 250 words, that constraint goes at the top, not at the bottom of paragraph four.
- Long input documents go in the middle of the prompt, not at the end. Put your instructions around the document — task above, restated task below — and the document in between.
- For very long context windows, restate. If you've attached a 50-page PDF, the task and constraints should both precede the PDF reference AND follow it.
This effect is real and worth designing around. It's also why the example structure in Show, don't tell works — the example goes near the top, the actual input goes after.
Attach vs paste
A small structural choice that materially changes output quality.
Attach a file when:
- The content has structure that matters: tables, columns, headings, sections.
- The content is long (>1,000 words). Pasting long content into the prompt pushes everything else into the lost-in-the-middle zone.
- You want the model to refer back to specific cells, rows, or sections later in the conversation.
- The file is a real artifact (Word doc, Excel sheet, PDF) — attaching preserves the format.
Paste content when:
- It's short (one paragraph, a single email, a tweet).
- The structure doesn't matter and the model just needs the prose.
- You want to quote something rather than reference it — e.g., pasting a customer's specific complaint into a draft response.
Default: when in doubt, attach. The penalty for pasting structured content is much higher than the penalty for attaching short content.
The verification chain that ships
For high-stakes outputs, combine three techniques:
- Decompose — plan, execute, review.
- Cite — quote the source line for every claim.
- Flag — mark anything uncertain.
Then your human review pass becomes:
- Scan the citations. Spot-check three.
- Search for
[LOW CONFIDENCE]and[INFERRED]. Verify or remove. - Read the final result for tone.
That's a 5-minute review pass instead of a 30-minute one — and it catches the things that actually matter.
Common mistakes
- One giant prompt for a multi-stage deliverable. Decompose.
- Asking for "facts" without asking for citations. The model will provide both. The latter exposes the former.
- Trusting a confident-sounding output more than a hedged one. Confident is a tone, not a signal. Hedged with citations beats confident without.
- Pasting a long Excel as Markdown. Attach the .xlsx. The model reads tables better than re-flowed tab-separated text.
- Burying the most important instruction in paragraph four. Top and bottom. Always.
Where to go next
- The four-part prompt — the scaffolding under decomposition.
- Make it a critic — the review pass that pairs with the verification chain above.
- Show, don't tell — when each decomposed stage benefits from a per-stage example.