A service starts timing out intermittently after a routine deployment. Nothing looks particularly alarming. The deployment itself appears clean, the underlying systems are healthy, and latency has increased but not enough to trigger the usual alarms.
An engineer eventually notices that the slower requests are interacting with a retry policy. The policy is perfectly sensible on its own. If a request takes too long, try again. But under the conditions created by the deployment, some requests are taking just long enough to trigger retries. Those retries create additional traffic, which increases latency, which causes more requests to retry. Neither the slower requests nor the retry policy is enough to explain the problem by itself. The problem is in the interaction.
Once the team understands what happened, it can fix it. Maybe the retry policy changes. Maybe the timeout does. Maybe the system gets better monitoring for this particular pattern. The exact engineering answer isn’t important here.
What interests me is what the company learns.
The most immediate lesson is very specific: change this retry policy so this particular sequence can’t happen again. That’s useful, and it should be done.
But somebody looking at the incident might extract a broader lesson. When latency starts rising, watch for retries that can amplify the problem. That lesson could help somewhere else in the system, even where the exact policy is different.
Go one level higher and the lesson becomes broader again. When individual components appear healthy but the system isn’t, look at the interactions between them.
All three lessons came from the same incident. All three are useful. But something changes as you move from one to the next. The first tells you almost exactly what to do, but only in a narrow situation. The second travels further, but somebody has to decide whether the conditions are similar enough for it to apply. The third could apply to almost anything, which is precisely why it tells you much less about where to look.
The more portable the lesson becomes, the more judgment it takes to use it.
I’ve been thinking about that because it feels like the problem sitting underneath the series of essays I’ve been writing about AI and work.
In The Average Is Lying to You, I argued that when AI takes routine work first, the average can stop describing the work people actually do. In The Side Door Is the Whole Building Now, I looked at what happens when exception processes built for occasional use start carrying much more of the human workload. The Dollar Threshold Is Static. Risk Isn’t. was about what happens to authority when the remaining work needs more judgment, while The Work Was Doing Two Jobs was about what happens when some of the routine work disappearing was also how people became experienced.
Then in The Normal Case Was the Company, I started wondering whether these were really separate problems. We didn’t simply build processes around normal work. Much of the organization itself was designed around it.
There is one more piece of that argument I hadn’t considered.
Organizations have always had to figure out how to make what one person learns useful to somebody else. One of the best ways we’ve found is to turn experience into something that travels. A rule. A process. A checklist. A standard. A precedent. A test.
When the lesson generalizes cleanly, this works extraordinarily well. The next person doesn’t need to repeat the original experience because the organization has already extracted what matters from it. We shouldn’t romanticize judgment and pretend everything needs to remain inside somebody’s head. Much of the progress of management has come from doing exactly the opposite.
The interesting cases are the ones where the lesson travels but doesn’t quite tell you what to do.
Take the retry incident. The company can preserve the exact technical fix. It can also preserve the broader heuristic about retry amplification. It can record the engineer’s reasoning, the alternatives she considered and the evidence that changed her mind. AI should make all of that much easier. Instead of reducing an incident to a few paragraphs in a postmortem that nobody reads six months later, an AI system could retain far more of what happened and retrieve it when a new problem looks similar.
That could be a significant improvement in how organizations learn.
But suppose six months later another service starts behaving strangely and the system retrieves this incident. Now there is a different question. Is the new problem actually similar to the old one?
Perhaps both involve rising latency, but for completely different reasons. Perhaps both involve retries, but the retry behavior that mattered last time is irrelevant this time. Perhaps the new incident looks nothing like the old one at the component level but has the same deeper structure: several things behaving normally and producing an abnormal result when combined.
Which similarity matters?
That’s judgment again.
And there is no reason to assume it always has to be human judgment. AI may become very good at this too. It may compare thousands of incidents, recognize structural similarities that people miss and tell an engineer which previous cases are genuinely relevant. It may eventually become better than most people at deciding which old lesson belongs with which new problem.
But then another distinction appears. Two situations may be similar in nine respects and different in one. Does the difference matter? A pattern may have predicted the right action fifty times. Is this the case where following it for the fifty-first time creates the mistake?
The problem isn’t that judgment can’t travel. Organizations have been making judgment travel for a very long time, and AI may allow much more of it to travel than ever before.
The problem is that every time judgment travels from one situation to another, somebody or something still has to decide where it applies.
That has made me think differently about the Context Loop I described in Migrating Scarcity. I was interested in getting relevant context back to the point where a decision is being made. I still think that’s important. But having more context available doesn’t eliminate the need to decide which context matters. In some situations, it may make that question more important.
This is the same scarcity movement at another level. Solve the narrow technical problem and value moves toward recognizing the pattern. Get better at recognizing patterns and value moves toward knowing which pattern applies. Automate that discrimination and the valuable question becomes which difference should override the pattern.
There may not be a permanent line somewhere in this chain marked “human judgment.” I don’t think the argument needs one. AI may keep moving further along it.
What matters is what happens to the work each time it does.
If AI increasingly takes the situations where we already know what matters, the remaining situations will contain a larger share where figuring out what matters is the work. If AI gets good at those too, attention moves to the next distinction it cannot yet make reliably.
That is why I’m increasingly skeptical of discussions about AI that end when a task has been automated.
The task was never necessarily the final constraint. It was simply where the constraint happened to be sitting at the time.
Organizations know how to make lessons travel. Rules do it. Standards do it. Precedent does it. Experienced people do it. AI may become the most powerful mechanism we’ve ever had for doing it.
But every time a lesson arrives somewhere new, there is another decision hiding inside the transfer: does it apply here?
Perhaps AI gets very good at that too.
And then the scarcity moves again.