Why does my AI agent ignore a NEVER rule in its system prompt?

Often because another line asks for the same action, wrapped in a softener like make sure to or remember to. The wrapper becomes the verb of that line, so nothing reads the two lines as a pair and nobody is told they disagree. The model sees both and picks one per conversation. Rewrite every wrapped rule as a modal plus the real verb and the conflict shows up as a logic/contradiction the build refuses.

Does make sure to make an instruction stronger in a prompt?

It adds urgency to the sentence, not force to the rule. In TypeGlish the line reads as an instruction to make sure, with the real action pushed into the object, so the checker cannot compare it with any other rule about that action. If a rule matters, write MUST or NEVER and put the action verb straight after it.

How do I find hidden contradictions in an agent prompt?

Strip the wrappers first. Rewrite each line that starts with make sure, remember, ensure you, don't forget, be sure or try to as a modal followed by the action verb, then run typeglish check. Pairs that were invisible while one side said remember to ask surface as logic/contradiction errors once both sides say ask.

Is it bad to write please or don't forget in a system prompt?

Politeness costs little on its own, but these openers change how the line parses. In typeglish 0.11.0, a line starting with Please ask or Don't forget to is not read as a rule at all and is reported as prompt/unparsed-rule, so it earns no enforceability credit and no proof. Keep the courtesy in the persona and start each rule with its modal.

← Tidelines/Deep divesOct 14, 2026

Remember to ask is a rule about remembering

Support prompts are full of gentle openers: make sure to, remember to, don’t forget to, ensure you. They read as emphasis. To anything that parses the line, they are the verb, and the action you meant gets pushed down into the object where no other rule can reach it.

by TypeGlish team7 min read#deep-dives

The verb is the first word.

TL;DR A rule written as make sure to ask for the policy number is about making sure, not about asking, so it can sit beside NEVER ask for the policy number and check clean; write every rule as a modal followed by the real action verb, and the hidden contradiction becomes a blocking error you have to resolve.

Bramble Home Insurance runs a claims assistant called Juno in its app and on its website. The prompt started as a list of reminders from the claims team, written the way people write notes to a new starter. Months later the app began passing the customer’s policy in with every chat, and product added one line at the bottom so Juno would stop asking signed-in customers for a number the system already had. Customers in the app still get asked for their policy number. Not every time. Often enough to show up in the complaints.

§1The prompt that checks clean

claims-before.tg - the reminders, plus the new line✓ 0 error

# Role
You are Juno, the claims assistant for Bramble Home Insurance.

# Constraints
- Make sure to ask for the policy number.
- Remember to confirm the customer's incident date.
- Don't forget to mention the policy excess.
- Be sure to give the customer a claim reference.
- Ensure you keep every reply to at most 3 sentences.
- NEVER ask for the policy number.

Line 5 and line 10 are a direct contradiction to any human who reads them side by side. Nobody read them side by side: they were written a year apart, by different teams.

tg check and score - claims-before.tg✓ B (80/100)

$ typeglish check claims-before.tg
claims-before.tg:7:1  info   prompt/unparsed-rule  Reads like a rule, but the rule reader cannot parse it as one, so it earns no Enforceability credit and no measurability check: no modal (MUST / NEVER / SHOULD) and "Don't" is not a verb the checker knows, so it reads as prose. Fix: lead with a modal, or start with a verb from the catalog (Escalate …, Ask …).
claims-before.tg:8:1  warn   prompt/unmeasurable  Unmeasurable rule — "be <quality>" names no observable action, so nothing can check compliance. Name a concrete action, or move it to a prose block (persona prose is allowed to be soft).

✓ 1 file — 0 error, 1 warning, 1 info

$ typeglish score claims-before.tg
claims-before.tg — B (80/100)  proven errors: none  tiers: base+z3
  planes  runtime 89 (what the model reads) · hygiene 50 (source only)
  facets  enforceability 79 x.21 · hardness 100 x.12 · directness 100 x.08 · consistency 100 x.17 · structure 100 x.12 (hygiene) · annotation 0 x.12 (hygiene) · style 57 x.08 · security 100 x.08
  rules   4 of 6 rule-shaped lines read · 1 unmeasurable

