Escalation, Ambiguity, and Error Propagation

What escalation and error propagation are for

An agent that only knows how to charge ahead is dangerous. Real work is full of moments where the right move is not to proceed. The request is outside what the agent is allowed to decide, a tool came back broken, or the customer is asking for something the policy doesn’t cover. This chapter is about two disciplines for those moments. Escalation hands the problem to a human when the agent shouldn’t or can’t resolve it. Error propagation governs how a failure travels through a multi-agent system without being either hidden or allowed to bring everything down.

Both are the reliability lesson of the previous chapter turned outward. Context management is about being honest with yourself about what you know. Escalation and error propagation are about being honest with the humans and other agents around you when you’ve hit a limit. These are the Customer Support and Multi-Agent Research scenarios under stress. They’re design patterns, verifiable by reasoning, and the underlying structured-error mechanics build on Domain 2.

Why it matters — and the cost of getting it wrong

The entire value of an agent is that it resolves things on its own. An agent that escalates every hard-looking case is an expensive router to a human queue. You’ve automated nothing, and you’ve taught your users that the agent is a speed bump on the way to a person. So the pressure runs toward proceeding, and that pressure is healthy right up until it isn’t.

The other direction is worse and quieter. An agent that proceeds when it shouldn’t acts on the wrong customer’s account, reports success on a search that failed, or makes a policy call it had no authority to make. And it does so confidently, with no signal that anything went wrong. Both escalation and error handling are therefore calibration problems: surface exactly the cases that need surfacing, no more and no fewer. The exam’s traps almost all live at the edges — cases that look like they need a human but don’t, and cases that look routine but must be escalated or reported.

The spectrum of “I can’t just proceed”

When an agent hits a wall, it has more than two options. It is not simply “handle it” versus “give up.” There is a spectrum, and picking the right point on it is the skill this chapter tests.

• Recover locally. The failure is transient — a timeout, a flaky call. The agent retries it itself and proceeds. No human, no propagation.
• Ask for clarification. The request is resolvable but ambiguous — the agent has the capability, it just doesn’t yet know which entity or action is meant. It asks one targeted question and continues.
• Escalate to a human. The situation is beyond the agent’s authority or coverage — an explicit request for a person, a policy gap, or an inability to make progress. The agent hands off.
• Propagate a structured error. In a multi-agent system, the failure is something this agent can’t resolve but a coordinator might. It reports the failure richly, upward, rather than swallowing it or dying on it.

The rest of the chapter is how the exam presses on each of these. The recurring mistake in every case is collapsing the spectrum: treating a clarification as an escalation, a transient error as a fatal one, or a real failure as a success.

When to escalate

The exam is precise about the right escalation triggers, and it’s precise about the wrong ones. Escalate when:

• The customer explicitly asks for a human. This is the clearest trigger, and it’s immediate. You honor it; you don’t first try to resolve the issue yourself.
• Policy is ambiguous or silent on the customer’s specific request — not merely when the case is complex. A policy that addresses own-site price adjustments but says nothing about competitor price matching is a gap. A gap is an escalation trigger even if the request itself is simple. This is the subtle one: escalation is about policy coverage, not difficulty.
• The agent can’t make meaningful progress: it’s stuck, not just slow.

The wrong triggers, which the exam offers as traps, are sentiment and self-reported confidence — both unreliable proxies for actual complexity. An angry customer with a simple, in-policy request doesn’t need a human; a calm customer with a policy-gap request does. Routing on how the customer feels, or on the model’s own confidence score, escalates the wrong cases and mishandles the right ones. Complexity — specifically, policy coverage and ability to progress — is the signal; emotion and confidence are noise.

The nuance the exam tests hardest is the difference between demanding and complaining. When a customer explicitly demands a human, escalate immediately, with no investigation first. When a customer is merely frustrated but the issue is within the agent’s capability, acknowledge the frustration and offer to resolve it. Escalate only if they reiterate the preference for a human. The failure modes are symmetric. Escalating every frustrated customer wastes human capacity on things the agent could handle; ignoring an explicit demand to “let me talk to a person” is a trust violation. Read the request, not the tone.

You implement this with explicit escalation criteria plus few-shot examples in the system prompt, showing the model when to escalate versus resolve. It’s exactly the criteria-plus-examples pattern from Domain 4. Vague instructions (“escalate difficult cases”) produce inconsistent escalation; concrete criteria with worked examples produce calibrated escalation.

Ambiguity: clarify, don’t guess

A related reliability behavior sits one notch down the spectrum from escalation. When a tool returns multiple matches — a customer search that hits three accounts — the agent must ask for an additional identifier, not heuristically select one. Picking “probably the most recent” or “probably the first” is a guess that will sometimes act on the wrong customer’s account, which for a support agent is a serious error. Requesting a disambiguating identifier (an email, an order number) is the safe, correct move. The general principle recurs across the exam: when the agent is genuinely uncertain about which entity or action is meant, surfacing the ambiguity beats resolving it by heuristic. It’s the ask-a-human instinct applied to disambiguation.

Error propagation across agents

The rightmost point on the spectrum is how errors travel through a multi-agent system. It has two named anti-patterns you must recognize on sight, because they’re opposite failures:

• Silently suppressing errors — returning empty results as if the query succeeded. Now the coordinator thinks there was genuinely nothing to find, when actually the search failed, and it builds a report on a false premise.
• Terminating the entire workflow on a single failure — one subagent’s timeout kills the whole research task, discarding the good results the other subagents produced.

Both are wrong, and the fix between them is structured error context. When a subagent hits an error it can’t resolve, it propagates rich information: the failure type, what it attempted, any partial results, and potential alternatives. That lets the coordinator make an intelligent recovery decision — retry with a different approach, proceed with partial coverage, or note the gap — rather than choosing between “pretend it worked” and “give up entirely.” A generic status like “search unavailable” hides all of that; a structured error exposes it.

The same access-failure-vs-empty-result distinction from Domain 2 is load-bearing here. The coordinator must be able to tell a timeout (which might warrant a retry) from a valid empty result (a successful query with no matches), because it responds to them completely differently. And subagents should do local recovery for transient failures — retry the timeout themselves — propagating only what they genuinely can’t resolve, along with what they attempted and any partial results. That is the “recover locally” point on the spectrum, done at the subagent level before anything gets propagated at all.

The reliability capstone of this task concerns synthesis. When synthesis combines findings, it should carry coverage annotations, marking which conclusions are well-supported versus which topic areas have gaps because a source was unavailable. A report that silently omits the topics its failed subagent was supposed to cover looks complete and isn’t. A report that annotates the gap is honest about what it does and doesn’t know. That honesty about coverage is itself a reliability property, and it flows directly into provenance and uncertainty in the next chapter.

Final thoughts

Behaving well when you can’t just proceed means picking the right response from a spectrum, not flipping between “handle it” and “give up.” Escalate on the right signals: an explicit request for a human (immediately), a policy gap or ambiguity, or an inability to progress. Do not escalate on sentiment or self-reported confidence, which are unreliable proxies. Distinguish a demand (escalate now) from a complaint (offer to help, escalate if reiterated). On ambiguity, ask for a clarifying identifier rather than guessing among multiple matches. And propagate errors structurally — failure type, what was attempted, partial results — steering between the twin anti-patterns of silently suppressing failures and collapsing the whole workflow. Then the coordinator can recover intelligently and annotate honest coverage gaps.

Next: human review, confidence, and provenance — calibrating when to trust automation, and preserving where each claim came from.