Human override is a Queue

Doesn’t it look pretty?

Human override is a Queue

Martijn Veldkamp

Martijn Veldkamp

Published Oct 7, 2026

+ Follow

We are delivering systems where we bolt on AI and put a human in the loop. And by doing so we gave her 4,000 decisions before lunch.

That sentence could describe more then half the AI plans I have read. The diagram are very reassuring. They look so good. An agent does something clever, a decision shape asks whether approval is required, and a “responsible” human appears in a box before anything dangerous happens. Look, control!

The box never needs coffee, never has another meeting and apparently reads at the speed of light. A remarkable employee, we should hire more /s. (for those that do not know that /s means it is meant as a sarcastic sentence)

In production, of course, the human is a person with a queue. The decisions arrive at some rate, each decision takes some amount of attention, and the person usually also has an actual job. If arrivals exceed attention for long enough, the queue grows. Once the queue grows, one of 3 things happens: the automated process slows down, the review becomes superficial, or somebody quietly changes the rules so fewer things require review.

Usually all of those, in that order.

The approval-shaped button

I wrote in Can You Handle It? that autonomy requires us to decide what we are willing to delegate. Later, in The Delegation Illusion, I argued that the liability often stays behind even when the task moves.

I think that the designed human override sits exactly between those two. It is supposed to be where judgment catches what automation cannot. That is such a nice sound bite, I should use that more. But judgment is not just a button, and adding a button does not create true evaluation or even judgment capacity.

You see the same thing at airport passport gates. The machine handles the normal traveler quickly until a passport will not scan, a ticket has a crease in the QR code, a face does not match or somebody stands on the wrong footprint. Then one employee is suddenly responsible for 8 gates, 4 blinking lights and a family that has placed a toddler in front of the camera. The automated lane did not remove the exception, it collected these exceptions faster.

That can still be a good system. The normal cases move faster and the employee focuses on situations that need a person. But only if the exceptions remain exceptional. If every third passenger needs help or attention, you have not delivered automated passport control, but a very efficient queue generator.

Review has a capacity

Some of these architecture diagrams treat human approval as binary. Present or absent. I think we need to treat it as a service with capacity, latency and failure modes.

I have so many questions. How many decisions arrive in an hour? How long does a real review take? What information does the reviewer receive? Can they understand why the agent chose this action, or are they approving a conclusion attached to 6 pages of generated confidence? What happens while the reviewer sleeps? What happens when 3 people are ill and the quarter ends on Friday? How do we keep track of human decisions and their effects?

Those questions belong in the control design.

Because if you think about it: If a meaningful review takes 5 minutes, one person has a theoretical maximum of 12 per hour. The real number is lower because humans are inconveniently human. They need context switches, toilet breaks and the occasional moment to wonder whether approving things all day was what their parents hoped for them… Erm, you know that glorious corporate career.

Send 60 decisions an hour into that control and the governance has already failed. The approvals might still happen, because people are wonderfully adaptable. They gamify the system, the scan, develop shortcuts, trust the green confidence number and click. The human remains in the loop on paper while disappearing from the decision.

A decorative layer of accountability

That decorative layer is even worse. When something goes wrong, the organisation can point to the approval. The reviewer clicked, never mind that the system made careful review mathematically impossible, by machine gunning decisions all morning.

Escalation is the design

My thinking is that we should design only the few things that genuinely deserve human attention, and arrives with enough context for that attention to matter. I know, rocket science it ain’t!

That means designing escalation, not adding approval. Designing a mandate where both agent and employee have clear boundaries.

And we need an improvement feedback loop. Low-impact, reversible actions can proceed inside a bounded policy. Strange, high-value or irreversible actions stop. Repeated decisions should become better rules or better automation, otherwise the human queue becomes permanent unpaid integration logic. And the reviewer needs authority to reject the action without being punished for slowing the throughput metric.

Developers can help by making uncertainty and provenance visible instead of returning one polished answer. Architects can design the failure path with the same care as the happy path. Leaders have to fund review capacity and accept that genuine oversight places a limit on volume.

That last part tends to be unpopular. We want autonomous scale and human accountability at the same time, preferably with no additional people and a dashboard by Monday. But accountability does not scale because a diagram says it does.

Before approving a human-in-the-loop design

I would ask to see it under load. Not a demo with 5 well-behaved examples. Give it a production-shaped day, including ambiguous cases, missing data, retries and the one customer who uploads a photograph of a document displayed on another phone (there is always one).

And then do the normal business process design stuff. You know, count how many decisions have an escalation. Measure how long a careful review takes. Watch what people do when the queue turns red. A control that only works while everyone has time is a hoping for a happy path with an approval button.

I think that the risk is oversight that remains visible enough to satisfy governance while becoming too overloaded to change an actual outcome.