Each piece applies Seeing Like a Dashboard to one surface an AI system presents about itself:
- Who Tests the AI’s Tests? (the tests)
- A Compromised Node Will Attest That It’s Healthy (the self-report)
- Plausible Deniability Didn’t Die (the accountability)
- Human in the Loop Is Theater (the oversight)
The standard answer to "is it safe to let the agent do that?" is "we keep a human in the loop." It sounds like control, and up to a point it is. Past that point it inverts into its opposite: the better the automation gets, the less able the human becomes of catching the moment it fails. This is not a new discovery. Human-factors research has known it for forty years. AI deployment is rediscovering it as if it were fresh, and writing the same check anyway.
Vigilance is not a willpower problem
Start with the thing every "human in the loop" plan assumes a person can do: stay alert, watch a mostly-correct system, and catch the rare error. Humans are reliably bad at exactly this. In 1948, Norman Mackworth sat people in front of a display that simulated a radar watch and measured how well they caught infrequent signals. Detection fell off sharply after about half an hour, and kept falling.
The effect is so robust it has a name, the vigilance decrement, and seventy years of replication. It is not laziness or poor training. It is what human attention does when asked to monitor for rare events. Sustained vigilance over a quiet channel is one of the few tasks where the human is the unreliable component by construction.
So "watch the AI and step in when it errs" is a job description built around the single thing people cannot do well. The plan fails on contact with the wiring of attention, before anyone is careless.
The irony of automation
In 1983 Lisanne Bainbridge wrote the paper that should be taped to every AI governance deck. The "Ironies of Automation" argument is short and brutal: the more you automate, the more critical and the more demanding the human's leftover role becomes, and the less equipped they are to perform it.
Automate the easy ninety-nine percent and look at what is left for the person. They must sit through long stretches where nothing requires them, which destroys their alertness. Then, the moment the system hits the hard one percent it could not handle, they are expected to diagnose a novel failure instantly, with no warm-up, in a situation they have not been actively flying, and fix it under time pressure.
You have automated away precisely the routine practice that would have kept their skills and their context sharp, and then asked them to supply expertise and situational awareness on demand. The success of the system is what disqualifies the overseer.
You automate the part the human was good at, and leave them the part they are worst at: staying alert through nothing, then being brilliant on the first hard thing in hours.
Reliability makes it worse, not better
Here is the part that should change how people reason about this. The natural assumption is that a more reliable AI is safer to oversee. The opposite is true for the oversight itself. Trust calibrates to observed reliability: a system that is right almost every time trains its supervisor to stop checking.
The literature calls it automation complacency, and it scales with how good the automation is. A model that is correct 99.9 percent of the time is a model that has taught its reviewer, through thousands of green results, to rubber-stamp the next one.
So the protective value of "human in the loop" runs backwards to where you need it. When the system is shaky, the human stays alert and the oversight is real, but you did not need much oversight because failures are obvious and frequent. When the system is excellent, the failures are rare, subtle, and high-stakes, and that is exactly the regime in which the human has been lulled into not looking. The safeguard is strongest when it matters least and weakest when it matters most.
The failure rate and the complacency rate move together. The better the agent gets, the less its overseer is watching.
Speed removes what little chance was left
Suppose the human is, against the odds, paying attention. They still need time: time to notice, to rebuild context, to decide, to act. Agentic systems do not grant it. They act at machine speed and they fan out, so by the time a person registers that something is wrong, the action has executed and propagated to the next step in the chain. This is the same problem the acceleration argument raised from the other side: the consequence arrives before anyone is made to look.
Which exposes a quiet equivocation in the phrase itself. "In the loop" implies the human sits on the critical path, that the action waits for them. Most deployments put the human beside a stream of things that have already happened. That is "on the loop," not "in" it, and the entire safety claim lives in the preposition. A reviewer watching outputs scroll past is not a gate. They are an audience.
So most of it is theater
Put the four together, vigilance decays, automation hollows out the skill, reliability breeds complacency, speed outruns reaction, and "human in the loop" stops being a control and becomes a performance of one. It satisfies the governance checkbox and the liability narrative ("a human reviewed it") without delivering the intervention it implies.
| The overseer fails because | What it does to them |
|---|---|
| Vigilance decrement | attention collapses watching a quiet channel for rare errors |
| Automation irony | the practice that built the skill is gone, so they must be expert cold |
| Complacency | a reliable system trains the reviewer to stop checking |
| Speed | the action executes and propagates before anyone can react |
It is the human-factors twin of monitoring is not understanding. A dashboard turning red is not understanding, and a person assigned to watch the dashboard is not oversight. And it composes with the deniability problem in a grim way: the supposed overseer who was not really watching becomes the next layer of excuse. "The agent did it, and a human signed off" is a better alibi than either half alone, and you manufactured both.
A human who only watches a reliable system is not a safeguard. They are a witness you appointed in advance, so there is someone to have signed off.
What actually works
You cannot fix a vigilance problem by demanding more vigilance. Telling tired overseers to focus harder is the safety equivalent of "just be careful." The fixes are structural, and each one costs the thing you were chasing when you reached for full automation:
- Make the human's role active, not watchful. A person doing part of the task stays in context; a person only monitoring does not. Keep the human on the critical path for the decisions that matter, accepting the throughput hit, rather than automating everything and posting a guard. Participation sustains attention in a way that observation never will.
- Gate by consequence, not by uniform review. Asking a human to review everything guarantees rubber-stamping. Route the irreversible, high-blast-radius minority to a person given real time and real context, and let the reversible majority run unwatched. This is the grade-capability-by-what-can-be-proven instinct applied to oversight: spend the scarce human attention only where a mistake is expensive.
- Design for re-engagement, not for attention. Accept that the human will not be tracking the system, and build for the handoff: when intervention is needed, the interface has to rebuild their situational awareness fast, what the agent was doing, why, and what state things are in, because they have none after an hour of quiet. Nielsen calls this the open, unsolved challenge, and it is.
- Make reversibility the real safety layer. Since the human will not reliably catch the failure live, the thing that actually saves you is being able to undo it: feature flags, staged rollout, dark-launch in parallel before promotion, fast fleet-wide revocation. Bet the safety budget on rollback, not on the overseer's eyelids.
The two jobs of the phrase
"Human in the loop" is quietly doing two jobs. One is real, catching failures, and it mostly cannot do it, for all the reasons above. The other is rhetorical, locating the failure in a human who "reviewed" it, and it does that one extremely well. The first is what organisations claim they are buying. The second is what they usually get, and on a long enough timeline it is the only thing they were ever reliably going to get.
If the one thing standing between an agent and a costly mistake is a person watching it succeed, over and over, until the once-in-a-thousand failure slides past at three in the morning, you have not built a safety mechanism. You have appointed a witness, and made sure they would be tired. Put the human where they are doing something, or make the mistake cheap to undo. Watching is not a control, and we have known that since the radar rooms of the Second World War.
"Keep a human in the loop" sounds like a safety control. Past a certain reliability it flips: the better the automation, the worse the human is at catching the moment it fails. Human-factors research has known this for forty years, and it has three legs.
Vigilance. Monitoring a mostly-correct system for the rare error is the one thing humans reliably can't do. Detection collapses after about half an hour. It's how attention works, not laziness.
Skill. Automate the routine and the human is left to diagnose a novel failure instantly, cold, after the practice that built that skill was automated away. The success of the system disqualifies the overseer.
Complacency. A system that's right 99.9% of the time trains its reviewer to stop checking, so the safeguard is weakest exactly when failures turn rare, subtle, and high-stakes. And agents move faster than a person can react: "in the loop" usually means beside a stream of things already done, an audience, not a gate.
A watcher of a reliable system isn't a safeguard, just a witness you appointed in advance.
What actually works
You can't fix a vigilance problem by demanding more vigilance. The fixes are structural:
- keep the human doing part of the task, on the critical path, not just watching;
- gate by consequence: route the irreversible, high-blast-radius minority to a person with real time and context, and let the reversible majority run;
- design the handoff to rebuild their context fast, since they'll be disengaged when it's needed;
- bet safety on reversibility, feature flags, staged rollout, fast rollback, not on the overseer's attention.
Put the human where they're doing something, or make the mistake cheap to undo. Watching a reliable system is not a control.
Sources
- Lisanne Bainbridge, "Ironies of Automation" (Automatica, 1983): the foundational argument that automating the routine leaves the human a harder, not easier, residual job, and strips the practice that would let them do it.
- Norman H. Mackworth, the Clock Test (1948): the vigilance decrement, the measured collapse of human detection of rare signals after roughly half an hour of monitoring.
- Raja Parasuraman and Dietrich Manzey, "Complacency and Bias in Human Use of Automation" (Human Factors, 2010): automation complacency rises with the reliability of the system being supervised.
- Jakob Nielsen, "AI-First Companies" (2025): the "Boredom Problem" framing of oversight, and the ladder of AI autonomy that prompted this piece.