XML Tags as Scaffolding — Why <example> Outperforms "for example"

You've written a prompt with an example, some instructions, and a block of user-supplied text. Claude mostly handles it well — until the day it treats your example as a real instruction, or folds part of your instructions into its output. XML tags fix this.

The jargon

XML tags — labels wrapped in angle brackets, like <example> and </example>. The opening tag marks the start of a section; the closing tag (note the /) marks the end. You don't need to know XML to use them — Claude just reads them as named containers.

The lesson

Plain English connectives ("for example", "here is the input", "note:") are ambiguous to a language model. The model has to infer where one section ends and another begins. It usually guesses right, but "usually" is not a prompt engineering strategy.

XML tags are unambiguous. Claude was trained on vast amounts of structured text and treats these tags as hard boundaries. When you wrap something in <example></example>, Claude knows that content is an illustration — not an instruction to follow, not the actual user input.

Anthropic's own prompt guides recommend this pattern explicitly. It's not a workaround; it's the intended interface.

How it works

Without tags:

Summarise the text below in two sentences. Here is an example of a good summary: "The report found three risks." Now here is the actual text: The 2024 audit covered...

Claude might blend the example into the output, or treat the example sentence as part of the text to summarise.

With tags:

Summarise the text below in two sentences.

<example>
The report found three risks and recommended immediate action on two of them.
</example>

<text>
The 2024 audit covered procurement, finance, and IT security...
</text>

Now Claude has no ambiguity. The <example> block is a reference. The <text> block is the target. These are different things, and the tags say so explicitly.

You can name your tags anything sensible: <instructions>, <context>, <persona>, <output_format>. The name is just a label — pick one that reflects what the section actually contains.

When to reach for it / when not to

Use tags whenever your prompt contains more than one distinct type of content — especially examples, user-supplied data, or instructions you want kept separate from each other. They're most valuable in longer prompts where the risk of the model losing track is real.

Skip them for simple, single-purpose prompts. "Translate this to French: [text]" doesn't need scaffolding. Adding tags to everything is noise.

One caution: if you're passing user-supplied text inside a tag, a malicious user could try to inject their own closing tag to break out of the container. For internal tools this rarely matters. For public-facing apps, sanitise user input before wrapping it.

Try it

Take a prompt you already use — one that includes an example or some reference material. Wrap each distinct section in a named XML tag. Run the same input through both versions and compare the outputs. Notice whether the tagged version handles the boundaries more cleanly, particularly if your example and your real input are similar in style.