The problem you don't see in a short prompt
To you it is obvious which part is the instruction and which is the pasted email. The model, however, sees one continuous stream of text. If the boundary is not marked, it has to guess — and sometimes it guesses wrong.
There are three typical symptoms, and all three may be familiar:
- It answers the data. You paste in an email that ends with a question, and the model answers that question instead of summarising it.
- It treats the instruction as content. "At most three paragraphs" turns up in the output as though it were part of the text.
- It takes a sentence in the data as an instruction. This is the dangerous one, and Prompt Injection covers it separately.
Three ways to mark boundaries
Headings. Simple, readable, quick: TASK:, MATERIAL:, FORMAT:. Perfect for a short prompt. Where it fails: when the pasted material also contains a line that looks like a heading.
Separator lines. --- or === between blocks. Better than nothing, but it does not say what is in the block, only that something different follows.
Tags. <material> … </material> — the most reliable option, and the one the providers' guides recommend. There are two reasons: the opening and closing marks unambiguously enclose the content, and the tag name also says what it is. On top of that, the model trained on huge quantities of text structured this way, so the form is familiar to it.
It does not have to be valid XML, and you do not need to name any standard. It just has to be consistent.
How to name your sections
Four simple rules:
- Descriptive names.
<contract>beats<data1>. The model works from the name too. - Consistently. If it is
<material>once, keep it<material>— don't switch to<text>. - Things that belong together go under one tag. With several documents, give each its own, plus the source: which file, which date. That is what lets you ask for citations.
- Keep the instruction outside. What the model has to do should not sit inside the
<material>block — otherwise it may take that for part of the material too.
A skeleton that works for long prompts
<task>
Summarise the parts of the contract dealing with termination.
</task>
<contract source="framework-agreement-2026.pdf">
[the text of the contract]
</contract>
<format>
Bullet points, one sentence each.
For every point, state which clause you based it on.
Anything not in the contract, do not invent — say it makes no provision for it.
</format>
Note the order: task first, material in the middle, format and constraints last. There is a practical reason for this. In a very long text the model uses information sitting in the middle less reliably than information at the beginning or end — that is the subject of Tokens and the Context Window. So the most important instruction should come after the material, not before it.
When you hand over several documents
Here marking is not a convenience but a precondition. Without it the model blurs the sources together and you cannot trace where a claim came from.
<documents>
<document id="1" source="quote-2026-03.pdf">…</document>
<document id="2" source="email-2026-04-12.txt">…</document>
</documents>
If the material will not fit in one go, Long Documents in Chunks shows what comes next. From here you can also ask for things like "for every claim, state the document id". This is one of the strongest checking tools available in prompting — and one of the five methods against hallucination worth knowing.
What not to do
Do not use a marker that could occur in the material. If you are asking about code or HTML, a <code> tag is ambiguous. Pick something more conspicuous — for example #####CODE-START#####.
Do not over-mark. Five sections are readable; twenty are not. If you need that many, it usually means the task should be split in two.
Do not make marking do the format's job. A tag says what something is — not what the answer should look like. That is still a separate sentence.
What to take away
As soon as a prompt contains both instruction and data, mark the boundary — with descriptive, consistent tags. Instruction first, material in the middle, format and constraints last. Those three steps prevent most long-prompt errors, and they cost nothing.