Few-shot examples for consistency

Tag each product review with
its main topic and sentiment.
Return JSON.

Tag each review with its main
topic and sentiment. Return JSON.
<examples>
<example>
Review: "Arrived late but the
jacket is lovely."
{"topic":"product",
 "sentiment":"positive",
 "secondary":"delivery"}
Why: the complaint is minor;
the verdict is on the jacket.
</example>
<example>
Review: "ok"
{"topic":null,
 "sentiment":"neutral"}
</example>
</examples>

What examples do that instructions cannot

Anthropic’s prompting guide calls examples one of the most reliable ways to steer Claude’s output format, tone and structure, and says a few well-crafted examples improve both accuracy and consistency. Its consistency guide goes further: examples of the desired output are more effective than abstract instructions. The reason is simple. An instruction describes a pattern in words, and words leave room for interpretation — “main topic” can mean the first thing mentioned, the most-discussed thing, or the thing the star rating reflects. An example is the pattern itself. The model does not have to interpret it, only match it.

Examples are especially good at three things. They pin down format — exact field names, date style, how an empty value is written. They settle judgement calls — which way to go when a case could plausibly be labelled two ways. And they set tone and length, which are notoriously hard to describe in words. When the complaint is “the output is inconsistent from one run to the next”, one of those three is usually underspecified.

Choosing the examples

The documentation’s guidance is to include three to five examples, and to make them relevant (mirror your real use case), diverse (cover edge cases and vary enough that Claude does not pick up unintended patterns) and structured (wrap each in <example> tags, and the set in <examples>, so Claude can tell them apart from the instructions). Each of those words guards against a specific failure.

The third row matters most in extraction work. If every example shows a value for every field, Claude learns that a complete record is what you want — and when a document genuinely lacks a field, it may invent a plausible one. One example with an explicit null teaches that “not stated” is an acceptable, even expected, answer. (Making the schema allow null is the other half; see 4.3.)

Spend your examples where the model is actually uncertain. You find those cases the same way you find false positives: run the prompt on a sample, collect the outputs that disagree with what a human would do, and turn the most common disagreement into an example. The docs also suggest asking Claude itself to evaluate an example set for relevance and diversity, or to propose more cases once you have a starting set.

<instructions>
Route each IT helpdesk message to one queue: access, hardware,
software, or security. Reply with the queue and a one-line reason.
</instructions>

<examples>
<example>
Message: My laptop won't turn on after the update last night.
Reason: the machine itself fails to boot; the update is context.
Queue: hardware
</example>
<example>
Message: I got an email asking me to "re-confirm my password" and
I clicked the link before I noticed the sender.
Reason: a possible credential leak outranks a password problem.
Queue: security
</example>
<example>
Message: Can't log in to the expenses tool, says account disabled.
Reason: the account state is the problem, not the tool.
Queue: access
</example>
</examples>

The second example is the one doing the work. “Password” would pull a naive router towards access; the reason line shows the priority rule — possible compromise beats inconvenience — so Claude can apply it to a case it has not seen, such as a lost phone with the authenticator app on it. The multishot guidance notes that examples work with extended thinking too: showing a short reasoning pattern inside the examples helps the model generalise the judgement rather than copy the surface wording.

Examples for tool calls

When Claude produces structured output by calling a tool, the JSON schema says what shape the input must have — but not how it is used. Anthropic’s engineering write-up on advanced tool use puts the gap this way: a schema cannot say which date format your API expects, whether an ID looks like a UUID or USR-12345, or when an optional nested object should be filled in. For that, a tool definition can carry an input_examples array.

create_ticket = {
    "name": "create_ticket",
    "description": "Open a support ticket. Use for faults the customer "
                   "cannot fix themselves; not for billing questions.",
    "input_schema": {
        "type": "object",
        "properties": {
            "title":    {"type": "string"},
            "priority": {"type": "string", "enum": ["low", "normal", "high"]},
            "due_date": {"type": "string", "description": "YYYY-MM-DD"},
            "reporter_id": {"type": "string"},
        },
        "required": ["title", "priority"],
    },
    # Each example must itself validate against input_schema (else HTTP 400).
    "input_examples": [
        {"title": "VPN drops every 10 minutes", "priority": "high",
         "due_date": "2026-09-23", "reporter_id": "USR-10442"},
        {"title": "Request second monitor", "priority": "low"},  # minimal
    ],
}

The documentation’s rules for these are worth knowing: every example must validate against the tool’s input_schema or the request fails with a 400 error; they work on your own client tools but not on server tools such as web search; and they cost prompt tokens — roughly tens of tokens for a simple example, a couple of hundred for a complex nested one. The engineering post recommends one to five examples per tool, realistic values rather than placeholders, a mix of minimal and full calls, and adding them only where correct usage is not obvious from the schema. Anthropic reports that in its internal testing, examples raised accuracy on complex parameter handling from 72% to 90%.

Traps the wrong answers are built from

You should now be able to

• Recognise when inconsistent output calls for examples rather than more instructions.
• Build a relevant, diverse set of 3–5 examples from observed failures.
• Write examples that demonstrate reasoning on ambiguous cases, not just answers.
• Use a null example to stop an extractor inventing missing values.
• Add input_examples to a tool definition and state their constraints.