A short prompt doesn't need structure. But production prompts are rarely short: a typical enterprise request bundles a role, behavior rules, one or more reference documents, a few worked examples, and the actual user input — often thousands of tokens of mixed material. Without clear boundaries, instructions bleed into data ("was that sentence a rule, or part of the contract I'm supposed to analyze?"). Anthropic's answer, stated plainly in its prompting best practices, is XML-style tags: wrap instructions, context, and inputs in their own consistent, descriptive tags.
How it works
XML tags here are just labeled brackets in plain text — <instructions>...</instructions>, <contract>...</contract>, <user_question>...</user_question>. There is no schema to register and no fixed vocabulary; Claude has simply been trained to treat tagged spans as coherent, separable units. Three habits make tags effective:
- Descriptive names.
<shipping_policy>beats<doc1>. The tag name itself is context Claude uses. - Consistency. Use the same tag names throughout a prompt and refer to them by name in your instructions: "Answer using only the information in
<shipping_policy>." - Nesting for hierarchy. Tags can contain tags — the official guidance explicitly recommends nesting for hierarchical content, such as several
<example>blocks inside one<examples>wrapper.
The patterns worth memorizing
Examples. Few-shot demonstrations go in <example> tags inside <examples> — this is the exact convention the official docs use, and it keeps demonstrations from being confused with live input. Details in teaching by demonstration.
Multiple documents. For long-context work, the documented pattern wraps each document in a <document> tag containing <document_content> and <source> subtags, so Claude can attribute claims to the right file. And for inputs beyond roughly 20,000 tokens, put the longform data at the top of the prompt, with your query and instructions after it — per Anthropic's docs, placing the query at the end can improve response quality by up to 30% on long-context tasks. More in context placement.
Separating untrusted input. Wrapping user-supplied text in its own tag (<user_input>) and instructing Claude to treat its contents as data, not commands, is a useful hygiene layer against instruction-injection attempts — not a complete defense, but a meaningful one. See prompt injection basics.
A worked skeleton
Here's the shape of a well-structured analysis prompt, sent through Amazon Bedrock's current Messages surface (the structure is identical on every platform):
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
prompt = f"""<contract>{contract_text}</contract>
<instructions>
Using only <contract>, list every clause that mentions
termination. Quote each clause, then explain it in one
plain-English sentence.
</instructions>"""
resp = client.messages.create(
model="anthropic.claude-sonnet-5",
max_tokens=2048,
messages=[{"role": "user", "content": prompt}],
)Note the order: document first, instructions after — the long-context pattern. If this prompt also carried examples, they'd sit in <examples> between the document and the instructions, and the static parts would be positioned for prompt caching.
What tags are not
Tags organize the prompt; they don't validate the output. If you need Claude's response in a machine-parseable format, ask it to answer inside named tags for light structure, or use structured outputs when you need guaranteed schema-valid JSON. And tags are not a security boundary — they help Claude keep roles straight, but server-side validation of anything consequential remains your job.
Where to go next
XML structure is the backbone of system prompt design and reusable templates; the quickstart covers first calls on each platform.