The Most Dangerous Process Is the One You Compiled

The execution gap everyone watches is the work that never gets done. The one nobody watches is the work that keeps getting done long after it should have changed.

The most dangerous process I ever inherited was one that worked exactly as designed. It was the customer-retention flow at TXU, the sequence meant to keep people from leaving when their contracts came up for renewal. Someone had compiled it years before I arrived: studied it until they knew it cold, optimized it, written it down, and locked it shut. And it was quietly losing us 25% of our customers in the five-month window around contract expiry (the two months on either side of the expiration month).

I use "compiled" on purpose, because it is what every company does to the work it understands best. You take a process you have run a thousand times, freeze it into a fixed sequence, and stop thinking about it. That is supposed to be a reward: you earned the right to stop re-deciding. The trouble is what gets frozen in with it.

It took me a while to see what was wrong, because nothing in that flow was broken. Every step did what it was written to do. It had been built by a capable team, blessed by Finance and Marketing, and then set down like wet concrete (nobody re-pours concrete). It had calcified. Nobody questioned it anymore, because questioning it meant reopening something everyone had agreed was finished. It was, in the most literal sense, a frozen answer: a good response to the question of why customers leave, locked in place long after anyone had checked whether the question still had the same answer.

We spend almost all of our attention on one kind of execution gap, the space between what a team means to do and what it actually does. The intent that never gets executed. That TXU flow was the opposite failure, and almost nobody is looking for it: execution that outlives its intent. The work keeps getting done, cheaply and confidently, long after the reason behind it has moved.

Correctness half-life

What I missed, and what the people before me missed, is that "runs constantly" had quietly turned into "must be right." Those are not the same thing. How often a process runs and how fast its right answer goes stale are two different measures, and they pull in opposite directions. The first is what makes freezing a process worth the effort: all that volume, all those savings. The second is what makes freezing it safe. Our retention flow scored high on the first and low on the second. It ran on every account, all the time, which is exactly why it felt like the last thing anyone should touch. But what it actually encoded, why people leave and what wins them back at renewal, was never stable for long. High volume, shifting ground. Every instinct said lock it down. The honest answer was: don't you dare.

Call it the correctness half-life: not how often a process runs, but how fast the right answer rots underneath it. A process with a long half-life can be compiled and left alone safely, because this year's answer is still good next year. One with a short half-life cannot, no matter how many times a day it fires.

And the damage stays hidden for a long time, which is the cruel part. When real software compiles, you can recompile in minutes: spot the problem, rebuild, ship. A process you have compiled into an SOP, or into a team's settled habits, has no such luxury. It keeps hitting its internal markers the whole time it is drifting away from reality. You find out the way I found out at TXU, the way most recovery problems surface: late, when the numbers stop adding up and someone senior finally asks why. By then the people who built the thing, the ones who would have felt the ground move, have long since moved on. The judgment that should have been re-examining it got optimized away the day everyone agreed the process was done.

AI is about to make this much easier to do

I have been thinking about that flow again, because AI is about to make freezing a process far easier than it has ever been. Today, when an AI agent runs a procedure, the steps still sit out in the open: you can read them and change one. This past spring, a team of researchers (Simon Dennis and colleagues) showed how to do away with that. You run the procedure a few thousand times, bake it straight into a small model, and from then on the model just runs the whole thing itself. In their test it handled a 55-step insurance claims process almost as well as a top model, at about a hundredth of the cost. They call it a "subterranean agent," and the name fits: the process slips underground, into the model's weights.

Unfortunately, that is also the most literal version of setting concrete I have ever seen: no one is ever going to review and improve that process again. A claims process is the perfect thing to compile if you only count the volume, and the worst thing to compile the moment you remember that the rules and the fraud and the regulation under it never stop moving. It is my old TXU flow on steroids: optimized once, set in stone, and someone threw the recipe away.

What reopening it was worth

At TXU, reopening that flow is what let us fix it. Once it was a live question again, we could pull every assumption buried inside it into the open and actually test them: A/B them one at a time, run the kind of big-data analysis that was just becoming possible in the early 2010s, and let the results decide. Attrition in that window went from 25% to 12%, and margin went up alongside it. That was not a lucky correlation, it was the measured output of those tests and the decisions we made because of them.

So before you compile anything, a human SOP or a model, ask the half-life question. If the answer is genuinely long, freeze it, bank the savings, take the senior person off it, and call that what it is: real maturity, but still assign it an expiration date. And if it is short, keep the process deliberate and a little more expensive than it needs to be, on purpose. That friction is not waste, it is your early-warning system, and the day you compile it away is the day you lose the ability to tell a process that is working from one that is merely still running.

If you want somewhere to start, pick the one you would least want to reopen, the process everyone agrees is settled, and ask it the half-life question. That is usually the one that has been quietly rotting the longest.