Course Content
Prompt Engineering Mastery
6 sections · 32 lessons
How do you handle long or multi-step tasks using prompts?
What you need to know
A single prompt that says "read this 40-page contract, find the risks, compare with our policy, and write an email" asks the model to do four jobs at once. When the email is wrong, you cannot tell which job failed.
Techniques
- Ordered steps in one prompt — fine for short tasks: "1. extract the dates, 2. check each against today, 3. list the overdue ones."
- Prompt chaining — separate calls, each with its own prompt, tests and model choice.
- Plan, then execute — ask for a plan first, review it (in code or by a person), then run each step.
- Draft, critique, revise — a second call reviews the draft against a checklist and a third fixes it.
- Carry state explicitly — pass a JSON object or short summary between steps, not the full transcript.
- Validate between steps — schema checks, business rules, or a human approval before the next step.
When to chain and when not to
| Chain when | One call is fine when |
|---|---|
| Steps need different models or tools | The task is short and self-contained |
| You must validate or approve midway | No step needs checking by code |
| One step is reused elsewhere | Latency matters more than traceability |
| Errors must be traced to a step | A reasoning model does it well in one go |
In 2026 reasoning models plan multi-step work internally, so the old reason to chain — "the model can't hold it all at once" — is weaker. The reasons that remain are engineering ones: testability, cost, checkpoints and control. When steps need branching, tools and retries decided by the model, the chain has become an agent.
A real-life example
An e-commerce site generates product pages from supplier spreadsheets. One big prompt produced pages where about 6% had wrong specs, and nobody could tell whether the extraction or the writing step was to blame. They rebuild it as a chain:
- Extract — a small, cheap model turns the supplier row into JSON specs using a strict schema.
- Validate — code checks units, ranges and required fields; bad rows go to a human queue.
- Write — a stronger model writes a 70-word description from the validated JSON only.
- Check — a verification call lists any claim not supported by the JSON; flagged pages are held.
Step 4 prompt:<specs>{"capacity_l": 5, "material": "304 stainless steel"}</specs><description>...</description>List every factual claim in the description that is not supported by<specs>. Return {"unsupported": [...]} and nothing else.Wrong-spec pages drop to 0.5%, each failure is traced to one step, and the cheap model handles the extraction step — which is 70% of the calls.
Follow-up questions to expect
- "Doesn't chaining add latency?" — Yes, each call adds a round trip. Run independent steps in parallel and use small models for simple steps.
- "How do you stop an error in step 1 spreading?" — Validate the structured output between steps and stop or route to a person when it fails.
- "Chain or agent?" — A chain is a fixed path you design; an agent lets the model choose the next step and tools. Use a chain when the path is known.