Server AtticLearning Harbour

AI Foundations · Module 3 · Lesson 3 of 3

Iterating on instructions: when more context beats cleverer wording

When an AI's output is not quite right, the instinct is to rephrase the instruction more cleverly — this lesson makes the case that adding the missing context, constraint or example usually fixes it faster, and closes the module by adding a review criterion and a stop condition to build a complete, testable task brief.

Lesson · 15–20 minutes · Text-first

By the end, you can

  • Explain why adding missing context, a constraint or an example is usually a more effective fix for a weak instruction than rephrasing it more persuasively (AF-3).
  • Add a review criterion and a stop condition to an instruction, so a named person can check the output and the AI is told in advance to ask rather than guess when it hits a gap (AF-3).
  • Produce a complete, testable task brief — goal, context, constraints, example or format, stop condition, review criterion — for a sample task (AF-3).

Before you start

This is Module 3, Lesson 3 of 3, the module's closing lesson. It builds on Lesson 1's three building blocks (goal, context, constraints) and Lesson 2's two more (examples, output format), and on Module 2 Lesson 3's decision habit for naming who checks an AI's output before it is used. This lesson does not require coding or technical setup.

The instinct to rephrase, and why it usually isn't the fix

When an AI's first attempt at a task is not quite right, the common instinct is to ask again more forcefully: "no, do it properly this time," "please be more thorough," "try harder." This treats the problem as one of persuasion — as if the AI held back effort the first time and needs more encouragement. But an instruction that was missing a fact, a constraint or an example the first time is still missing it after being rephrased more forcefully. Rephrasing changes the wording; it does not supply what was never there.

Anthropic's current prompting guidance illustrates this directly with a real before/after. Its **less effective** example instruction is simply "NEVER use ellipses." Its **more effective** version does not use stronger or more insistent language — it adds a reason: explaining that the output will be converted to speech, so ellipses would be misread aloud. The fix was not a firmer tone; it was a fact the model did not have. This is the same lesson this course has returned to since Module 1: a fluent output is not the same as a correct one, and a firmer-sounding instruction is not the same as a more complete one.

Google's prompt design guidance frames iteration as expected rather than a sign of failure — **"prompt design can sometimes require a few iterations before you consistently get the response you're looking for"** — and lists several concrete levers for that iteration: rephrasing, reordering the prompt's content, and, most relevantly here, providing information the prompt was missing. OpenAI's guidance treats iteration the same way: as something to measure, not guess at, describing **"building tests and evaluation suites that measure prompt behavior so you can monitor performance as you iterate."** None of the three sources frames "say it more insistently" as a real lever at all — the actual levers are the building blocks this module has covered (context, constraints, examples, format) plus reordering, which Google's guidance names directly.

A review criterion completes the brief

Lessons 1 and 2 built four parts of a checkable instruction: goal, context, constraints, and examples or format. One part is still missing, and it is the one this course keeps returning to: **who checks the output, and against what.** Module 2 Lesson 3's decision habit already asked this question for whether to use AI on a task at all. This lesson applies the same question to the instruction itself: a task brief is not complete until it states a review criterion the AI's own output cannot satisfy on its own.

This matters because nothing about a well-written instruction changes what an AI system actually is. The US National Institute of Standards and Technology frames an AI system as something that generates "outputs such as predictions, recommendations, or decisions" — the framework does not describe the system as verifying those outputs itself. A goal, context, constraints and an example make an instruction checkable; a stated review criterion is what actually gets it checked. Without one, even a well-specified instruction can produce a fluent, confident, wrong answer that nobody was looking for.

A review criterion names three things: what specifically gets checked (not "does this look right" but a named fact, figure or condition), against what source, and who does it. "A manager skims it before sending" is not a review criterion. "The project owner compares each stated task status against the live board before the update is sent" is.

A stop condition: make asking an allowed answer

A review criterion catches problems after the output exists. A well-designed brief also heads some of them off before that, with a **stop condition**: an instruction telling the AI what to do when it hits a gap the brief did not anticipate — a missing fact, two sources that contradict each other, something only a person has the authority to decide. For example: "If the supplied entries do not answer this, say what is missing instead of filling the gap," or "If two figures conflict, flag the conflict and ask rather than choosing one." This is guidance, not a vendor-documented technique — but it follows directly from everything this module has covered: Lesson 1 showed that an unstated decision gets filled with a plausible guess, and a stop condition is how the brief says, in advance, that for *this* kind of gap a question is the right output, not a guess. The review criterion and the stop condition work as a pair: one names the person who checks the output, the other gives the AI permission to stop and ask before there is anything to check. Learners who go on to Course 1 (Local AI Agents) will meet the same idea again as a bounded task's stop rules.

A worked example: iterating a weak instruction into a complete brief

A team lead's first instruction to an AI tool is: "Summarize this week's customer feedback." The output comes back fluent and confident — but vague: general impressions with no specific complaints named, because the instruction never supplied the actual feedback text.

