The Machine That Learned to Wait
The most consequential change in automated systems this decade is not that they got faster. It is that a few of them were taught to do nothing.
For thirty years the entire discipline pointed one way. Reduce latency. Shorten the loop. Get the response closer to the event until the gap between them stops being perceptible. It was a good direction and it produced a great deal of value, and somewhere around the middle of the last decade a number of people who build these systems began, independently, to suspect it had gone too far.
The suspicion arrived through failures rather than theory. A trading system that amplified a minor pricing error into a significant one before a human could see the screen. A logistics network that rerouted around a phantom delay and created a real one. A content system that responded to a spike so quickly it manufactured the spike it was responding to. In each case nothing malfunctioned. Every component did exactly what it was designed to do, at the speed it was designed to do it.
Deliberate delay as a design primitive
What is emerging in response is a set of techniques that would have been heresy a decade ago: systems that hold a decision for a defined interval, that require corroboration from an independent signal before acting, that damp their own responsiveness when input volatility rises above a threshold. Engineers call it different things in different industries. The common thread is treating delay as something you specify, not something you tolerate.
We spent twenty years removing every millisecond we could find. Then we spent three years putting eight hundred of them back, on purpose, in one specific place.
The engineering is less interesting than the organisational question underneath it. A deliberate delay is a cost that is visible on a dashboard and a benefit that is invisible by definition — it consists of the incidents that did not happen. Justifying it requires a form of argument that most performance-oriented cultures are structurally bad at making.
The corroboration principle
The most portable idea to come out of this work is corroboration: before acting on a signal, require a second signal that could not have been produced by the same failure. It sounds obvious. It is routinely absent, because a single high-quality input is cheaper than two adequate ones, and because correlated failure modes are hard to reason about until they occur.
- Identify the actions that are expensive to reverse. Those are the only ones that need to wait.
- For each, name a second signal with a genuinely independent failure mode.
- Specify the hold interval explicitly, and record what it prevented.
None of this is a retreat from automation. The systems being described are more autonomous than their predecessors, not less — they are trusted with larger decisions precisely because they have been given a mechanism for hesitation. The engineers who built them make the point almost identically: an automated system that cannot wait is not really making decisions. It is only reacting quickly, and reacting quickly to the wrong thing is the oldest failure there is.
Filed under