Structuring prompts with XML, roles, and sections

Once your prompt grows past a short instruction — once it mixes context, examples, input data, and instructions — plain prose stops cutting it. The model has to parse where one thing ends and the next begins, and it sometimes guesses wrong.

The fix is structure. The patterns below work across every major model.

When to start structuring

Short prompts don't need structure. "Write a haiku about morning coffee" doesn't need XML tags. Once any of these are true, structure earns its keep:

• Your prompt is more than ~200 words
• You're mixing instructions with pasted content (a document, a transcript, a code snippet)
• You have more than one type of input
• You're using examples
• The output quality matters enough that you'd run it twice if it failed

XML tags: the simplest tool that works

Wrapping content in named tags makes it unambiguous which part of the prompt is what. The model handles this much better than relying on punctuation, blank lines, or "Above is the document, below is the question."

Less effective:

Here is a customer support ticket:

The user says their password reset link is expiring before they can use it.
They're on mobile and traveling.

Please draft a response.

More effective:

<ticket>
The user says their password reset link is expiring before they can use it.
They're on mobile and traveling.
</ticket>

<instructions>
Draft a response. Match the tone of the examples below.
Acknowledge the friction. Don't apologize twice. End with one concrete next step.
</instructions>

The tag names don't have to be standardized — any consistent name works. What matters is the structure.

When XML tags actually pay off

• Inputs you didn't write. When you paste a document, transcript, or code snippet, tag it. Otherwise the model can get confused about where the input ends and your instructions begin.
• Multiple documents. Wrap each in <document> with <source> and <content> subtags. The model can reference them clearly ("according to document 3...").
• Examples. Wrap each in <example> and the group in <examples>. The model treats them as patterns to learn from, not instructions to follow literally.
• Long prompts. As a prompt grows, structure prevents the model from collapsing it into one undifferentiated blob.

The role assignment: a 1-sentence quality upgrade

A single sentence at the top of your prompt that tells the model who it is changes the entire output. Vocabulary, depth of explanation, what it skips, what it emphasizes — all shift.

You are a senior security engineer reviewing code for OWASP Top 10 vulnerabilities.

You are an editor at The Atlantic. You value precision over cleverness, brevity over comprehensiveness, and concrete examples over abstract claims.

You are a technical product manager translating an engineering doc into something a non-technical executive will read in 90 seconds.

Each of these prompts can be the entire system prompt. The model fills in everything else.

A few rules:

• Be specific. "A helpful assistant" tells the model nothing. "A senior backend engineer specializing in distributed systems" tells it a lot.
• State the values, not just the title. "An editor who values concrete examples over abstract claims" beats "an editor."
• Match the role to the task. Don't ask a "senior security engineer" to write marketing copy — the role assignment will fight the request.

The hierarchy of a long prompt

When your prompt grows past a few hundred words, the order matters. The pattern that works:

1. Role — 1 sentence, who the model is
2. Context — what the user / company / situation is
3. Input data — the document, transcript, code, etc., wrapped in tags
4. Examples — if you have any, wrapped in <examples> tags
5. Instructions — what to actually do, including format constraints
6. The specific request — the one question or action, at the very end

Why this order? Models have been shown to retrieve information better when the question or instruction comes at the end — after the context they need to reason about. For very long inputs (20k+ tokens), this matters a lot — putting the question first can drop output quality meaningfully.

Example structure:

You are a senior backend engineer reviewing a service migration plan.

<context>
We're migrating our auth service from PostgreSQL to DynamoDB.
The team is mid-sized (8 engineers), running on AWS, no prior DynamoDB experience.
</context>

<migration_plan>
{the actual migration plan, pasted or referenced}
</migration_plan>

<examples_of_good_reviews>
<example>
{a past review that's the right tone and depth}
</example>
</examples_of_good_reviews>

Review the plan. Cover:
- What's likely to bite the team given their stated experience level
- Anything in the plan that's missing
- Anything in the plan that's over-engineered for their size

End with a "recommended next step" — one concrete action.

Be honest. Don't hedge to seem balanced.

Notice the request comes at the end, after all the context. The model has everything it needs before being asked to do anything.

Anti-patterns

• Tag inflation. Don't wrap every paragraph in its own tag. Use tags where the boundary actually matters.
• Tag inconsistency. If you use <input> once and <user_input> later, the model might treat them as different things.
• Role + instruction conflict. "You are a brutally honest critic. Be encouraging and supportive." Pick one.
• Burying the instruction. If your actual question is in paragraph 4, the model might miss it. Put it at the end and make it obvious.

When to ignore all of this

Short prompts. Casual prompts. Throwaway prompts. The patterns above are overhead — they're worth it when output quality matters or when you're going to reuse the prompt. For a one-off "what does this acronym stand for," skip the ceremony.

What to read next

• What makes a prompt actually work — the foundations
• Few-shot examples: when they help, how to write them — the deep dive on the examples pattern referenced above