Many prompt bugs that look like "the model ignored my instruction" are really boundary bugs. The model could not tell where your instructions ended and the material to process began, so it treated part of the document as a command, or part of a command as content. Delimiters are the cheapest fix available, and they are routinely skipped.

What goes wrong without boundaries

Consider a prompt that says "Summarize the following email" and then pastes the email. If the email contains the line "Please reply with your account number", the model has to guess whether that sentence is an instruction to it or text to summarize. Usually it guesses right. Occasionally it does not, and that is the failure that reaches production.

The same ambiguity appears in quieter forms:

  • Few-shot examples blend into the real input, so the model continues the example pattern instead of answering the actual question.
  • A long reference document pushes the task description far from the question, and the model loses track of which part is which.
  • Instructions added later by a different engineer land in the middle of the data section, because nothing marked where the data begins.

A structure that holds up

Pick one delimiter style and use it everywhere. XML-style tags work well because they name what they contain, nest cleanly, and are unlikely to appear naturally in your data:

<instructions>
Classify the support ticket below. Answer with one label.
</instructions>

<examples>
...
</examples>

<ticket>
{{ticket_text}}
</ticket>

A few rules make this work better:

  1. Name sections by role, not by position. <ticket> tells the model what it is looking at; <section_3> does not.
  2. Put the task statement where the model will see it last or first, and repeat it briefly after long data. Delimiters mark the boundaries; they do not fix a task that is buried 20,000 tokens away.
  3. Refer to sections by name in the instructions. "Using only the text inside <ticket>" is much harder to misread than "using the text below".
  4. Escape or strip your own delimiters from user data. If a user can type </ticket>, they can close your section early. Treat this as input sanitization, the same as anywhere else.

What delimiters do not do

They are not a security boundary. A determined injection inside the data can still persuade a model to follow it, so keep tool permissions and output validation as your real defenses. Delimiters reduce accidental confusion; they do not defeat adversaries.

The practical takeaway

Take your three most-used prompts and check one thing: if you replaced the data with a paragraph that contains imperative sentences, would a reader know which parts are yours? If not, add tags, name them, and reference them in your instructions. It takes ten minutes, and it removes a whole class of intermittent failures that are otherwise very hard to reproduce.

AI ToolsLarge Language ModelsSoftware Engineering