The team lead's first instinct is to rephrase: "Give me a better, more detailed summary of this week's customer feedback." Without new context, the second attempt is just as fluent and just as unverifiable as the first — a more confident-sounding paragraph built from the same missing information. Applying this lesson instead: the fix is not firmer wording, it is the missing building blocks. **Context** — attach the actual 40 feedback entries from this week, not a description of them. **Constraints** — do not report a complaint that appears in fewer than three entries as a "trend"; do not invent a customer name. **Output format** — a table with columns: complaint, number of entries, one representative quote. **Review criterion** — before the summary goes to the wider team, the team lead spot-checks three rows against the original feedback entries to confirm the counts and quotes are accurate. **Stop condition** — if an entry is unreadable, ambiguous about what it is complaining about, or refers to something outside this week's entries, list it under "could not classify" and ask, rather than guessing a category for it.

The complete, testable task brief: "Summarize this week's customer feedback [context: the attached 40 feedback entries] into a table with columns complaint, number of entries, one representative quote [output format]. Only report a complaint as a trend if it appears in three or more entries; do not invent a customer name or quote [constraints]. Example row: complaint: 'shipping was slower than expected', number of entries: 5, quote: 'my order took twice as long as the estimate.' If an entry is unreadable or ambiguous, list it under 'could not classify' instead of guessing [stop condition]. [Review: before this is shared with the wider team, I will check three rows against the original entries to confirm counts and quotes match.]"

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Practice

Improve a weak instruction into a testable task brief

A volunteer coordinator's first instruction to an AI tool was: 'Write something to thank our volunteers.' The output was a generic, fluent thank-you message that could have applied to any organisation, mentioned no specific event, and the coordinator is not sure it is accurate enough to send. The actual facts available: 34 volunteers helped run a weekend food-bank drive on 12-13 September; the drive collected 900kg of food; two volunteers, Dan and Priya, coordinated the van pickups. The message needs to go out by email to all 34 volunteers by name where possible, must not overstate what any individual volunteer did beyond what is confirmed above, and someone should check it before it is sent.

  1. Explain why simply asking the AI to 'try again, but warmer and more heartfelt' would not fix this instruction's actual problem.
  2. Write the context this instruction is missing.
  3. Write at least one constraint that follows from 'must not overstate what any individual volunteer did.'
  4. Write a review criterion: who checks the message, against what, before it is sent?
  5. Write the complete, testable task brief in one paragraph, combining goal, context, constraints, format, a stop condition and the review criterion.
Compare with a bounded first version

Asking for 'warmer and more heartfelt' only changes tone, not the missing facts — the message would still be generic because it still would not contain the specific event, date, tonnage or names, which is the actual reason it reads as generic. Context: the message is thanking volunteers for a specific event — a weekend food-bank drive on 12-13 September that collected 900kg of food, with Dan and Priya named as the van-pickup coordinators. Constraint: do not attribute a specific role or achievement (for example, 'you personally saved X families') to any volunteer beyond what is confirmed — Dan and Priya's coordinating role is confirmed, but no other individual contribution is broken out, so the message should thank the group by name list rather than inventing individual credit. Review criterion: before the email is sent, the coordinator checks that the event date, the 900kg figure and Dan and Priya's role match the coordinator's own records, and confirms the volunteer name list is complete and correctly spelled. Complete task brief: 'Write a thank-you email to our 34 food-bank drive volunteers, addressed to them by name where possible. Context: this was a weekend food-bank drive on 12-13 September that collected 900kg of food; Dan and Priya coordinated van pickups. Constraints: do not attribute any other specific individual achievement beyond Dan and Priya's coordinating role; thank the rest of the group collectively. Keep it under 150 words. If you need a fact not listed here — another name, another figure, anything about the drive — leave a marked gap and ask instead of inventing it. Before sending, I will check the event date, the 900kg figure, and Dan and Priya's credited role against my own records, and confirm the volunteer name list.' The second-to-last sentence is the brief's stop condition: it tells the AI in advance that a question is the right output for any gap, since every confirmed fact has already been supplied.

Knowledge check

Try the idea

An AI-generated project status report says 'the project is progressing well,' but the instruction that produced it never supplied the actual task board or status data — it only asked for 'a positive-sounding update.' What is the most effective next step, according to this lesson?
Low-stakes practice only. This does not score, block progress or create a learner record.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

  1. Prompting best practices — Anthropic. Contrasts a less-effective rephrased instruction with a more-effective one that adds context or motivation, illustrating that the fix for a weak instruction is usually added information, not persuasive wording.
  2. Prompt engineering — OpenAI. Describes building tests and evaluation checks to measure prompt behavior and monitor performance while iterating on a prompt.
  3. Prompt design strategies — Google AI for Developers. States that prompt design can require a few iterations before consistently getting the desired response, and lists rephrasing, reordering content and providing missing information among the available strategies.
  4. Artificial Intelligence Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as generating outputs such as predictions, recommendations or decisions, not as a system that verifies its own output — the basis for this lesson's point that a task brief needs a stated review criterion, not just a clearer instruction.