XML Tags, Roles & Long-Context Structure

Why structure matters: instructions vs data

A prompt usually mixes several kinds of content: your instructions, background context, and the actual data to process. In an unstructured prompt these blur together — and the failure mode is nasty: Claude treats part of your data as an instruction (a pasted email that says "ignore the above" gets obeyed) or part of your instructions as data (your formatting rules end up quoted in the output).

The fix is wrapping each distinct content type in XML tags — angle-bracket markers like <instructions> and <input>. Claude is specifically trained to respect these as structure. Three habits make them work:

• Descriptive names: <contract>, <user_email>, <style_guide> — the tag name itself is context.
• Consistency: use the same tag names throughout a prompt, and refer to them by name ("using the rules in <style_guide>...").
• Nesting: tags can contain tags, mirroring the natural hierarchy of your content.

<instructions>
Classify the sentiment of the review in <review> as positive,
negative, or mixed. Output only the label.
</instructions>

<review>
The battery life is incredible, but the screen scratched in a week.
</review>

Now "ignore previous instructions" inside the review is just review text. The boundary is explicit.

Roles: one sentence of framing

The system prompt sets who Claude is for the conversation, and even a single sentence shifts behavior and tone measurably: "You are a senior security engineer reviewing code for vulnerabilities" produces different attention — different priorities, different vocabulary — than no role at all. Set a role whenever the task has a natural expert persona; skip elaborate character sheets, which add tokens without adding steering.

Related: system prompts should sit in a "Goldilocks zone" of specificity. Too rigid — hardcoded if-else logic for every case — breaks on inputs you didn't anticipate. Too vague — "be helpful and accurate" — steers nothing. Aim for specific heuristics: clear enough to guide decisions, flexible enough to generalize.

Long context: documents first, question last

When your prompt includes long material (roughly 20k+ tokens — full documents, transcripts, large code files), placement becomes a first-order variable. The rule: put the long documents at the top of the prompt and your query at the end. Placing the query after the documents improves response quality by up to 30% on multi-document tasks.

Why it works: with the question last, everything the model just read is still "in focus" when it starts answering, and the question directly primes what to retrieve. With the question first, the model reads thousands of tokens of document while trying to hold your instructions in mind the whole way.

Wrap each document in structured tags with metadata:

<documents>
  <document>
    <source>services-agreement-2025.pdf</source>
    <document_content>
    ...full text...
    </document_content>
  </document>
  <document>
    <source>msa-vendor-b.pdf</source>
    <document_content>
    ...full text...
    </document_content>
  </document>
</documents>

Which agreement exposes us to less liability? Answer in
<recommendation> tags with specific clause references.

The <source> tag pays off doubly: Claude can cite documents by name, and you can trace claims back.

Grounding in quotes: the anti-hallucination step

For question-answering over long documents, add an intermediate step: ask Claude to first extract the relevant quotes, then answer using only them.

First, find the quotes from the documents most relevant to the
question and print them inside <quotes> tags. Then answer the
question inside <answer> tags, based on those quotes.

This works because it forces retrieval before generation. The model must locate actual supporting text — and an answer with no quotes behind it becomes visibly suspect. Quote grounding focuses attention and cuts hallucination on document tasks, and the quotes double as citations you can verify in seconds.

Putting it together

A well-structured long-context prompt reads in this order:

1. System prompt: role plus durable heuristics.
2. Documents: at the top of the user message, each in <document> tags with a <source>.
3. Instructions: what to do, referencing tags by name.
4. Output format: the tags or structure the answer should use.
5. Query: the actual question, last.

None of these pieces is exotic on its own. Together they turn "here's a wall of text, please answer" into a prompt where the model knows what's data, what's instruction, where to look, and what shape the answer takes — which is most of what separates flaky long-context behavior from reliable behavior.