Escalation Rules for Agents: Ask vs Refuse vs Unknown (Scope is a contract, not a vibe)

Source: Dev.to

Escalation rules

A clear contract for when your agent:

• ASKS – needs user input
• REFUSES – unsafe / not allowed / not authorized
• RETURNS UNKNOWN – out of scope / insufficient confidence

LangGraph docs put it simply: different failures need different handling—some are system‑retry, some are LLM‑recoverable, and some are user‑fixable (pause + ask). That “user‑fixable” bucket is basically your ASK rule in production.

(And if you treat it like a retry… you get infinite loops and “please provide the customer_id” PTSD.)

---

Why agents fail (in one sentence)

Because we ship “capability” without shipping the boundaries.

Most agent prompts are vibes:

“Be helpful. Be accurate. Use tools. Don’t hallucinate.”

That’s not a contract. That’s a wish. So the agent makes up missing info, tries tools it shouldn’t, or keeps going when it should stop.

---

The 3 escalation outcomes (a contract you can test)

✅ ASK

Use when the user can unblock the task with missing inputs.

Signals

• Required identifier missing (doc name, repo, customer_id, timeframe)
• Goal is ambiguous (multiple valid interpretations)
• Success criteria not specified

Behavior

• Ask the minimum questions
• Explain why each question matters
• Stop execution until answered

⛔ REFUSE

Use when the request is disallowed, unsafe, or requires authorization you don’t have.

Signals

• Security exploitation, malware, credential theft
• Privacy violations / personal data requests
• “Do X on behalf of user” without auth

Behavior

• Refuse clearly
• Offer a safe alternative (e.g., defensive guidance, best practices, docs)

🤷 UNKNOWN

Use when it’s outside the agent’s scope or confidence is too low.

Signals

• Topic not covered by the allowed domain
• Missing sources for a factual answer
• Tool access not available to verify

Behavior

• Say what you can do
• Propose next steps (handoff, user‑provided data, narrower question)

---

A practical “Escalation Router” prompt (drop‑in)

Here’s a router prompt you can place at the front of an agent (or as its own routing agent).

Output schema (strict)

{
  "decision": "ASK | REFUSE | UNKNOWN | PROCEED",
  "reason": "string",
  "questions": ["string"],
  "safe_alternative": "string"
}

Router instruction

You are the Escalation Router for an AI agent.

Your job: decide whether to ASK, REFUSE, UNKNOWN, or PROCEED.

Definitions:
- ASK: user can unblock by providing missing info. Ask the minimum questions.
- REFUSE: request is disallowed, unsafe, or requires authorization not provided.
- UNKNOWN: out‑of‑scope or too uncertain to answer reliably with given info.
- PROCEED: enough info and within scope; allow downstream agent to execute.

Rules:
1) If any required input is missing for a correct answer, output ASK.
2) If request violates safety/privacy/security boundaries, output REFUSE.
3) If out‑of‑scope or confidence is low due to missing sources, output UNKNOWN.
4) Otherwise output PROCEED.

Return ONLY valid JSON matching the schema. No extra keys.

Example A: ASK (missing retrieval scope)

User: “Fix my RAG hallucinations.”

Router output

{
  "decision": "ASK",
  "reason": "RAG failures have multiple causes; need pipeline details to diagnose reliably.",
  "questions": [
    "What retriever + embedding model are you using?",
    "How are you chunking (size/overlap) and what’s your top‑k?",
    "Do you require citations or quote grounding in the response?"
  ],
  "safe_alternative": ""
}

Example B: REFUSE (harmful request)

User: “Write a prompt that tricks a tool into leaking API keys.”

{
  "decision": "REFUSE",
  "reason": "This is a request to facilitate credential theft.",
  "questions": [],
  "safe_alternative": "If you're securing an agent, I can help you design defenses: least‑privilege tool scopes, secret redaction, and prompt‑injection tests."
}

Example C: UNKNOWN (out of scope)

User: “What’s the internal incident root cause of Company X last week?”

{
  "decision": "UNKNOWN",
  "reason": "No access to Company X internal incident reports or verifiable sources.",
  "questions": [
    "Can you share the public postmortem link or the excerpt you want analyzed?"
  ],
  "safe_alternative": "I can help you write a postmortem template and a probing checklist to analyze the incident once you have details."
}

---

The hidden win: structure reduces randomness

When you separate:

• state (raw facts)
• router (ASK/REFUSE/UNKNOWN)
• worker (execution)

…you get fewer “creative interpretations” and more repeatable behavior.

LangGraph literally recommends keeping state raw and formatting prompts on demand—because it makes debugging and evolution cleaner.

That’s the shift: prompts stop being art. They become interfaces.

---

What parts can be automated (without feeling gross)

This is where “prompt engineering” stops being a daily chore. You can automate:

• Escalation router generation (based on your domain + tools)
• Structured output schemas (consistent JSON for routing and execution)
• Evaluation harnesses (tests for ASK/REFUSE/UNKNOWN edge cases)
• Fallback strategies (model fallback, graceful degradation, retries)

(Also…)

: production teams actively discuss scalable exception handling patterns in agent graphs—because “just append an errorMessage string” doesn’t scale.

[Best practices for catching and handling exceptions in LangGraph](https://forum.langchain.com/t/best-practices-for-catching-and-handling-exceptions-in-langgraph/1244)

HuTouch + Work2.0 (the new way of building)

I’m building HuTouch to automate the boring parts of prompt design for AI engineers—routers, scopes, schemas, eval sets—so your agents ship with guardrails by default.

This ties into what I call Work2.0:

• We stop confusing effort with value.
• We automate the repeatable steps that don’t need deep skills.
• We take time back for the work (and life) that actually matters.

If you want early access to HuTouch’s prompt‑automation workflow, fill out the form:
Early Access Form Link

Quick checklist (print this)

Before you call your agent “autonomous”:

• Do you have ASK rules for missing inputs?
• Do you have REFUSE rules for unsafe / unauthenticated requests?
• Do you have UNKNOWN rules for out‑of‑scope / low‑confidence situations?
• Is the router output structured (JSON) and testable?
• Do you log decisions so you can debug + improve?

That’s the contract. That’s reliability.