311 anomalies. 28 needed a human. Half never reached one.
A meta-analysis of the escalation boundary — the line where an autonomous control plane runs out of road and has to ask for help. The uncomfortable finding is not how often it had to ask. It is how often the asking itself failed.
The appealing version of autonomy is a system that never needs you. The honest version is a system that knows exactly when it does. This post is about the second one. We aggregated every anomaly our control plane raised over the same ten-week window behind our other field notes, and asked a single question: when an autonomous loop cannot fix something, what actually happens next?
The answer has two halves, and only one of them is comfortable. The system is good at knowing when to give up. It is surprisingly bad at making sure a human hears about it.
What we aggregated
These are the same production numbers behind our posts on goal self-pruning and silent-success failures, viewed from a third angle: not what the agent achieved, and not how it lied, but where the boundary of its autonomy actually sits. Every figure below is a live row in our agent-operations database, not a projection.
Headline read: nine in ten anomalies the system fixed on its own. That is the number a vendor puts on a slide. The number that matters is the one underneath it — what happened to the nine percent that it could not.
The bounded envelope: try twice, then escalate
Our control plane does not escalate on first contact. It caps autonomous self-repair at two attempts and only escalates an anomaly once it has genuinely exhausted those attempts. That cap is the difference between a self-driving system and a self-repairing one: a self-repairing system has to know, precisely, when to stop.
The clean fact inside that table: every anomaly the control plane actually resolved, it resolved in one try or fewer. None of the 271 self-resolved cases needed a second attempt. The 14 that hit the cap were the 14 that genuinely ran out of autonomous road — they tried twice, stayed broken, and were correctly handed upward. That is the envelope working exactly as designed.
The uncomfortable half: the ask that never landed
Now the part we would rather not publish. Of the 28 anomalies that escalated to an operator, only half got there because the system had exhausted its repair options. The other half escalated for a different reason: the operator push itself failed to deliver.
This is the failure mode that scared us most while writing this. The system did the hard, noble thing — it recognised it was beaten and decided to involve a human — and then the channel that carries that decision broke. Fourteen times, an anomaly that had legitimately exhausted autonomy sat in an escalated state not because nobody cared, but because the notification never arrived. A control plane that never escalates is dangerous. A control plane that escalates into a void is worse, because it feels like the first one.
Why single-anomaly monitoring misses this
Looked at one anomaly at a time, the lost pushes are invisible. Each individual escalated row says “handed to operator” and looks resolved from the agent’s side. The gap only appears when you compare the count of escalations against the count of escalations that actually reached a human, and realise those two numbers are not the same number.
This is the same defining property of a meta-analysis we wrote about before, applied to a different question. A run-level check tells you whether this anomaly was handled. An aggregate check tells you whether the handling reached anyone. The second question is the one that protects you; the first is the one most dashboards answer.
The fix: treat a failed push as the failure it is
The repair followed directly from the framing. A failed operator push is not a delivery problem to retry quietly; it is an anomaly in its own right, the same severity as the thing it was trying to report. We now re-classify a lost escalation as an open control plane issue rather than a closed notification, so the system cannot quietly mark an unreachable human as “done”. The boundary of autonomy is only meaningful if the act of crossing it is observable.
The honest ratio
We keep publishing the same uncomfortable ratios because they are what make the rest of the numbers trustworthy. Across 969 tracked issues, 112 reached done — roughly one in nine, the rest blocked, superseded, or reabsorbed. Across 484 goals the agent set itself, 222 were achieved and 217 cancelled. An autonomy story without those numbers is a story that is hiding its cancellations.
The lesson from the escalation boundary is narrower and harder to hear. The measure of a trustworthy autonomous system is not how rarely it asks for help. It is how reliably the asking actually reaches a person when it does.
The ANIA promise
Autonomy is only real where the boundary is honest.
We build ANIA in the open — including the meta-analyses of where our own control plane ran out of road. If field notes on the honest edges of autonomy are useful to you, follow along.
Try ANIA free