> Markdown rendition of https://typeglish.dev/blog/agent-sign-off-bereavement ("Why your agent tells a grieving customer to have a great day - Tidelines"). Canonical page: https://typeglish.dev/blog/agent-sign-off-bereavement · All pages: https://typeglish.dev/llms.txt [← Tidelines](https://typeglish.dev/blog)/ Best practices Oct 9, 2026 # 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. by **TypeGlish team** 7 min read #best-practices Every contact. Including this one. **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. ## §1 The 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. before.tg - the house voice, written for every contact ✓ B (87/100) ```typeglish # 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. ``` Five rules, all written with verbs the checker reads. Nothing here is careless. Each line is a reasonable thing to want from a support agent on an ordinary day. tg check, score and build - before.tg ✓ 0 error, 0 warning, 0 info ``` $ 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) ``` Every rule-shaped line read, consistency 100, runtime 99. The only lever the score names is annotation, which the model never sees. 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: an illustrative reply - every clause traces to a rule ``` 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! ``` Not a model failure. The tone rule, the name rule, the close rule and the sign-off rule all fired, as written. Two of them should not have. ## §2 A 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](https://typeglish.dev/blog/default-and-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. ## §3 Write 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. fix1.tg - the exception appended in its own section ✗ logic/contradiction ```typeglish # 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. ``` tg check, score and build - fix1.tg ✗ F (70/100), build refused ``` $ 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 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 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 ``` The unguarded `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. words.tg - the same exception, in other words ✓ B (86/100) ```typeglish # 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. ``` tg check and score - words.tg ✓ a false green ``` $ 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 ``` Clean, and a B. *Wish* is not a verb the checker knows, and *a great day* is not *a cheerful sign-off*, so nothing connects the exception to the rule it was written to override. The default still holds on every contact, and the agent now reads two rules that pull opposite ways. 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.](https://typeglish.dev/blog/renamed-customer-ablation) measured the same thing with the customer’s name: a synonym the checker cannot fold is a contradiction it cannot see. ## §4 Scope 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. guards.tg - two guards, one message ✓ B (87/100) ```typeglish # 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. ``` tg check - guards.tg ✓ 0 error, 0 warning, 0 info ``` $ typeglish check guards.tg ✓ 1 file - 0 error, 0 warning, 0 info ``` *My mum passed away, I need to close her account* satisfies both guards, and one rule requires the call the other forbids. The checker does not report it: the two conditions are worded differently, and it cannot know that one message can meet both. [Every WHEN is a classifier](https://typeglish.dev/blog/every-when-is-a-classifier) is the longer version of this: the model decides the guard, so the overlap is decided at runtime. 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](https://typeglish.dev/blog/agent-third-party-caller) 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. fixed.tg - the default scoped, the contact routed, the exception tested ✓ A (99/100) ```typeglish # 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 ``` The `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. tg check, score, test --dry and build - fixed.tg ✓ 8/8 covered by $TEST ``` $ 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) ``` .typeglish/dist/fixed.txt - what the model reads ✓ every default scoped ``` # 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. ``` The annotations, the tool schemas and both tests stay in the source. The model reads the role, the one sentence that says who an account holder is, and the eight rules. `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. ## §5 Common 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 with `UNLESS 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 `MUST` covers every case, including the one your new `WHEN` rule forbids, so typeglish reports the pair as a `logic/contradiction` and refuses the build. The error is the collision your agent would otherwise settle per conversation. Scope the default with `UNLESS` and 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]` beside `WHEN 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`. Field note 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. ∿ washed up Oct 9, 2026 ∿