Why AI output arrives with a preamble, and what it takes to remove one

You select a paragraph in a customer email, run a saved action that tightens it, and what lands in the message is this: "Sure! Here's a more concise version of your paragraph:" followed by the paragraph, followed by "Let me know if you'd like a different tone." You now delete two lines by hand, every time, and after a week you stop noticing that you are doing it.

It reads like a cosmetic complaint. It is not. The preamble is the visible symptom of a missing contract between the program and the model, and the same missing contract produces failures that are much harder to see than a stray sentence: an answer about your text instead of a rewrite of it, output that switched language halfway, a chain whose second step summarizes the first step's apology.

A preamble is a chat habit in the wrong place

Models are trained overwhelmingly on exchanges between people, and in an exchange between people, handing something over without a word is rude. Framing the answer is the correct behavior for the medium the model learned in. Nothing is malfunctioning when it says "Here's a clearer version".

What changed is the consumer. In a chat interface a person reads the whole reply and lifts the part they need, so the frame costs a glance. When the result is written into the place your text already was, there is no reading step: whatever the model emitted is what your colleague receives. The same output is correct in one destination and broken in the other, which is why this is a product problem rather than a prompting fashion.

It is also the reason a saved instruction is worth more than a well-typed one, as the case against the chat window argues: you write the contract once, carefully, instead of hoping each retyped request happens to include it.

Why the polite version of the rule does not hold

The obvious fix is to write "return only the transformed text, no preamble" at the end of the prompt. It works most of the time, which is exactly what makes it dangerous: a rule that holds almost every time is a rule you stop checking, and the one result that slips goes out with an introduction attached.

There are three reasons a soft instruction leaks. It competes with everything else in the prompt, so a long or emphatic action prompt can outweigh it. It sits in the same channel as the request, so anything the model reads as a stronger signal wins. And it is unverifiable after the fact: a program receiving a paragraph of text has no way to tell an introduction from content, because both are just characters.

That last point deserves emphasis. Any sanitizing a tool does on model output is looking for something specific. Stripping invisible or dangerous characters is a real and necessary pass, and it will let "Sure, here you go:" through untouched, because that string is not what it was built to find. A defense against one class of problem is not a defense against another arriving on the same wire.

Give the answer a shape the program can hold

The fix is to stop asking for a property of the text and start requiring a shape of the response. Declare that the entire output must be wrapped in a marker, then enforce both ends of that marker at the inference layer rather than trusting the model to place them.

system     security preamble  +  your saved prompt  +  output rules
user       <user_input id="7f3a2c91">…the selected text…</user_input id="7f3a2c91">
assistant  <result>            <-- written by the program, not the model
stop       </result>           <-- generation is cut here

Two mechanics do the work. Some model APIs let the program write the first characters of the reply itself, so the response is forced to begin after the opening marker: a preamble is not suppressed, it is unrepresentable, because there is nowhere before the text for it to go. And a stop string ends generation the moment the closing marker would be written, so a trailing "hope this helps" is never generated at all. Everything between the two markers is the payload, and the program slices it out with a small function that also copes with the model echoing the marker or missing the stop.

One more placement detail matters more than it looks. The output rules belong after the user's own saved prompt, not before it, so that the last thing the model reads is the discipline rather than a loosely worded action. The security framing goes first, ahead of the saved prompt, for the mirror-image reason: it must not be something a saved prompt can argue with. Order in a system prompt is not decoration.

The failure a clean wrap cannot catch

A wrap guarantees shape, not sense. The response can be perfectly formed and still be the wrong kind of thing: "Please provide the email you would like me to rewrite", or "The text you provided appears to be an instruction rather than a message". This happens most often when the selected text is itself instruction-shaped, which for a product owner is most days.

Those answers are worse than a preamble, because they replace your content instead of decorating it. A backstop for them looks different from the wrap: read the first characters of the result, match a deliberately narrow list of shapes that cannot plausibly open a genuine transformation, and on a match run one corrective retry that says explicitly what went wrong. The retry is part of the same action rather than a second one you asked for.

