What is Escalation?
Handing a stuck case to a person — ideally with the full history of what was tried and why it stopped.
An agent that can stop is cheaper than one that loops; the history is what makes the handover useful.
On this page
Escalation is the controlled act of an agent stopping work and handing it to a person — with the question, the failure history, and what has been tried attached — instead of retrying indefinitely or, worse, improvising a way past the obstacle. It is the safety valve of autonomous work: everything between the human gates runs without supervision precisely because this path exists for the cases that cannot.
The design question is not whether agents should escalate — any system that runs unattended needs an exit — but when, and how usefully. An escalation that fires on the first failed test is noise; an escalation that fires after the fifteenth identical retry is a fire alarm nobody can read.
Why escalation matters more with agents
Unattended work inverts the normal cost of being stuck. A human developer who hits a wall stops, asks, and moves on — the wall has a natural interpreter. An agent that hits the same wall has three options, and two of them are catastrophic at scale:
| Behaviour | Immediate effect | Compounding cost |
|---|---|---|
| Loop | Tokens burn, nothing ships | A queue of half-dead work nobody noticed dying; hours of compute spent re-learning the same dead end |
| Improvise | Work "continues" — around the obstacle | The workaround becomes the implementation; the deviation is discovered at review, or later |
| Escalate | The work parks; a person decides | The next run starts from the answer instead of rediscovering the question |
The loop case is the sneaky one: from the outside, a retrying agent looks exactly like a productive one. Without escalation as a designed path — and without visibility into which work is parked — "still running" and "stuck forever" are indistinguishable.
What a useful escalation carries
An escalation is a handover between colleagues, and it is only as good as its handover notes. The minimum useful set:
- The question, stated. Not "blocked" — "the brief's acceptance criterion 3 contradicts the API as implemented; which wins?"
- What was tried. Each approach, its result, and why it was abandoned. This is what stops the next run from repeating the sequence.
- What would unblock it. Often the agent can see the decision it needs even though it cannot make it.
- The state of the work. Branch, evidence so far, what remains untouched.
The first item is the hardest and the most valuable: turning a stuck state into a well-formed question is most of the way to answering it, and it is the difference between an escalation a person resolves in two minutes and one they re-open the whole ticket to understand.
Escalation vs the neighbouring concepts
| Escalation | Retry with backoff | Human gate | |
|---|---|---|---|
| When it fires | An obstacle the agent cannot resolve | A failure likely to be transient | A decision point designed in advance |
| Who decides next | The person | The agent | The person, by design |
| Expected frequency | Rare, by intent | Common, cheap | Fixed by the autonomy level |
| Signal when frequent | The briefs or the tooling are defective | Normal operation | Normal operation |
The diagnostic reading matters as much as the mechanical one. Escalations are a health signal: a project whose escalations cluster on one kind of work has a brief-writing problem; one whose escalations are all "environment unavailable" has an infrastructure problem; one with almost no escalations and heavy review rework has agents that are not stopping when they should.
Best practices for escalation design
1. Cap retries, then stop
A fixed number of attempts — not a mood. When the cap is reached, the work parks with its history; it does not try attempt eleven because attempt ten felt close.
2. Route escalations where people actually look
An escalation that lands in a log is a loop with extra steps. The destination is a queue with visibility: what is waiting, since when, on whose decision.
3. Record the return path
When a person resolves an escalation, the answer should reach the work — the next run resumes with the decision attached, and the resolution itself becomes a record: what was asked, what was decided, why.
4. Treat escalation quality as a signal
Read the escalations weekly. Well-formed questions with useful histories mean the system works; vague "blocked" flags mean the agents are stopping without thinking, which is a prompt and tooling problem, not a safety success.
Escalation in YATFA
Escalation is a first-class state in YATFA: an agent that cannot resolve an obstacle stops the ticket into a dedicated escalations queue with its failure history attached, the work sits parked rather than looping, and the resolution reaches the ticket as a recorded answer the next run starts from. The queue itself is a working surface — see escalation in YATFA.
Frequently asked questions
Isn't escalation just failure?
No — it is the designed outcome for a specific class of obstacle: decisions outside the agent's authority, contradictions in the brief, environments it cannot reach. The failure modes are the alternatives: looping and improvising. An agent that never escalates is either perfect or hiding its stuck cases, and the base rates say the second.
How many retries before escalating?
Enough to absorb transient noise — a flaky network call, a slow dependency — and no more. The useful rule is not a global number but per failure class: transient errors retry with backoff; the same substantive failure twice in a row escalates, because the third attempt is not information, it is hope.
Who should resolve escalations?
Whoever holds the decision the agent cannot: scope and priority questions go to the owner, requirement contradictions back to the brief's author. The escalation record should name the kind of decision so it routes correctly instead of pooling in one inbox.