Consistency is 100 and the proof tier found nothing. The two findings are about lines 7 and 8. Lines 5 and 10, the pair that is actually hurting customers, get no comment at all.

This is not the checker missing a contradiction it should have caught. It is the checker reading the file exactly as written, and the file does not say what its authors think it says.

§2Read the verb, not the sentence

A rule has a head: the action it obligates or forbids. In NEVER ask for the policy number, the head is ask. In Make sure to ask for the policy number, the head is make sure, and to ask for the policy number is what you are making sure of. The real action has moved down a level into the object. The checker’s own one-line summary of each statement shows where it put things:

typeglish statements - claims-before.tg (excerpt)

$ typeglish statements claims-before.tg
  - Make sure to ask for the policy number.
  Asks Juno to make sure to ask for the policy number.

  - Remember to confirm the customer's incident date.
  Asks Juno to remember to confirm the customer's incident date.

  - Don't forget to mention the policy excess.
  Gives Juno this instruction: “Don't forget to mention the policy excess.”.

  - Ensure you keep every reply to at most 3 sentences.
  Requires Juno to you keep every reply to at most 3 sentences.

  - NEVER ask for the policy number.
  Requires Juno not to ask for the policy number.

Excerpt: the statement IDs and token lines are trimmed, the summaries are verbatim. Line 5 is a request to make sure. Line 10 is a prohibition on asking. Different actions, so there is nothing to compare.

Take the wrapper off and say the same thing directly, and the pair becomes the thing everyone assumed it was:

claims-direct.tg - the same rules, verb first✗ logic/contradiction

# Role
You are Juno, the claims assistant for Bramble Home Insurance.

# Constraints
- MUST ask for the policy number.
- MUST confirm the customer's incident date.
- MUST mention the policy excess.
- MUST give the customer a claim reference.
- MUST keep every reply to at most 3 sentences.
- NEVER ask for the policy number.

tg check and build - claims-direct.tg✗ build refused

$ typeglish check claims-direct.tg
claims-direct.tg:5:1  error  logic/contradiction  Conflicts with line 10. Logical conflict — "ask for the policy number" is both required and forbidden. Keep one, or scope the two rules so they cannot both apply (IF <condition> THEN ...).
                  ↳ line 10: - NEVER ask for the policy number.
claims-direct.tg:10:1  error  logic/contradiction  Conflicts with line 5. Logical conflict — "ask for the policy number" is both required and forbidden. Keep one, or scope the two rules so they cannot both apply (IF <condition> THEN ...).
                  ↳ line 5: - MUST ask for the policy number.

✗ 1 file — 2 error, 0 warning, 0 info

$ typeglish build claims-direct.tg
typeglish build: claims-direct.tg refused — nothing written

Same intent, one word changed per line, and the file can no longer ship. That is the outcome you want: the decision product and the claims team never made together is now a red build instead of a coin flip in production.

A softener does not make a rule stronger. It makes it about something else.

The model is not running a parser, and it will usually understand that make sure to ask means ask. That is the trouble. It understands both lines, it has no instruction about which one wins, and it settles the tie fresh in each chat, which is the pattern Your prompt argues with itself describes. The wrapper does not confuse the model. It hides the conflict from everyone who could have resolved it before the model had to.

§3Which openers hide the verb

We put each common opener in front of ask for the policy number, one at a time, in a file that already said NEVER ask for the policy number, and ran typeglish check (version 0.11.0) on each. They sort into four groups.

The checker sees the action, and the conflict is proven. MUST ask, the bare imperative Ask for the policy number, You ask, and You need to ask. Each one fails with logic/contradiction on both lines.
The line checks clean, and the conflict disappears. Make sure to, Make sure you, Always make sure to, Remember to, Always remember to, MUST remember to, Ensure you, ENSURE to, It is important to, and Your job is to. No error, no warning, no info line. These are the dangerous ones, because nothing suggests anything is wrong.
The line is not read as a rule. Don’t forget to, Please ask and You will ask come back as prompt/unparsed-rule. Try to adds prompt/hedging on top. At least these say something.
The line reads as a quality, not an action. Be sure to parses as be <quality> and earns prompt/unmeasurable.

