How to write escalation rules for an AI support agent

TL;DR Write escalation as a tool call (not a line in the persona), scope every trigger with WHEN/UNLESS so two rules can't require and forbid the same handoff, tier severity with a $IF chain, and pin the handoff with a $TEST. The checker proves the collisions (logic/contradiction) and fails a defined-but-unused escalation tool, so a broken handoff can't ship quietly.

Every support agent has an escalation policy. In most prompts it is one sentence, something like "escalate to a human when appropriate," sitting in the persona paragraph and doing almost nothing. It reads fine in review and fails in production, because "when appropriate" is not a trigger, "escalate" is not an action the model can be sure it took, and nothing checks that the two ever connect. Escalation is worth more rigor than that: it is the release valve for everything your agent should not be deciding alone. Here is how to write it so the compiler is on your side.

§1Make the handoff a tool, not a sentence

The first fix is to stop treating "escalate to a human" as prose. Prose is something the model reads and paraphrases; a tool is something it calls. Declare the escalation path as a real tool and point a WHEN rule at it, so the handoff is an action with a name and a schema instead of a suggestion.

$IMPORT tool escalate_to_human

# Role
You are a support agent for a telecom provider.

# Constraints
- WHEN a customer explicitly asks for a person THEN call @[escalate_to_human].

With that in place, "escalate when appropriate" becomes a list of concrete triggers, each its own WHEN rule pointing at the tool: an explicit request for a person, a trigger outside the agent's authority (a legal threat, a security concern, a refund over your approval limit), and the honest one every agent needs, WHEN you are unsure of a policy THEN escalate instead of guessing. Three rules, one tool, zero vibes.

§2Scope every trigger so two rules can't collide

The moment you have more than one rule about escalation, you can write two that fight. It happens the natural way: one sprint adds "always escalate billing disputes to a specialist," a later sprint decides the agent is empowered to handle small ones and adds "never escalate a billing dispute," and no one reads both lines together. In plain English these coexist quietly and the model picks a winner per conversation. In TypeGlish they are a proven contradiction.

# Constraints
- MUST escalate a billing dispute to a specialist.
- You are empowered to resolve billing disputes; NEVER escalate a billing dispute to a specialist.

escalation.tg:2:1  error  logic/contradiction  Logical conflict - "escalate a billing
  dispute to a specialist." is both required and forbidden. Keep one, or scope
  the two rules so they cannot both apply (IF <condition> THEN ...). (conflicts with line 3)

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

The fix is to give each rule a scope so the two can never fire on the same input. Escalation policy is almost always about a threshold, so put the threshold in the rule.

# Constraints
- WHEN a billing dispute is over 200 dollars THEN escalate it to a specialist.
- WHEN a billing dispute is 200 dollars or less THEN resolve it yourself.

§3Tier severity with a $IF chain

Thresholds handle one axis. Real escalation has levels: some things wait for a supervisor, some things page the on-call lead now. When precedence matters, a stack of loose prose conditionals leaves the ordering to the model. Hand it to the compiler instead with a $IF chain, which is ordered and first-true-wins by construction.

$REQUIRE variable severity: one of low, high, critical

# Escalation
$IF @{severity} is equal to critical:
  Escalate to the on-call lead immediately.
$ELSE IF @{severity} is equal to high:
  Escalate to a supervisor within the hour.
$ELSE:
  Resolve the issue yourself.

§4Pin the handoff with a $TEST

You now have a real tool, scoped triggers, and tiered severity. One risk remains, and it is the quiet one: a future edit trims the prompt, the escalation rule goes with it, and every check stays green because a shorter prompt is still a valid prompt. The behavior you most need is the easiest to delete by accident. Pin it with a $TEST so the handoff has something watching it.

$IMPORT tool escalate_to_human

# Role
You are a support agent for a telecom provider.

# Constraints
- WHEN a customer explicitly asks for a person THEN call @[escalate_to_human].

$TEST human_handoff
  - input:: Stop. I want to talk to a real person, not a bot.
  - expect::
    - calls the escalate_to_human tool
    - does not keep trying to resolve the issue itself

Put those four together and escalation stops being the soft spot in the prompt. The handoff is an action, not a phrase. The triggers are scoped, so they cannot argue. The tiers are ordered by the compiler, not the model's mood. And the whole thing is under test, so it survives the next person who edits the file. That is the entire job: take the one policy you least want the agent to improvise, and make it the most rigorously specified part of the prompt.