Escalation, Ambiguity, and Error Propagation

Two reliability patterns that decide whether an agent behaves well when it can’t just proceed: knowing when to hand off to a human (Task 5.2) and how errors should travel through a multi-agent system (Task 5.3). These are the Customer Support and Multi-Agent Research scenarios under stress. They’re design patterns, verifiable by reasoning; the underlying structured-error mechanics build on Domain 2.

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, and 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.

And the wrong triggers, which the exam offers as traps: sentiment and self-reported confidence are 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 — 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, escalating 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, while 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, 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: 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, which 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: the ask-a-human instinct applied to disambiguation.

Error propagation across agents

Task 5.3 is how errors travel through a multi-agent system, and 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 being forced to choose 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.

The reliability capstone of this task: 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

Escalate on the right signals — an explicit request for a human (immediately), a policy gap or ambiguity, or an inability to progress — and not 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, so 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.