A simple structuring trick that turns messy, unpredictable LLM outputs into clean, reliable ones.
If you've spent any time writing prompts for Claude, GPT, or any other large language model, you've probably hit this wall: your prompt works fine for a simple ask, but the moment you pack in multiple instructions — some context, a few examples, formatting rules, and the actual task — the model starts mixing things up. It answers the wrong part of the question. It ignores your formatting instructions. It treats your example output as part of the actual task.
The fix is almost embarrassingly simple: wrap your prompt sections in XML tags.
LLMs are trained on enormous amounts of code, documentation, and markup. XML (and HTML) syntax is deeply embedded in that training data, which means models are very good at recognizing where one tagged section ends and another begins. Unlike plain paragraphs — where the boundary between "here's my context" and "here's my instruction" is fuzzy — a tag creates an unambiguous boundary.
Anthropic actually recommends this explicitly for Claude: wrapping distinct parts of a prompt (instructions, context, examples, output format) in tags like <instructions>
, <context>
, <example>
, and <output_format>
measurably improves consistency, especially in longer or more complex prompts.
Think of it like the difference between handing someone a wall of text versus handing them a form with labeled fields. Both contain the same information, but one is far easier to parse correctly — for a human, and for a model.
Without tags:
Summarize the article below in 3 bullet points. Keep it under 50 words.
Use a neutral tone. Here's an example of the style I want:
"- Company X raised $10M in Series A funding."
Now here's the article: [long article text]
The model has to guess where the instructions end and the article begins — and with a long article, it sometimes starts summarizing the example instead of the real content.
With tags:
<instructions>
Summarize the article in 3 bullet points, under 50 words total.
Use a neutral tone.
</instructions>
<example_style>
- Company X raised $10M in Series A funding.
</example_style>
<article>
[long article text]
</article>
Now there's zero ambiguity. The model knows exactly what's an instruction, what's a style reference, and what's the raw content to work on.
You don't need a formal schema — these are just semantic containers the model can recognize. Some of the most useful:
<instructions>
— the actual task<context>
— background info the model needs but shouldn't act on directly<example>
/ <examples>
— sample inputs/outputs (few-shot prompting)<document>
or <article>
— source text to analyze/transform<output_format>
— exactly how you want the response structured<thinking>
— for models that support step-by-step reasoning before the final answerYou can also nest them, e.g., multiple <document index="1">
, <document index="2">
blocks when feeding several sources at once — attributes work too, and models parse them correctly.
This trick isn't just for input — you can ask the model to return its answer in tags, which makes parsing the response programmatically trivial:
<answer>
Your final response here.
</answer>
<confidence>high</confidence>
If you're building this into an app (say, a Next.js API route calling the AI SDK), this turns a fragile "hope the model formats it right" problem into a simple string-extraction problem — no need for a full JSON schema when you just need one or two fields.
For a single, simple instruction ("Translate this to French"), tags are overkill — they add noise for no benefit. Reach for XML tagging when your prompt has multiple distinct components that could be confused with each other: instructions + context + examples + a document to process, all in one message.
XML tagging isn't a hack — it's closer to good API design applied to prompts. You're giving the model an explicit contract instead of hoping it infers your intent from prose. The next time a prompt feels like it's "almost working," try wrapping its parts in tags before you start rewriting the wording. Often, structure — not phrasing — was the actual problem.