After deploying an agent with escalation configured, a team reports that when the agent escalates an error to the on-call engineer, the notification simply reads: 'Agent run failed. Human intervention required.' The engineer has no information about what step failed, which tool was called, or what the agent was trying to accomplish. Which configuration change will make escalation notifications actionable?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Escalation that doesn't include context is like a car's check engine light — it tells you something is wrong but not what to do about it. A good escalation payload tells the engineer: here's the task I was doing, here's what step I was on, here's the exact tool call that failed, here's the error, and here's what I already tried. The engineer should be able to diagnose and resolve the issue without hunting through raw logs. Context-rich escalation is a key accountability and operability requirement in Domain 2.
Full explanation below image
Full Explanation
Escalation to humans is a critical safety valve in agentic systems — when an agent encounters a situation beyond its ability to resolve autonomously, it must hand off to a human. But an escalation notification is only useful if the receiving human can quickly understand the situation and take action.
A minimal actionable escalation payload should include: 1. Task objective: what was the agent trying to accomplish (the high-level goal). 2. Current step: where in the task sequence the failure occurred. 3. Failed tool call: which tool was invoked, with what parameters. 4. Error details: the exact error message or exception returned. 5. Preceding context: the sequence of tool calls that led to this point. 6. Suggested action (optional): if the agent can diagnose the likely cause, it should say so.
This transforms escalation from 'something went wrong' to 'here is exactly what you need to know to fix it.'
Why the other options are wrong:
Option A — Increasing the escalation threshold delays when the human is notified but does not improve the quality of the notification when it does arrive. If the agent retries five times with the same error, the engineer receives the same unhelpful notification, just later. This also risks worsening the situation if the agent is doing something harmful on each retry.
Option C — Switching to a pull-based dashboard changes how the engineer accesses failure information but does not fix the information gap. An engineer who has to log into a dashboard to investigate a vague 'Agent run failed' alert faces the same problem: the information needed to diagnose the failure is still not included in the escalation context. Pull vs. push is a delivery mechanism choice; content richness is a separate concern.
Option D — Adding retries before escalation is valuable for transient errors (see q013) and reduces escalation volume, but it does not address the content of the escalation payload when escalation does occur. The scenario describes an escalation content problem, not an escalation frequency problem. After three retries with no improvement, the engineer still receives 'Agent run failed. Human intervention required.' — just less often.