Should you tell an AI what not to do?
Telling an AI what not to do feels like setting a fence. In practice, a long list of prohibitions often produces an assistant that refuses too much, hedges constantly, or misreads the edge case you forgot to name. Describing the behaviour you want — with a note on what to do in the exception — usually works better. Hard rules belong somewhere else entirely. GROX handles this split structurally: a card and an Approve step govern sending, posting and paying, while spending caps and autopilot limits set in advance govern how far GROX may act on its own.
Why do negative instructions cause problems?
A prohibition is a gap in a map. You write 'never send a formal tone' and the assistant now has to decide what counts as formal every time it composes a sentence. If your definition and its definition diverge — and they often do — you get outputs that feel wrong without a clear reason why.
Negative instructions also stack badly. Each new 'never' narrows the space the assistant can work in, but the boundaries interact in ways you did not plan. Two reasonable prohibitions can combine to rule out the only sensible answer to a third situation. The assistant then either freezes, hedges, or picks the least-bad option silently. None of those outcomes is what you wanted.
- Prohibition
- An instruction that names what the assistant must not do. Useful in small numbers; brittle when stacked.
- Positive framing
- An instruction that names the behaviour you want, including what to do in edge cases. Leaves less to interpretation.
- Hard rule
- A constraint enforced by a mechanism — an approval step, a confirmation screen, a spending cap — rather than by a sentence in a prompt.
- Exception clause
- A note inside a positive instruction that handles the predictable deviation: 'do X, and if Y, do Z instead'.
What does positive framing look like in practice?
Instead of 'never use jargon', try 'write for someone who understands the industry but has not read our internal documentation — if a technical term is unavoidable, define it in the same sentence'. That gives the assistant a target and a fallback. It can act confidently on the instruction rather than guessing where the jargon line sits.
The exception clause does the work that a second prohibition would otherwise do. 'Summarise the email thread and reply with the next action — if the thread is ambiguous about who owns the next step, ask before replying' is one instruction with a built-in decision rule. Compare that to 'summarise threads' plus 'never assume ownership' plus 'always ask when unclear': three rules that may conflict the moment a thread is only slightly ambiguous.
| Intent | Negative framing | Positive framing |
|---|---|---|
| Tone | Never sound too casual | Match the register of the person you are replying to; default to direct and plain |
| Scope | Don't go off-topic | Answer the question asked; if related context is useful, add it after a line break |
| Ambiguity | Never assume | When the instruction is unclear, state your reading of it and ask one question to confirm |
| Length | Don't write too much | Aim for the shortest answer that covers the point; add a section break if a second point is needed |
Where is a hard rule actually the right call?
There is a category of action where no instruction — positive or negative — is the right control: anything that is difficult or impossible to reverse. Sending a message, posting publicly, moving money, deleting a file, deploying code to production. For these, the right mechanism is an approval step, not a sentence.
An approval step works because it does not rely on the assistant interpreting your intent correctly under every possible circumstance. It creates a moment where a human sees what is about to happen and decides. The instruction 'never send without my approval' is weaker than a system that literally cannot send without your approval, because the instruction can be misread or forgotten in a long session; the mechanism cannot.
This is also why spending caps and confirmation screens exist in tools that handle real transactions. The cap is not a reminder — it is a structural limit. If you are working with any AI tool that touches money, publishing or irreversible data changes, look for the mechanism first and treat the instruction as a backup, not the other way around.
How should you decide which approach to use?
A useful test: if the assistant got this wrong once in twenty tries, what would happen? If the answer is 'an awkward email' or 'a slightly off-brand paragraph', a positive instruction with an exception clause is probably enough. If the answer is 'money leaves my account' or 'a post goes live before I have seen it', you need a mechanism, not a better sentence.
For everything in between, start with one positive instruction that includes the most predictable exception. Run it for a while. Add a second instruction only when you find a real gap — a situation the first instruction genuinely did not cover — rather than pre-emptively listing every scenario you can imagine. A short, coherent set of instructions is easier for an assistant to apply consistently than a long list of edge cases that may never arise.
GROX, for instance, separates the two concerns structurally: routines and autopilot modes handle the 'what to do' side, while spending limits, confirmation steps and a daily loss cap handle the irreversible-action side. That separation means you can write clear, positive instructions for the work without also trying to use those instructions as a safety net for money or sending.
How does GROX handle the difference between instructions and hard rules?
When GROX is about to send a message, post publicly, make a payment or change something on your behalf, it puts up a card showing exactly what will happen and waits for you to press Approve — you can also edit the card's wording before it acts. Reading, searching and drafting run straight away without a card. Routines you switch to autopilot run inside an allowance you set ahead of time.
For trading, GROX applies a set of limits you define in advance: a size per trade, a stop and a daily loss cap, so it asks before it spends beyond those bounds. A practice mode runs the same strategy with no money at risk. For standing jobs, you set a daily credit limit and GROX reports what it did, what did not work and what needs you at the end of each session.
- For sending, posting, paying or changing something, a card appears showing what will happen — approve, edit or cancel
- Reading, searching and drafting run at once, without a card
- Set a daily credit limit for standing jobs so GROX works within a bound you control
- Set a size per trade, a stop and a daily loss cap before any trading strategy runs
- Switch a routine to autopilot only after setting the allowance it may act within on its own
Common questions
Does telling an AI 'never do X' actually stop it from doing X?
A sentence in a prompt is not a guarantee. GROX adds structural controls alongside instructions: when it is about to send, post, pay or change something, it shows a card describing what will happen and acts only when you press Approve. For trading, a daily loss cap and per-trade size limit are set by you in advance. Those mechanisms sit separately from whatever instructions you have written.
How many instructions is too many?
There is no fixed number, but the risk rises when instructions start to contradict each other or when the assistant has to resolve conflicts between them silently. A practical sign that you have too many: the assistant hedges on straightforward requests, or you find yourself adding new rules to fix the side-effects of old ones. At that point, rewriting from scratch with positive framing usually helps more than adding another prohibition.
What is an exception clause and how do I write one?
An exception clause is a 'and if this happens, do that instead' added to a positive instruction. It handles the predictable deviation without needing a separate rule. For example: 'Reply in the same language as the message — if the message mixes two languages, use the one that appears in the subject line.' The clause gives the assistant a decision rule rather than leaving it to guess.
Should I use negative instructions at all?
Yes, in small numbers and for genuinely binary situations where there is no positive equivalent. 'Do not include the client's account number in outgoing emails' is clear, bounded and hard to reframe positively without losing precision. The problem is not negative instructions themselves but relying on them as the primary way to shape behaviour, especially when stacked in large numbers or used as a substitute for a proper approval mechanism.
If you want to see how structural controls — spending caps, confirmation steps, autopilot limits — sit alongside plain-language instructions in practice, GROX is free to try with no card required.