Two of those deserve a second look. MUST remember to ask has the strongest modal in the language and still hides the conflict, because the modal binds to remember. And ENSURE is itself a binding modal in TypeGlish, yet Ensure you ask checks clean too: the checker’s summary of the claims prompt’s own Ensure you keep every reply… line reads Requires Juno to you keep every reply, with the stray you still sitting in the object. A capital-letter modal is not a guarantee. The word straight after it is what decides what the rule is about.

This is a close relative of the problem in Advice is a verb, where a prohibition only covers the exact verb it names. There the two rules chose different verbs for one action. Here they choose the same verb, and one of them hides it behind a reminder.

§4Write the verb, then make the decision

The rewrite is mechanical for most lines: delete the opener, put a modal in front of the action, done. Be sure to give the customer a claim reference becomes MUST give the customer a claim reference. The policy-number pair is different, because stripping the wrappers does not fix it. It exposes a question nobody answered: should Juno ask for the policy number or not?

The answer is both, depending on where the chat happens. In the app the policy arrives with the session; on the website there is no session. That is a fact the platform knows before the conversation starts, so it belongs in a typed input and a compile-time branch, not in a rule the model has to apply by guessing who is signed in. How to turn parts of your system prompt on and off covers the mechanics.

claims.tg - verbs first, the decision made✓ A (100/100)

$REQUIRE variable signed_in: boolean

# Role
@@ role: one sentence names the speaker, so every later "you" is Juno
You are Juno, the claims assistant for Bramble Home Insurance.

# Constraints
@@ policy_lookup: the app passes the policy in for signed-in customers; the website chat has no session
$IF @{signed_in}:
  - NEVER ask for the policy number.
$ELSE:
  - MUST ask for the policy number.
@@ incident_date: the date decides which policy year the claim falls in
- MUST confirm the customer's incident date.
@@ excess: customers who learn the excess late call back angry
- MUST mention the policy excess.
@@ reference: the customer quotes the reference on every follow-up
- MUST give the customer a claim reference.
@@ brevity: three sentences keeps a claims chat readable on a phone
- MUST keep every reply to at most 3 sentences.

$TEST new_claim
  - input:: A pipe burst under my kitchen sink last night and the floor is soaked.
  - expect::
    - confirms the customer's incident date
    - mentions the policy excess
    - gives the customer a claim reference
    - at most 3 sentences

Every rule leads with a modal and the action. The two policy-number rules now live in separate arms of one chain, so the compiler keeps exactly one of them per build. The @@ notes carry the reasons the old reminders were trying to convey with tone.

tg check, score, test --dry and build - claims.tg✓ two builds, one source

$ typeglish check claims.tg
✓ 1 file — 0 error, 0 warning, 0 info

$ typeglish score claims.tg
claims.tg — A (100/100)  proven errors: none  tiers: base+z3
  planes  runtime 100 (what the model reads) · hygiene 100 (source only)
  facets  enforceability 100 x.21 · hardness 100 x.12 · directness 100 x.08 · consistency 100 x.17 · structure 100 x.12 (hygiene) · annotation 100 x.12 (hygiene) · style 100 x.08 · security 100 x.08
  rules   6 of 6 rule-shaped lines read · 4/6 covered by $TEST

