Structure and Format

When a prompt contains more than one kind of thing — an instruction and a document, or a task and examples and data — the model can lose track of which part is which. It might treat a sentence inside your pasted document as an instruction, or answer the wrong question. The fix is to label the parts.

Summarize the document below for a non-technical reader.

<document>
{the full document text goes here}
</document>

Write the summary in 3 bullet points.

The tags (<document>…</document>) draw a hard line between what to do and what to do it to. The model no longer has to guess where the data starts and the instructions resume.

Why tags, specifically

Anthropic’s models are particularly responsive to XML-style tags — <document>, <example>, <instructions>, <data> — because they were trained on a lot of text structured that way. The tag name is yours to choose; what matters is that each distinct part of the prompt is wrapped and labeled.

This solves three real problems:

• Injection confusion. If your pasted data contains something that looks like a command (“ignore the above and…”), tags keep it quarantined as data, not instruction.
• Reference clarity. You can now point at parts by name: “using only the facts in <document>, answer the question in <question>.”
• Multi-part prompts. Role, examples, data, and task each get their own labeled block, so a long prompt stays legible to the model and to you.

<role>You are a contracts analyst.</role>

<examples>
{two example contract summaries}
</examples>

<contract>
{the contract to summarize}
</contract>

<task>
Summarize the contract above in the same format as the examples.
Flag any clause that differs from standard terms.
</task>

See it in action

The same request, with and without structure:

Both work, but the second is tighter: the instruction lives outside the tags, the data lives inside, and the injection attempt is neutralized because the model knows the tagged region is data.

Controlling the output shape

Tags handle the input side. The output side is about telling the model the exact shape you want — and being specific enough that there’s no room to drift.

Vague: “give me the results in a nice format.” Precise:

Output a markdown table with exactly these columns, in this order:
Risk | Likelihood (Low/Med/High) | Impact (Low/Med/High) | Mitigation.
No prose before or after the table.

“No prose before or after” matters more than people expect — models love to add a friendly intro and a summary. If you’re going to paste the output somewhere or parse it, say what you do not want around it.

Prefilling: speak the first words for the model

You can also steer the format by putting words in the model’s mouth — starting its response for it so it must continue from there. This is prefilling.

If you prefill the assistant’s reply with { , the model continues with JSON instead of “Sure! Here’s the JSON:”. Prefill with <summary> and it picks up inside that tag. It’s a precise way to skip preambles and lock the opening format.

Key takeaways

• Label the parts. Wrap data, examples, and instructions in named tags (<document>, <examples>) so the model never confuses input with instruction.
• Tags neutralize injection by marking a region as data — valuable for anything that handles untrusted input.
• Specify output shape precisely, including what you don’t want around it (“no prose before or after”). Match the format to whoever — or whatever — consumes it.
• Prefilling forces a starting format but is an API/browser-chat technique; in a CLI, ask explicitly for the opening instead.

Next: Ground the Answer