Refusals That Don't Kill the Conversation

~14 min · conversation, refusals

Level 0Apprentice

0 XP0/100 lessons0/14 achievements

0/120 XP to next level120 XP to go0% complete

Refusing without ghosting

Sometimes the model has to refuse — out of safety policy, out of scope, out of capability. A bad refusal kills the conversation: "I cannot help with that." A good refusal redirects: "I can't do X for safety reasons; I can do Y, or you can ask Z."

The shape of a usable refusal

Acknowledge — name what was asked.
Decline with reason — short, factual.
Offer alternatives — what the model can do.
Open the door for redirection — "is there a related thing I can help with?"

What kills conversations

Generic refusals with no specifics ("I can't help with that" — what was that?).
Refusing in the wrong layer (system policy refusal returned in plain text instead of a structured error).
Excessive moral hedging on benign requests.

Programmable refusals

For pipelines, refusals should be structured: {"status": "refusal", "reason_code": "out_of_scope", "alternatives": [...]}. The UI then decides how to present the refusal.

Code

Refusal schema for pipelines·json

{
  "status": "refusal",
  "reason_code": "out_of_scope",
  "reason_message": "Pricing strategy is outside the support agent's scope.",
  "alternatives": [
    {"action": "escalate", "target": "sales"}
  ]
}

External links

Exercise

On a prompt that returns generic refusals, design a structured refusal schema with reason_code and alternatives. Run on five out-of-scope inputs. Compare downstream UX.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousThe Pippa Pattern — Vault as External Memory Next →Closing the Loop — When to End the Conversation

Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)

No comments yet — be the first.