$ typeglish test claims.tg --dry
✓ claims.tg  coverage: 4/6 rules exercised
  uncovered (no case shares the rule's wording):
    L10  ask for the policy number.
    L12  ask for the policy number.
  · new_claim — "A pipe burst under my kitchen sink last night and the floor " (not run)
      ✓ at most 3 sentences
      · rubric — 3 prose expectations, judged on a live run (needs ANTHROPIC_API_KEY)
✓ 1 prompt — 0 failed

$ typeglish build claims.tg --vars '{"signed_in":true}'
✓ built .typeglish/dist/claims.txt ← claims.tg (d9d859c0d663, full)

$ cat .typeglish/dist/claims.txt
# Role
You are Juno, the claims assistant for Bramble Home Insurance.

# Constraints
- NEVER ask for the policy number.
- MUST confirm the customer's incident date.
- MUST mention the policy excess.
- MUST give the customer a claim reference.
- MUST keep every reply to at most 3 sentences.

$ typeglish build claims.tg --vars '{"signed_in":false}'
✓ built .typeglish/dist/claims.txt ← claims.tg (ebb9f8e60ffa, full)

$ cat .typeglish/dist/claims.txt
# Role
You are Juno, the claims assistant for Bramble Home Insurance.

# Constraints
- MUST ask for the policy number.
- MUST confirm the customer's incident date.
- MUST mention the policy excess.
- MUST give the customer a claim reference.
- MUST keep every reply to at most 3 sentences.

The app build and the website build each carry one policy-number rule, and neither carries the other. The model in the app never sees the instruction to ask.

The dry run is honest about what it cannot see. The new-claim case shares wording with four rules, so it covers four. The two policy-number arms are listed as uncovered because no case says asks for the policy number, and a single test cannot honestly say it: the right answer depends on which build is running. Those two arms are pinned by the build itself, with two artifacts and two hashes from one source. Read both artifacts once before you deploy them.

§5The wrapper audit

You can do this on any prompt in ten minutes, with or without a checker.

Search for the openers. make sure, remember, ensure, don’t forget, be sure, try to, it is important, your job is, please. Each hit is a line whose real action is hiding in its object.
Rewrite each as modal plus verb. MUST, NEVER, SHOULD, MAY, followed straight away by the action. If you wanted the emphasis, the modal is the emphasis.
Re-run the check and read the new errors as questions. A contradiction that appears after the rewrite was always there. It is a policy decision somebody owes, and the error names both lines.
Move the reasons into notes. Reminders usually exist because someone got burned. Don’t forget the excess means customers complained about the excess. That belongs in a @@ note above the rule, where it is kept for the next editor and stripped before the model reads anything.

The habit is simpler than the audit. Write rules the way you would write a function call: the operation first, then what it acts on. The first word after the modal is the rule. Everything that comes before it is decoration, and everything that comes after it is detail.

§6Common questions

Why does my AI agent ignore a NEVER rule in its system prompt?: Often because another line asks for the same action, wrapped in a softener like make sure to or remember to. The wrapper becomes the verb of that line, so nothing reads the two lines as a pair and nobody is told they disagree. The model sees both and picks one per conversation. Rewrite every wrapped rule as a modal plus the real verb and the conflict shows up as a logic/contradiction the build refuses.
Does make sure to make an instruction stronger in a prompt?: It adds urgency to the sentence, not force to the rule. In TypeGlish the line reads as an instruction to make sure, with the real action pushed into the object, so the checker cannot compare it with any other rule about that action. If a rule matters, write MUST or NEVER and put the action verb straight after it.
How do I find hidden contradictions in an agent prompt?: Strip the wrappers first. Rewrite each line that starts with make sure, remember, ensure you, don't forget, be sure or try to as a modal followed by the action verb, then run typeglish check. Pairs that were invisible while one side said remember to ask surface as logic/contradiction errors once both sides say ask.
Is it bad to write please or don't forget in a system prompt?: Politeness costs little on its own, but these openers change how the line parses. In typeglish 0.11.0, a line starting with Please ask or Don't forget to is not read as a rule at all and is reported as prompt/unparsed-rule, so it earns no enforceability credit and no proof. Keep the courtesy in the persona and start each rule with its modal.

Field note

The typeglish statements command is the fastest way to see what a line is actually about. It is read-only and prints a one-line, plain-English reading of every statement in the file. Scan the readings for to make sure to, to remember to or this instruction: and you have found every line whose action is hidden or unread. In every opener we tried, the contradiction appeared only once both lines led with the same action, so putting the real action first is what lets the prover do its job.

∿ washed up Oct 14, 2026 ∿