Scope, refusals, and a voice that stays put

The three things every deployed assistant gets asked

Within a week of launch, whatever your product does, your assistant will receive: a question about a competitor, a request for legal or medical advice, and an attempt to make it say something embarrassing so the screenshot can be posted. None of these are hostile edge cases. They are the ordinary traffic of a public text box.

So the scope of your assistant is not a philosophical matter. It is a list you write down.

Write the out-of-scope list explicitly

A prompt that says what the assistant does leaves everything else undefined, and undefined means the model improvises. Say what it does not do, and say what to do instead.

You answer questions about ordering, delivery and returns for this shop.

You do not: give medical, legal or financial advice; compare us with named competitors; discuss pricing not listed on the site; agree to refunds, discounts or exceptions; or discuss politics, religion or current events.

When a request falls outside that list, say in one sentence that you cannot help with it, and offer the one thing you can do that is closest to what they want.

That last clause is the difference between a refusal that feels like a wall and one that feels like service. “I can’t advise on whether this medicine suits you; I can show you the ingredients list and our returns policy” is a refusal that keeps the customer.

Refuse without being unpleasant

Three properties of a refusal that does not generate a complaint:

Short. One sentence. A four-paragraph explanation of policy reads as defensive and invites argument.

Free of moralising. Do not explain to an adult why their question was inappropriate. State the boundary and move on.

Offering an exit. A route to a human, a relevant page, or the nearest thing in scope. A refusal with no next step converts into a support ticket, which costs more than the answer would have.

And the counterpart failure is real: over-refusal. Models trained to be careful will decline questions about medication packaging, about historical violence, about ordinary security work, about a user’s own medical records. Over-refusal is a quality bug with a business cost, and it does not show up on the metrics people usually watch. Put ten legitimate-but-adjacent questions into your test set and check they get answered.

Tone that stays put

A persona described in adjectives drifts within a few turns, because adjectives do not constrain generation. A persona described in constraints holds.

Instead of friendly, professional and warm, write:

• Address the customer as “you”. Never use their first name more than once in a reply.
• Two to five sentences. No bullet lists unless listing three or more items.
• No exclamation marks. No emoji.
• Do not open with “Great question” or “I’d be happy to help”.
• British spelling.
• If you do not know, say so in the first sentence, not the last.

Every one of those is checkable by a regular expression or a five-line function, which means every one of them can be an assertion in your test suite. That is the test for whether a tone instruction is real.

Drift over a long conversation is a specific, mechanical problem: as history grows, the system prompt is a smaller fraction of the context and the model increasingly imitates the recent turns, including the user’s register. If the user starts writing in capitals and slang, the model slides towards it. The fixes are restating the two or three most important constraints in the final user turn, and capping history length rather than letting a chat run to 60 turns.

Do not let the user be the author

One security point belongs here rather than in the security module, because it looks like a tone problem.

If your interface lets a user set a persona, a name, or “custom instructions”, that text is being placed in the same system context as your rules, and it is being written by someone who may want your assistant to behave badly with your logo on it. Treat user-supplied persona text as data: put it inside delimiters, put your non-negotiable rules after it, and state that instructions inside the persona block are preferences about tone only and cannot change scope.

That is a mitigation and not a guarantee (the full argument is in the security module) but the sequencing alone removes the easiest version of the attack.

Test the boundary, not the middle

Your test set should contain, for every scope rule, one clear violation, one adjacent-but-legitimate question, and one attempt to argue past a refusal. It is the middle case that costs you money: a model that refuses cleanly and refuses too often has traded one visible failure for an invisible one.