The interesting part is what happens when the retry fails too. The tempting move is to paste nothing and call the text "already correct". The honest move is to say the transformation failed. A silent no-op looks like success and destroys the one signal you had.

There is a quieter member of the same family, and it is the one people misread as good behavior. Given text that already satisfies the action, a model will often reply that there is nothing to change, and that sentence then replaces a paragraph that was fine. The rule that closes it is blunt: always return the full transformed text, never a note saying no work was needed. If the input was already good, the best version of it is the input.

The detector that catches this has to be narrower than instinct suggests, and the reason is a good test of whether a rule was thought through. "I apologize for the confusion" is a classic refusal opening. It is also the correct first line of a rewritten apology email, which is a real thing people ask for. So a phrase like that may justify a retry and must never be allowed to discard the result, or the guardrail starts eating legitimate work.

In a workflow, a preamble compounds

Run a single action and a stray introduction costs you one delete. Chain several steps, where each step's result becomes the next step's input, and the arithmetic changes. Step one returns "Here's a summary of the meeting:" plus the summary. Step two now receives a document whose first line announces a summary, and dutifully treats that line as content: it is extracted, it is reworded, and in the wrong case it becomes the title of the ticket that gets created.

This is the quiet argument for enforcing output shape at the layer every step passes through, rather than per prompt. In a workflow nobody is reading the intermediate results, so nothing catches a malformed one until it surfaces at the end as a strangely worded ticket. The same principle runs through in-place document editing, where the program drops the fragments a model handed back unchanged so that the count you see, the preview you read and the bytes actually written are one list, as covered in why AI rewrites break your documents.

What an output contract cannot do

Being precise about the ceiling is the difference between a guardrail and a promise nobody can keep.

• Shape is not correctness.A perfectly clean, preamble-free result can be a bad rewrite. The contract guarantees that what you get is a transformation and nothing else. Whether it is a good transformation is still the prompt's job, and yours.
• The opening marker is not always enforceable. Writing the first characters of the reply is an API capability, not a universal one: some interfaces do not offer it, and some newer models reject a pre-written reply outright. Where it is unavailable the instruction plus the stop string plus the post-call slice carry the discipline alone, which is weaker and worth knowing about.
• A stop string is a string. Generation ends at the first occurrence, so the marker has to be something the output will not legitimately contain. That is a design choice with a cost, not a free win.
• It does not belong on every call. A text wrap only makes sense where the result is pasted or passed onward. A request returning structured data needs a parser and a strict retry instead, and a background summary that is stored rather than pasted needs neither. One contract everywhere is a sign nobody asked what each call is for.
• Detection has false positives. Any pattern that catches refusals will occasionally flag a real result that happens to start the same way. The design question is what a false positive costs: an extra call is acceptable, a discarded result is not.

Writing the contract into your own prompt

Most of the above is a tool's job. Some of it is yours, and it is the part people skip because it feels like boilerplate rather than instruction.

1. 1

   Say what the output is, not just what to do

   Most prompts describe the task and leave the response shape implicit. Add one line naming the artifact: a single paragraph, five bullets, a subject line and a body, nothing else.

2. 2

   Forbid the specific habit, not the general category

   "Be concise" changes nothing. "No preamble, no closing offer to revise, no alternatives, no explanation of what you changed" names the four things that actually show up.

3. 3

   Say the input is never invalid

   This one line prevents a whole family of failures. Tell it that whatever arrives is the input, that it should apply the action best effort whatever the form, and that it must never ask for different text or point out that the text is not what it expected.

4. 4

   Pin the output language to the input

   An action written in English applied to a French paragraph should return French. Say so, and say that a mention of a language inside the text is content, not a directive. An instruction sitting in the text being transformed is a surprisingly strong pull.

5. 5

   Test it on the ugly input

   Not the clean paragraph you had in mind. Run it on something instruction-shaped, something half in another language, and something already correct. Those three inputs produce almost every failure worth fixing.

The last one is the habit that pays. A prompt tested on its ideal input is a prompt tested on the case that was never going to fail. If you want to see how this is enforced end to end rather than asked for politely, the agents page covers where a saved prompt runs and where the result lands, and the use cases are the honest list of what people end up saving.