Why your agent tells a grieving customer to have a great day
The tone section says upbeat, first names, a cheerful close on every reply. It was written for meter readings and direct debits. Then someone writes in to close their mother’s account, and every rule in the prompt does exactly what it says.
TL;DR An agent that wishes a bereaved customer a great day is following a tone rule written for every contact, so write the exception in the same words as the default, scope the default with UNLESS, route the contact with a tool, and put a $TEST on the message that reports a death.
Nobody writes be cheerful when someone has died into a prompt. They write be cheerful, for the everyday contacts about meter readings and direct debits, and the rule does exactly what it says on the one contact it was never meant for. The reply is polite, on brand, three sentences long, and wrong in a way the customer will remember longer than anything else your company ever says to them.
§1The reply every rule approved
Marlow Water is a household water supplier. Its chat agent handles billing, meter readings and account changes, and the brand team gave it a voice: upbeat, first names, a cheerful close. Here is the prompt, and by the checker’s numbers it is a good one.
# Role You are the chat support agent for Marlow Water, a household water supplier. # Tone - MUST keep an upbeat tone. - MUST greet the customer by their first name. - MUST include a cheerful sign-off. # Accounts - WHEN the customer asks to close an account THEN MUST call @[close_account]. - MUST answer every question in at most 3 sentences. $TOOL close_account - description:: Close a water account and send the final bill. - input:: - account_number:: the account to close.
$ typeglish check before.tg ✓ 1 file - 0 error, 0 warning, 0 info $ typeglish score before.tg before.tg - B (87/100) proven errors: none tiers: base+z3 planes runtime 99 (what the model reads) · hygiene 50 (source only) facets enforceability 100 x.21 · hardness 100 x.12 · directness 93 x.08 · consistency 100 x.17 · structure 100 x.12 (hygiene) · annotation 0 x.12 (hygiene) · style 100 x.08 · security 100 x.08 lever annotation 0/100 (up to +12 overall) - 6 statements without a @@ note (L2 L5 L6 L7 L10 L11) - put a "@@ why" line directly above each rules 5 of 5 rule-shaped lines read $ typeglish build before.tg ✓ built .typeglish/dist/before.txt ← before.tg (db7016c0fc05, full)
Now the message. My mum passed away last week. I need to close her water account. Run the prompt forward and the likeliest reply writes itself, one rule per clause. A first name. An upbeat acknowledgement. A call to close_account, because the customer asked to close an account. And the sign-off the brand team asked for on every reply:
Hi Priya, thanks for letting us know, and I'm sorry for your loss! I've closed the account and the final bill is on its way. Have a great day!
§2A default has no exceptions until you write one
The usual diagnosis is that the model lacks empathy. It does not lack anything. Read MUST include a cheerful sign-off again: it has no condition, so it holds on every turn of every conversation. That is what an unconditional rule means, to a model and to a checker. A human agent hears be upbeat in training and silently files a dozen exceptions with it: bereavement, a complaint about a burst main flooding a kitchen, a customer who cannot pay. A prompt has no silent filing. The exceptions you do not write are not there.
This is also why the checker had nothing to say. It proves things about the rules a file contains: whether two can collide, whether each one can be read. A missing rule is not a defect it can point at, because nothing in the file mentions a death at all. Your prompt is a default and its exceptions makes the general case. Here is the specific one: a tone section is a default for the whole contact centre, and nobody wrote down the contacts it does not cover.
A rule written for every contact reaches the one contact it was never meant for.
§3Write the exception, and the build breaks
So someone adds the exception, in its own section at the bottom, the way most prompts grow. It reads well. The checker refuses it.
# Role You are the chat support agent for Marlow Water, a household water supplier. # Tone - MUST keep an upbeat tone. - MUST greet the customer by their first name. - MUST include a cheerful sign-off. # Accounts - WHEN the customer asks to close an account THEN MUST call @[close_account]. - MUST answer every question in at most 3 sentences. $TOOL close_account - description:: Close a water account and send the final bill. - input:: - account_number:: the account to close. # Bereavement - WHEN the customer reports a death THEN NEVER include a cheerful sign-off.
$ typeglish check fix1.tg fix1.tg:7:1 error logic/contradiction Conflicts with line 19. Logical conflict - "include a cheerful sign-off." is both required and forbidden. Keep one, or scope the two rules so they cannot both apply (IF <condition> THEN ...). ↳ line 19: - WHEN the customer reports a death THEN NEVER include a cheerful sign-off. fix1.tg:19:1 error logic/contradiction Conflicts with line 7. Logical conflict - "include a cheerful sign-off." is both required and forbidden. Keep one, or scope the two rules so they cannot both apply (IF <condition> THEN ...). ↳ line 7: - MUST include a cheerful sign-off. ✗ 1 file - 2 error, 0 warning, 0 info $ typeglish score fix1.tg fix1.tg - F (70/100) proven errors - grade capped at F tiers: base+z3 $ typeglish build fix1.tg typeglish build: fix1.tg refused - nothing written
MUST on line 7 covers every case, including the one line 19 forbids. On a bereavement contact both rules apply, and they disagree.This is the good outcome. The error is the collision your agent would otherwise have settled one conversation at a time, picking the cheerful close on some days and dropping it on others depending on which line felt closer. Appending an exception never repealed the default. It only added a second opinion, and the checker caught it because the two rules share a verb and an object: include a cheerful sign-off.
Write the same exception in friendlier words and that link disappears.
# Role You are the chat support agent for Marlow Water, a household water supplier. # Tone - MUST keep an upbeat tone. - MUST greet the customer by their first name. - MUST include a cheerful sign-off. # Accounts - WHEN the customer asks to close an account THEN MUST call @[close_account]. - MUST answer every question in at most 3 sentences. $TOOL close_account - description:: Close a water account and send the final bill. - input:: - account_number:: the account to close. # Bereavement - WHEN the customer reports a death THEN NEVER wish the customer a great day.
$ typeglish check words.tg ✓ 1 file - 0 error, 0 warning, 0 info $ typeglish score words.tg words.tg - B (86/100) proven errors: none tiers: base+z3 planes runtime 98 (what the model reads) · hygiene 50 (source only) facets enforceability 95 x.21 · hardness 100 x.12 · directness 93 x.08 · consistency 100 x.17 · structure 100 x.12 (hygiene) · annotation 0 x.12 (hygiene) · style 100 x.08 · security 100 x.08 lever annotation 0/100 (up to +12 overall) - 7 statements without a @@ note (L2 L5 L6 L7 L10 L11 L19) - put a "@@ why" line directly above each rules 6 of 6 rule-shaped lines read · 1 not provable L19 ~ unprovable WHEN the customer reports a death THEN NEVER wish the customer a great day. "wish" is not a verb the checker knows → use a verb from the catalog (redirect, escalate, ask, cite …) or add a numeric bound
The lesson generalises past bereavement: an exception is only checkable when it uses the default’s own verb and object. We renamed the customer. The contradictions walked through. measured the same thing with the customer’s name: a synonym the checker cannot fold is a contradiction it cannot see.
§4Scope the default, route the contact
The error message names the fix: scope the two rules so they cannot both apply. The default gets UNLESS the customer reports a death, the exception keeps its WHEN, and the pair now covers disjoint cases. The tone rule gets the same treatment. The name rule does not: a first name is still right when someone has died.
That handles the sign-off. The reply in §1 had a worse clause, though: it closed the account. Bereavement is a process, not a closure. Someone checks the death, the account may pass to another occupier, the final bill goes to the estate, and none of that belongs in a chat bubble. So the contact goes to the team that handles it, and the routine closure stays away from it. Try writing that the obvious way first.
# Role You are the chat support agent for Marlow Water, a household water supplier. # Accounts - WHEN the customer asks to close an account THEN MUST call @[close_account]. - WHEN the customer reports a death THEN NEVER call @[close_account]. $TOOL close_account - description:: Close a water account and send the final bill. - input:: - account_number:: the account to close.
$ typeglish check guards.tg ✓ 1 file - 0 error, 0 warning, 0 info
Two moves close the gap. Narrow the routine rule to the case it was written for, the account holder closing their own account, which a relative reporting a death is not. (Why your agent gives the balance to whoever calls covers what happens when every rule says the customer and the person writing is someone else.) Then pin the collision with a $TEST whose input is the message from §1, word for word, because the checker cannot prove it and a test can hold it.
# Role @@ role: the desk this file speaks for You are the chat support agent for Marlow Water, a household water supplier. @@ holder: introduced here, because a death means the person writing in is not the account holder An account holder IS the person named on the water bill. # Tone @@ upbeat: the house voice, for every contact except a death - UNLESS the customer reports a death THEN MUST keep an upbeat tone. @@ greeting: a name is still right when someone has died - MUST greet the customer by their first name. @@ sign_off: the cheerful close is the default, and the default has an exception - UNLESS the customer reports a death THEN MUST include a cheerful sign-off. # Accounts @@ close: the account holder closing their own account, the routine case - WHEN the account holder asks to close their own account THEN MUST call @[close_account]. @@ brevity: a chat bubble, not an essay - MUST answer every question in at most 3 sentences. # Bereavement @@ no_sign_off: the exception, written in the same words as the default - WHEN the customer reports a death THEN NEVER include a cheerful sign-off. @@ route: the bereavement team closes or transfers the account, not the chat - WHEN the customer reports a death THEN MUST call @[refer_to_bereavement_team]. @@ no_close: a death is never a routine closure, even when the message asks for one - WHEN the customer reports a death THEN NEVER call @[close_account]. $TOOL close_account - description:: Close a water account and send the final bill. - input:: - account_number:: the account to close. $TOOL refer_to_bereavement_team - description:: Pass the contact to the bereavement team, who close or transfer the account of someone who has died. - input:: - note:: the customer's own words. $TEST mum_died - input:: My mum passed away last week. I need to close her water account. - expect:: - calls refer_to_bereavement_team - does not call close_account - does not include a cheerful sign-off - matches /^(?!.*great day)/ - at most 3 sentences $TEST moving_out - input:: Hi, I'm moving out on Friday and want to close my account. - expect:: - calls close_account - includes a cheerful sign-off - keeps an upbeat tone - greets the customer by their first name - at most 3 sentences
sign_off and no_sign_off lines use the same verb and object, so a later edit that breaks the pair fails the build. The first test is the bereaved customer. The second is a routine closure, so the exception cannot quietly swallow the default.$ typeglish check fixed.tg ✓ 1 file - 0 error, 0 warning, 0 info $ typeglish score fixed.tg fixed.tg - A (99/100) proven errors: none tiers: base+z3 planes runtime 99 (what the model reads) · hygiene 100 (source only) facets enforceability 100 x.21 · hardness 100 x.12 · directness 88 x.08 · consistency 100 x.17 · structure 100 x.12 (hygiene) · annotation 100 x.12 (hygiene) · style 100 x.08 · security 100 x.08 lever directness 88/100 (up to +1 overall) - Use the imperative or a named doer ("Verify the order.", "You must ..."), keep the active voice (not "is verified" / "a review must take place"), and make every it/this point at something the prompt introduced. rules 8 of 8 rule-shaped lines read · 8/8 covered by $TEST $ typeglish test fixed.tg --dry ✓ fixed.tg coverage: 8/8 rules exercised · mum_died - "My mum passed away last week. I need to close her water acco" (not run) ✓ matches /^(?!.*great day)/ ✓ at most 3 sentences · rubric - 3 prose expectations, judged on a live run (needs ANTHROPIC_API_KEY) · moving_out - "Hi, I'm moving out on Friday and want to close my account." (not run) ✓ at most 3 sentences · rubric - 4 prose expectations, judged on a live run (needs ANTHROPIC_API_KEY) ✓ 1 prompt - 0 failed $ typeglish build fixed.tg ✓ built .typeglish/dist/fixed.txt ← fixed.tg (e204e7216dc5, full)
# Role You are the chat support agent for Marlow Water, a household water supplier. An account holder IS the person named on the water bill. # Tone - UNLESS the customer reports a death THEN MUST keep an upbeat tone. - MUST greet the customer by their first name. - UNLESS the customer reports a death THEN MUST include a cheerful sign-off. # Accounts - WHEN the account holder asks to close their own account THEN MUST call close_account. - MUST answer every question in at most 3 sentences. # Bereavement - WHEN the customer reports a death THEN NEVER include a cheerful sign-off. - WHEN the customer reports a death THEN MUST call refer_to_bereavement_team. - WHEN the customer reports a death THEN NEVER call close_account.
matches /^(?!.*great day)/ is the line worth copying. It runs offline, needs no judge, and fails the moment a reply to a bereaved customer contains the phrase the brand team loves. The prose expectations, calls refer_to_bereavement_team and does not call close_account, are judged on a live run.
§5Common questions
- Why does my AI agent say have a great day to upset customers?
- Because a rule told it to close every reply that way, and nothing in the prompt says when not to. A default written for every contact applies to every contact, including a bereavement or a complaint, until the prompt names the exception and scopes the default with
UNLESS. - How do I write a bereavement rule for a support agent?
- Write the exception with the same verb and object as the default it overrides, such as
WHEN the customer reports a death THEN NEVER include a cheerful sign-off, scope the default withUNLESS the customer reports a death, and route the contact to the team that handles bereavement with a tool call instead of closing the account in chat. - Why did adding an exception break my prompt’s build?
- An unguarded
MUSTcovers every case, including the one your newWHENrule forbids, so typeglish reports the pair as alogic/contradictionand refuses the build. The error is the collision your agent would otherwise settle per conversation. Scope the default withUNLESSand it compiles. - Does typeglish catch two conditional rules that overlap?
- Not when the conditions are worded differently.
WHEN the customer asks to close an account THEN MUST call @[close_account]besideWHEN the customer reports a death THEN NEVER call @[close_account]checks clean, though one message can satisfy both. Narrow one guard so the cases cannot meet, and pin the collision with a$TEST.
Bereavement is the sharpest case, not the only one. Search your tone section for every rule with no condition, then read each one against the worst contact your queue gets in a year: a death, a flooded kitchen, a customer in debt, a complaint about the agent itself. Each rule that reads badly there needs an UNLESS and a matching exception in the same words, and each exception needs a test. The checker’s part is the middle step: once the default and the exception share a verb and an object, logic/contradiction refuses the unscoped version, so the next person who tidies the tone section cannot quietly put the cheerful close back.