Write a Prompt That Stops Drifting After Three Uses

Your prompt worked on Monday and quit on Thursday

This is one of the most common things people bring us, and it usually sounds like an apology. The prompt worked. Then it stopped working. Same tool, same person, same task, and now the output is too long, or it invented a discount that does not exist, or it dropped the sign-off you asked for.

You are not doing it wrong. What you wrote was a reasonable set of instructions. The problem is that most prompts are written as one paragraph of hope, and a paragraph of hope holds up fine until the input changes shape.

That is what drift is. Not the model getting worse. The input getting weirder while your instructions stayed the same.

Why the order of your prompt matters

Here is the part that surprises people. You can keep every word of your prompt and just change where the words sit, and the output gets steadier.

Most of us write instructions the way we talk. We front-load everything. Role, task, tone, length, rules, do not do this, do not do that, and then at the very end we paste in the messy customer email. So the last thing the model reads is the mess. In our own testing, whatever comes last carries more weight, which means the mess is what it takes its cues from.

The constraint sandwich fixes the order. Instructions on top. Input in the middle, clearly fenced. Constraints again on the bottom. The rules are the last thing read, so the rules are what stick.

Building one, step by step

Take a task you already do with AI a few times a week. Reply to an inbound quote request, turn a voicemail transcript into a service note, summarize a vendor email for your bookkeeper. Pick one. Then build it in this order.

1. Write the top slice. Two sentences at most. Who the assistant is and what job it is doing. For example: You are drafting a reply to an inbound quote request for a small commercial cleaning company. Your job is to acknowledge the request and ask for the three missing details.
2. Fence the input. Put the words BEGIN INPUT on its own line, paste the raw material, then put END INPUT on its own line. This one habit stops the model from reading a customer's stray instruction as your instruction.
3. Write the bottom slice. This is where the real work goes. Output format, length limit, tone, and the specific things it is not allowed to do. Be concrete. Under 120 words. No pricing. No timelines. End with the line Thanks, and then the sender name.
4. Add a fallback. One line telling it what to do when the input is incomplete: If a required detail is missing, write MISSING and the name of the detail instead of guessing. This single line prevents most invented facts.
5. Restate the one rule you care about most. Last line of the prompt. If your biggest fear is that it quotes a price, then the last line is Do not include any prices.

That is the whole pattern. Instructions, fenced input, constraints, fallback, the one rule again.

Test it with your worst inputs, not your best ones

Most people test a new prompt on a clean example. Then they roll it out and the first real input is a forwarded email chain with three replies and a photo caption.

So do it backwards. Go find five of the ugliest real examples of that input you have. The rambling one. The two-line one with no detail. The one where the customer asked a question you cannot answer. Run all five.

You are not looking for good output. You are looking for the specific way it fails. Every failure becomes one new line in the bottom slice. Imagine you run five ugly voicemail transcripts and three of them come back with a made-up callback time. That is not five problems. That is one line: Do not state a callback time unless the transcript says one.

Keep the bottom slice under about ten lines. When it gets longer than that, you do not have a prompt problem anymore. You have a process that is trying to do two jobs at once, and it should be split into two prompts.

The prompt is a draft machine, not a decision machine

A constraint sandwich makes output more predictable. It does not make output correct. Someone on your team still reads every draft before it goes to a customer, a vendor, or a file that matters. That review is not a temporary phase you graduate out of. It is the design.

And the prompt by itself is only part of what we are talking about. A good prompt sitting in someone's chat history is not a workflow. The workflow is where the input comes from, who runs it, where the output goes, and who checks it. What we do is we take the guesswork out of that part, because that is the part that actually holds.

Do one, not twelve

I want to talk you out of the obvious next move. Do not go build a library of forty prompts this month. Do not buy a prompt pack. Do not sign up for a platform to manage prompts you have not written yet.

Rewrite one prompt this week using the sandwich. Test it on five ugly inputs. Save it somewhere a second person can find it, which for most teams means a shared doc, not a private chat. Then use it for two weeks before you touch anything else.

One prompt that holds is worth more than a folder of prompts nobody trusts. Tommy and I have never once seen a team regret starting small here.