AI Escalation Workflow Design: From Nudge to Takeover

AI escalation workflow design is the written answer to one question: when an unattended agent fails, stalls, or goes quiet, who finds out, in what order, and at what point does a human take the work away from it? A good design has rungs. Detection first, then the owner, then a proposed fix, then a human with the authority to stop the agent. Each rung has a trigger you can point to.

This is part six of our governance series. The previous part covered the one channel our agents use to reach people. This one covers what travels down that channel when something breaks.

Why unattended agents need a ladder, not an alert

Agents rarely crash loudly. They stall, loop, or report success on work they did not do. METR’s research published 19 March 2025 found that the length of task frontier agents can finish with 50% reliability has been doubling roughly every seven months. That is real progress, and it also means that on any task near the edge of that horizon, about half the runs do not finish.

The OWASP Top 10 for Agentic Applications, released 9 December 2025, names two risks that make a single alert insufficient. ASI08 is cascading failures, where a false signal moves through automated pipelines and grows. ASI09 is human-agent trust exploitation, where a confident, well-written explanation leads a person to approve something harmful. An escalation ladder addresses both: it catches the quiet failure early, and it puts high-stakes calls in front of a person who is expecting to be asked.

Most companies have not rehearsed this. Grant Thornton’s 2026 AI survey (950 respondents, fielded 23 February to 18 March 2026) found only 20% have tested their AI incident response plans. PagerDuty’s survey of 1,500 executives, published 23 September 2025, found 81% trust AI agents to act on the company’s behalf during a crisis. The two surveys asked different groups, but the gap is plain: trust in agents during a crisis is high, and rehearsed plans for when they fail are rare.

The ladder as we actually run it

In our fleet, a tomte, our word for one production agent with one defined job, never decides on its own that its failure is fine. The ladder looks like this.

1. Detect. A runtime watchdog checks every scheduled job for four patterns: gone quiet, never succeeded, a streak of failures, or a missed deadline. A separate loop grades each agent as healthy, degraded, failing, or overdue.
2. Notify the owner. Every agent has a named human owner in its registration record. The alert lands as a task for that person, which also sends an email and an in-app notice. If the agent has no owner, or the problem spans several agents, it goes straight to the founder.
3. Propose a fix. A diagnosis step suggests one of four moves: rerun, re-authorise, investigate, or nudge the owner. It proposes only. Nothing executes at this rung.
4. Retry and verify. An approved retry re-invokes the stalled job, then checks that it actually recovered before closing the task.
5. Frozen items go up. Anything that sits for days with no change in state is flagged and routed to an owner task. Past a per-owner cap, the rest roll into one digest for the founder instead of a flood of separate alerts.
6. Take it away. A human flips the agent’s active flag off. It stops within one run cycle.

Who gets paged, and what happens when nobody answers

The page goes to a person, not a channel. Our registry makes the owner field part of what an agent needs before it runs, so an alert always has somebody’s name on it.

If the owner does nothing, the alert fires again each day the problem persists, throttled so it does not become noise. We chose that over an automatic jump to a manager after a set number of hours. A silent owner is itself a signal, and the frozen-item check is what catches it: the stalled work moves up the ladder on its own schedule, whatever the owner does.

Overdue human tasks run through a different test. A daily sweep asks whether the delay is excusable. If it is, the task goes back to whoever assigned it, since the plan was probably wrong. If it is not, it escalates to the assignee with the founder and HR copied. The task follow-up agent covers that side in detail. This post is about the agents themselves.

Severity decides the route

Every detected problem gets a severity: low, medium, high, critical, or unknown. Severity maps to a routing tier. Low items can be fixed automatically. Mid-range items go to the owner. The top of the scale goes to the founder. Unknown is its own grade on purpose, because a watchdog that cannot tell how bad something is should say so instead of guessing low.

Two decisions skip the ladder entirely and always need a human, whatever authority the agent holds: anything about hiring or firing, and anything above a fixed money threshold. No agent in our fleet can earn its way past either.

Rung	Trigger	Who acts	What it cannot do
Detect	Quiet, failing, never succeeded, overdue	Watchdog	Fix anything
Owner notice	Any detected problem	Named owner	Skip the owner if one exists
Proposed fix	Owner task opened	Diagnosis step	Execute without approval
Retry	Fix approved	Retry executor	Close without verifying recovery
Frozen item	No state change for days	Owner, then founder digest	Stay silent
Takeover	Human decision	Founder or engineering	Resume automatically

Handing the work back

De-escalation is deliberately dull. Resuming an agent is the same flag flipped back on. On its next cycle the agent picks up its queue where it stopped. There is no automatic resume, because an agent deciding that its own incident is over is the exact failure the ladder exists to prevent.

When the retry rung works, it closes its own task after it verifies recovery. That rule also blocks the ASI09 problem: the agent does not get to explain that everything is fine. The check does.

Where our escalation is still rough

We publish failures fixed, and some that are not fixed yet.

First, the automatic retry rung is documented as broken in practice. Its runbook tells operators to expect a manual approve-and-trigger instead. So today, rung four is a human pressing a button, and we would rather say that than draw a ladder with a missing step.

Second, our freshness watchdog once evaluated zero agents and zero runs for weeks and reported a clean success every time. A watchdog with nothing to watch looked exactly like a fleet with nothing wrong. We added a guard on 26 September 2026 that fails the check when its input is empty.

Third, one registered job has never fired at all. It has no failed run, so there is no failure row for any alert to trigger from. Watching for failures does not catch work that never started. Only a check on expected runs does.

Fourth, our reliability loop, which proposes fixes for the fleet, once filed a batch of proposals aimed at its own escalation logic. It now has a hard exclusion list. An escalation system should not rewrite itself.

Fifth, a note for anyone planning a go-live. During our dry-run week, chase messages were held back on purpose. On day one of go-live the whole week’s backlog went out as one batched message. That was by design, and it still looked like a bug to the people who received it. Warn them first.

What this costs to set up

This ladder runs across our own fleet. As of 30 June 2026 that fleet held 41 registered agents with 9 live in production, and the dated figures are in our agent fleet case study.

For a client, escalation design is part of the Fractional AI Officer retainer at $2,900 a month, cancel monthly. We register an owner for every agent, write the severity routes and the always-human decisions with you in writing, and hand over the watchdogs, the configuration, and the runbook. You own all of it.

If your agents can fail today without anyone’s name on the alert, start async. Describe what runs unattended and who would notice if it stopped, in writing, and we reply within one business day. No calls.