Examples and output format: making instructions checkable

By the end, you can

• Explain why showing an AI system a worked example steers its output more reliably than describing the desired output in words alone (AF-3).
• Specify an output format precisely enough that a reviewer can check a response against it without guessing (AF-3).
• Rewrite an instruction to add a worked example and a stated output format (AF-3).

Before you start

This is Module 3, Lesson 2 of 3. It builds directly on Lesson 1's three building blocks — goal, context, constraints — and adds two more: examples and output format. It also draws on Module 2 Lesson 2's distinction between classification (a category label) and other task types, since this lesson's worked example is a classification task. This lesson does not require coding or technical setup.

Showing beats describing

Lesson 1 covered stating what you want in words. This lesson covers showing it. A worked example of the exact output you want is one of the most reliable ways to get an AI system to reproduce that shape, tone and structure — more reliable, in practice, than a longer paragraph of description. Anthropic's current prompting guidance states this directly: **"Examples are one of the most reliable ways to steer Claude's output format, tone, and structure. A few well-crafted examples (known as few-shot or multishot prompting) improve accuracy and consistency,"** and recommends including **"3–5 examples for best results."** OpenAI's prompt engineering guidance describes the same technique in its own terms: **"few-shot learning lets you steer a large language model toward a new task by including a handful of input/output examples in the prompt."** Google's prompt design guidance goes further and treats examples as close to mandatory rather than optional: it recommends teams **"always include few-shot examples in your prompts"** and states that **"prompts without few-shot examples are likely to be less effective."**

The pattern across all three is the same: an example is not decoration. It reduces ambiguity that a written description leaves open — exactly how short is "short," exactly what does "professional tone" mean for this team, exactly which fields belong in the output and in what order.

Stating an output format precisely

The other missing building block from a vague instruction is shape: what form should the answer actually take? "Give me a summary" could reasonably produce a paragraph, a bullet list, a table or a single sentence — all technically summaries. A checkable instruction states the shape: "three bullet points, each under 20 words" or "a table with columns: item, category, confidence."

Anthropic's guidance offers a specific technique for this that is worth adopting as a habit: **state what the output should be, not just what it should avoid.** Its own example contrasts "Do not use markdown in your response" with the more effective "Your response should be composed of smoothly flowing prose paragraphs" — the second gives the model something to aim for, rather than only something to avoid. The same logic applies to any output-format instruction: "don't make it too long" is a constraint with nothing to aim at; "keep it to three sentences" is checkable.

A worked example

A support team wants an AI tool to classify incoming customer emails into "billing," "technical" or "feedback" — the same classification task type Module 2 Lesson 2 covered. Their first instruction is: "Sort this email into the right category."

That instruction has a goal (of sorts) but no example and no stated format — the reply could be a single word, a sentence, or a paragraph explaining the reasoning. The team adds both. First, an example: "Email: 'My invoice this month is £40 higher than usual and I don't understand why.' Category: billing." Second, a stated output format: "Reply with exactly one word: billing, technical, or feedback. Do not add an explanation." The rewritten instruction pairs the worked example with the exact output shape the team's routing system can actually use — a single category word it can match against a queue name, not a sentence it would have to parse.

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.

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. States that a few well-crafted examples (few-shot or multishot prompting) improve accuracy and consistency, recommends 3-5 examples, and describes telling the model what to do instead of what not to do as an effective way to steer output formatting.
2. Prompt engineering — OpenAI. Describes few-shot learning as steering a model toward a task by including a handful of input/output examples in the prompt.
3. Prompt design strategies — Google AI for Developers. Recommends always including few-shot examples in prompts, and states that prompts without few-shot examples are likely to be less effective.
4. Ticket routing — Anthropic. Describes ticket routing as a classification task producing a category label, used here as the worked example's checkable output.