Domain 5 · Lesson 2 · Context & Reliability (15%)
Escalation & Error Propagation
Task Statements 5.2 & 5.3 — when to hand off to a human, and how failures travel up.
Course progress: Domain 5 ▸ lesson 2 of ~3
Escalation & ambiguity resolution (5.2)
Legitimate escalation triggers:
- The customer explicitly asks for a human — honor it immediately, without first attempting investigation.
- Policy gap / ambiguity — policy is silent or unclear on the request (e.g., competitor price-matching when policy only covers own-site adjustments). Escalate; don't invent policy.
- Cannot make meaningful progress.
Unreliable escalation proxies (distractors)
Sentiment (frustration ≠ complexity) and self-reported confidence scores are poorly calibrated proxies for actual case complexity — the exam repeatedly rejects both. An agent is often incorrectly confident on the hard cases.
Calibrated behavior: acknowledge frustration but offer resolution when the issue is within your capability — escalate only if the customer reiterates the preference. When a lookup returns multiple matches, ask for additional identifiers; never pick heuristically. Improve escalation calibration with explicit criteria + few-shot examples (not a trained classifier or sentiment threshold as a first move).
Error propagation across agents (5.3)
When a subagent (e.g., web search) times out, how the failure reaches the coordinator determines whether recovery is possible.
| Approach | Verdict |
| Structured error context: failure type, attempted query, partial results, alternatives | Correct Enables intelligent coordinator recovery |
| Generic status ("search unavailable") after silent retries | Wrong Hides context the coordinator needs |
| Catch timeout, return empty set marked successful | Wrong Silent suppression → incomplete results look complete |
| Propagate exception that kills the whole workflow | Wrong One failure shouldn't end everything |
The pattern
Subagents recover transient failures locally; propagate up only what they can't resolve, with what was attempted and any partial results. Distinguish an access failure (retry decision) from a valid empty result. Annotate synthesis with coverage gaps so the final output is honest about what's missing.
Check yourself
An agent resolves 55% (target 80%): it escalates easy cases and attempts hard policy-exception ones. Most effective calibration fix:
- Add explicit escalation criteria plus few-shot escalate-vs-resolve examples
- Have the agent self-report confidence and route low scores to humans
- Train a separate classifier on historical tickets to predict escalation
- Add sentiment analysis and escalate when negativity crosses a threshold
Correct: option 1. Unclear decision boundaries are the root cause; explicit criteria + few-shot fix it proportionately. Self-reported confidence (2) is poorly calibrated (already wrongly confident on hard cases); a classifier (3) is over-engineered before prompt work; sentiment (4) doesn't track complexity.
A web-search subagent times out. The propagation design that best enables recovery returns to the coordinator a:
- Generic "search unavailable" status after silent internal retries
- Empty result set marked successful so the pipeline keeps flowing
- Structured context: failure type, attempted query, partials, alternatives
- Raised exception that halts the entire research workflow at once
Correct: option 3. Structured error context lets the coordinator retry, reroute, or proceed with partials. Generic status hides context; empty-as-success suppresses the failure; halting the workflow is disproportionate.
Decision rules
Customer asks for human → escalate now. Policy silent/ambiguous → escalate. Multiple matches → ask for identifiers. Never escalate on sentiment/self-confidence. Failures → structured context, local recovery first, partial results up, annotate coverage gaps; never silent-suppress or kill the workflow.
Ask your teacher. Want the escalate-vs-resolve few-shot block, or the structured-error schema? Ask.