Gate What Your Agent Can't Undo, and Stop Gating Everything Else

Full episode transcript

Gate what your agent can't undo, and stop gating everything else. Most people are doing the exact opposite right now. They pick one approval rule at deploy time, point it at every single action the thing takes, and then wonder why nobody saved any time. That's not an agent. That's a form a human has to sign forty times a day. The rule I work from is that approval belongs on actions that cannot be recovered or easily reversed, and almost nowhere else. The line is reversibility. It is not how nervous the work makes you, and it is not how important the department sounds. Those two get confused constantly. A draft that sits in a folder for somebody to read later is recoverable no matter how senior that somebody is. A payment that clears is not recoverable no matter how small it is. Sort by what you can take back, not by what makes your stomach hurt. Here is how the bad version happens, and it is almost always the same four steps. Somebody stands the agent up. Somebody asks whether it is safe. Somebody sets approval to on for everything, because that is the answer that survives the meeting. Then it ships and nobody touches that setting again. None of that is stupid. It is a decision made at the exact moment you know the least about how this particular workflow goes wrong. So let me say the part people skip. Human approval is not one universal boundary. There is no correct global setting you configure once and inherit everywhere, and no industry default that tells you where the line goes in your shop. Invoice coding, customer replies, and inventory adjustments do not share a boundary just because they share a company. Each of those has its own answer, and the answer is not sitting in the org chart. A policy written before the thing ever ran is a guess wearing a suit. It records what somebody was afraid of in a conference room. Running it tells you where the model is actually wrong, which is almost never where anybody predicted. So you don't look the boundary up. You find it, workflow by workflow, by running the thing and watching where it goes sideways. That information costs you a few weeks of attention, and I don't know a cheaper way to buy it. The loop itself is not complicated. Run the workflow with a person on it. Log every place the agent was wrong, and be specific about what kind of wrong it was. Move the gate to those places. Take it off the places it was never wrong. Then run it again next quarter, because the workflow will change and the answer will move with it. That is the whole method. It is unglamorous, and it is the part everybody wants to skip. Early on, keep people closer. Not because the agent is stupid, it is usually fine at the thing you hired it for. You keep people close because you do not yet know which part of this particular job it gets wrong, and you cannot learn that from a benchmark or a vendor page. It is local knowledge about your data, your exceptions, your weird customers. The only way to get it is to run the thing while somebody who knows the work is still watching. Be honest about what that period is for, though. It is not quality control forever. It is a study with a finish line, and the finish line is a written list of failure modes specific enough to act on. If you are six months in and a person is still reading every output with the same attention they had on day one, either nobody wrote down what was learned or nobody was allowed to act on it. Both of those are management problems, not model problems. Now the line that never moves. Anything that cannot be recovered or easily reversed stays human-gated, permanently. Money that leaves the building. A message that lands in front of a customer. A record you cannot restore. A deletion with nothing behind it. That gate is not a training wheel. It does not come off with tenure, it does not come off because the agent had a great quarter, and it does not come off because clicking approve got annoying. Write that list down for your own shop, because it is shorter than people expect and it is specific to you. My bet is that in most workflows, the actions that cannot be recovered or easily reversed are a small slice of what the agent does all day. The rest is drafts, proposals, staged changes, queued items somebody can throw in the trash. If you cannot name your irreversible actions in one sitting, that is the real gap, not the permission setting. So there are two kinds of approval and they get filed in the same place, which is the whole problem. One kind is a permanent property of the action. It is irreversible, a person signs, end of discussion. The other kind is a training wheel. You put it there because you weren't sure yet, and it is supposed to come off. Treat both as permanent and you get a system that is expensive on the safe half and no safer on the dangerous half. Everything that is a training wheel, you should be actively taking off, and that is the part that never gets scheduled. You stop reading a good new hire's every email at some point. Not on a date written at orientation, but because they kept being right and you noticed. Same move here. The agent expands its autonomy as it earns trust, on real operation, in the specific place it has proven itself. Not everywhere at once, and not off the back of a demo. Here is a test to run on yourself. When was the last time you removed an approval? If the answer is never, you are not running an agent. You are running a supervision job with a model attached to it. Approvals should be coming off on a schedule, in writing, with a name on the decision, the same way you would hand a new person more rope once they earned it. If nothing ever loosens, nothing was ever learned. I want to be blunt about the cost, because approve-everything gets treated as the free option and it isn't. It feels responsible for about a week. Then the person clicking approve has seen four hundred correct outputs in a row, and they are not reading anymore, they are clicking. Now you have all of the delay and none of the oversight. That is worse than either honest choice, and it quietly eats the entire productive gain you built the thing for. So: find the boundary by running it, keep people close while you are still learning the job, gate what cannot be undone forever, and take everything else off as the thing proves itself. The agent earns trust like an employee does, on real operation, not on a policy somebody wrote before it ever ran. If your approval settings look the same today as the day you turned them on, you have not learned anything about your own workflow yet. That is the thing worth fixing.