Gate What Your Agent Can't Undo

Gate what your agent can't undo, and stop gating everything else.

Most deployments I see described do the opposite. One approval rule gets picked at deploy time, pointed at every action the agent takes, and never touched again. That is not an agent. That is a form a human signs forty times a day, and it explains most of the stories about automation that somehow saved nobody any time.

The line is reversibility

The question that decides where a gate goes is whether the action can be taken back. Not how nervous the work makes you, not how senior the person on the other end is, not how important the department sounds. Those are the two questions that get confused, and confusing them is expensive in both directions.

A draft that sits in a folder is recoverable regardless of who eventually reads it. A payment that clears is not recoverable regardless of how small it was. Sort by what you can undo.

Human approval is not one universal boundary. There is no global setting you configure once and inherit everywhere, and no industry default that tells you where the line belongs in your shop. Invoice coding, customer replies, and inventory adjustments do not share a boundary just because they share a company. Each one has its own answer, and the answer is not sitting in the org chart.

You find the boundary by running it

A policy written before the system ever ran records what somebody was afraid of in a conference room. It does not record where the model is actually wrong, because nobody knew that yet. My bet is that the real failure modes are almost never the ones predicted in the planning meeting — they are narrow, specific, and tied to your data.

So the boundary gets discovered workflow by workflow:

1. Run the workflow with a person on it. 2. Log every place the agent was wrong, and be specific about the kind of wrong. "Bad output" is not a failure mode. "Miscodes freight when the invoice has two ship-to addresses" is. 3. Move the gate to those places. 4. Take the gate off the places it was never wrong. 5. Repeat next quarter, because the workflow changes and the answer moves with it.

That is the entire method. It is unglamorous, it requires somebody to actually keep the log, and it is the step teams skip when they substitute a policy for the engineering work.

Keep people close early — with a finish line

Early on, keep people closer. Not because the agent is stupid; it is usually fine at the task you hired it for. You keep people close because you do not yet know which part of this particular job it gets wrong, and that is local knowledge about your data, your exceptions, and your weird customers. No benchmark and no vendor page contains it.

The important part is that this period is a study, not a permanent condition. A study has a finish line and produces an artifact: a written list of failure modes specific enough to act on. If you are six months in and someone is still reading every output with day-one attention, either nobody wrote down what was learned or nobody was allowed to act on it. Both are management problems wearing a technical costume.

Practically, that means the early phase needs three things most pilots never set up: a log with a field for failure type, a named owner who reviews it, and a recurring date where gates get moved based on what the log says.

The line that never moves

Anything that cannot be recovered or easily reversed stays human-gated, permanently. Money leaving the building. A message landing in front of a customer. A record you cannot restore. A delete 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. It is a property of the action, not a property of your confidence.

Write your own list. It is shorter than people expect and it is specific to you. My bet is that in most workflows, the irreversible actions are a small slice of what the agent touches all day; the rest is drafts, proposals, staged changes, and queued items somebody can throw away. There is also an engineering move hiding in here: a lot of actions that look irreversible can be made reversible. Staging a change instead of applying it, holding outbound mail for a beat, keeping a restorable copy — every one of those converts a permanent gate into a recoverable action, and that is usually cheaper than paying a human to approve it forever.

Two kinds of approval, one folder

The core confusion is that two different things get filed in the same place.

One is a permanent gate: the action is irreversible, a person signs, end of discussion. The other 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 in the training-wheel category should be actively coming off, and that is the step 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 proved itself. Not everywhere at once, and not off a demo.

So run the test on yourself: when did you last remove an approval? If the answer is never, you are not running an agent, you are running a supervision job with a model attached. Approvals should come off on a schedule, in writing, with a name on the decision.

The cost of the "safe" default

Approve-everything gets treated as the free option, and it isn't. It feels responsible for about a week. Then the reviewer has seen four hundred correct outputs in a row and is no longer reading, just clicking. Now you have all of the delay and none of the oversight — worse than either honest choice, and it eats the productive gain the system was built for.

Find the boundary by running it. Keep people close while you are still learning the job. Gate what cannot be undone, forever. Take everything else off as the thing proves itself. 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.

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.

Sources