The alarm no one caught
Walk into any operations centre and you will find a wall of alarms. Reds, ambers, badges with counts on them. The system is, in a narrow sense, working — it noticed the thing. The question that decides whether the thing gets handled is never asked on the demo: did the alarm reach a person who could act, and did that person know it was theirs?
We have watched the same failure in a hospital command centre, a building portfolio, and a defence watch floor. An automated agent — or a junior operator — raises a flag. The flag goes up. And then it goes nowhere. It sits in a feed that scrolls. It posts to a channel no one owns after 1700. It expands a counter that everyone has learned to ignore. The signal was generated and the signal was lost, in the same breath.
Escalation is the part of an autonomous system that everyone assumes works and almost no one builds. This is a note about why it is hard, what an escalation actually is, and what it takes to make one that arrives.
Three ways an escalation dies
We have catalogued the ways escalations fail, and they collapse into three.
It never leaves the tab. The most common, and the most embarrassing. The escalation lives in the memory of the session that raised it. The operator closes the laptop, the serverless function recycles, the page reloads — and the escalation is gone, because it was never written down anywhere durable. It felt real on screen. It had no existence the moment the screen went away.
It reaches a queue no one owns. The escalation persists, but it lands in a shared inbox, a firehose channel, or a list that belongs to everyone and therefore to no one. Diffusion of responsibility does the rest. Three people each assume another is handling it. The escalation is technically present and functionally invisible.
It arrives without enough to act. The escalation lands, on the right desk, owned — and says something happened. No context, no evidence, no proposed action, no way to see why it was raised. The recipient now has to reconstruct the situation from scratch before they can decide. Most do not. They snooze it.
An escalation is a transfer of custody
The reason these failures keep happening is that most systems treat escalation as a notification. It is not a notification. An escalation is a transfer of custody — a decision moving from someone, or something, that cannot or should not resolve it to someone with the authority and context who can.
Custody is the operative word. When a security guard hands a detainee to a police officer, custody transfers, and there is a signature. When a duty nurse hands a deteriorating patient to the rapid-response team, custody transfers, and there is a record. The point of the record is not bureaucracy. It is that responsibility has unambiguously moved, and both sides know it.
A software escalation has to clear the same bar. Something held a decision; now someone else holds it; both ends agree on who. If you cannot point to the moment custody transferred and the party who now owns it, you do not have an escalation. You have a notification that you are hoping someone reads.
Durable by default
The first property is the unglamorous one: an escalation must outlive the thing that raised it. It has to survive a page reload, a process restart, the operator logging off, and the agent that emitted it being scaled to zero. If the escalation only exists in runtime memory, it is a rumour, not a record.
This sounds obvious until you audit how often it is violated. Per-session state is the default in most frameworks because it is the easiest thing to build and it demos perfectly. The escalation appears, the room nods, and nobody reloads the page. The gap only shows up at 0300 when the function that held the alert has long since recycled and the alert is simply not there anymore.
Durable by default means the escalation is written to a store that survives all of the above before it is ever shown on a screen. The screen is a view of the record. The record is the escalation.
It has to reach a second account
The second property is that an escalation has to leave the originator. This is the property that the word itself implies and that systems most often quietly drop. An escalation that lands back in the raiser's own view is not an escalation. It is a to-do list.
Custody cannot transfer to yourself. The whole point is that the decision has moved to someone with more authority, more context, or simply a fresh pair of hands on a different shift. That means the escalation has to be visible in a second account — a watch officer, an on-call lead, a supervisor — who did not raise it and who can see it land in their own queue, attributed, owned, and waiting.
The test is brutally simple and almost never run: raise an escalation, sign out, sign in as the person who is supposed to receive it. Is it there? In most systems the honest answer is no.
Arriving with enough to act
The third property is that the escalation has to carry its own case. A custody transfer with no context forces the recipient to re-investigate, which means the escalation has not saved any work — it has just moved the work to a more expensive person.
An escalation that arrives well carries the proof packet that justified it: the signal that triggered it, the reasoning that classified it as worth raising, the action being proposed, and the reversibility of that action. The recipient should be able to read the case, agree or override, and have their decision recorded — in seconds, without leaving the escalation to go reconstruct the world.
This is where escalation stops being a messaging problem and becomes an evidence problem. The same provenance spine that lets an agent justify an action it takes on its own is what lets an escalation justify itself to the human who inherits it.
What we built
In our platform, an escalation is a first-class object, not a message. When an agent or an operator escalates, the call writes a durable record before anything renders — typed, attributed, carrying its evidence — and chains it into the same ledger every other action is written to. It is durable from the first instant, because it was born as a record.
That record is then mirrored into a second party's inbox — a watch officer's queue that lives in a different account from the one that raised it. The recipient sees it arrive, owns it, and can acknowledge or resolve it. The status round-trips: the moment they act, the state changes everywhere, durably, so the next person to look knows it is handled and by whom. Custody transferred, and there is a signature on both ends.
None of this is exotic. It is the boring discipline of treating an escalation as a record that must persist, must move to someone else, and must carry its case — applied without exception. The engineering is modest. The decision to do it at all is the rare part.
Why most platforms skip it
Escalation is invisible in a demo. The demo shows the agent being clever — fusing signals, drafting an action, catching the anomaly. It ends at the moment of detection, which is the moment that looks impressive. What happens after detection — the unglamorous handoff to a tired human on a night shift — is exactly the part a demo has no reason to show and every reason to skip.
So the incentive of the whole industry points away from building this. The procurement watches the catch. The operator lives with the handoff. The gap between those two audiences is where escalations go to die, and it is the same gap we keep finding under every other operational failure: the system was built for the person evaluating it, not the person running it.
The test to bring to a procurement
If you are evaluating any system that claims to escalate, do not ask whether it can raise an alert. Everything can raise an alert. Ask for the handoff, and run it yourself.
Have it escalate something. Then reload the page — is the escalation still there? Then sign in as the person who is supposed to receive it, on a different account — has it arrived, attributed and owned? Then open it — does it carry enough that you could decide right now, without going to ask three other systems what happened? Then resolve it — does everyone else now see that it is handled?
Four steps. Most systems fail at the first. The ones that pass all four are the ones that understood the unglamorous truth: the catch is not the product. The arrival is.