Where the human checkpoint goes

Picture an agent that helps run a small internal tool. This is a hypothetical, an illustration I made up to make a point, not something that happened. One afternoon it is asked to tidy up stale records. It finds a batch that looks abandoned, deletes them, and posts a friendly summary to a shared channel. Nobody approved the deletion. Nobody approved the message either. Both were within what the agent had been allowed to do, because nobody had decided where the line was.

After a step like that goes out, the natural reaction is to add a gate. Then another. Within a week, every action the agent takes asks a person to click "approve," and within two weeks the person is clicking without reading. I want to talk about that, because it is an easy mistake to make after the first one, and it ends in the same place.

This is an opinion piece about building agents, and here is my claim. I think approval gates belong at a few chosen points, not on every step. Where those points go is a design decision, and it deserves more thought than it usually gets.

Two ways to get it wrong

The first failure is no gate. The agent has a broad set of permissions, and things go out unreviewed because nothing in the design said they shouldn't. The example above is that. The cost shows up late, and it shows up outside the team, which is the worst place for it to show up.

The second failure is a gate on every step. It looks like the responsible fix. In practice, a checkpoint that fires constantly stops being a checkpoint. The approver learns that nearly everything is fine, so the click becomes a reflex. The gate is still there in the diagram, but the attention is not. You have kept the ceremony and lost the protection, and you have also made the agent slow to the point where people start looking for ways around the prompts.

I do not have data on how often either failure happens, and I will not pretend to. I am reasoning from how people behave when they are asked the same question over and over. Treat it as an argument, and check it against your own experience.

A plain rule for choosing where

If a gate on every step is too many and no gate is too few, you need a way to choose. Here is a rule of thumb. It is three questions about an action.

Is it reversible? Renaming a local variable is. Sending an email is not. Deleting a record might be, if you have a backup and someone remembers to restore it, which is a different thing from being easy to undo. The less reversible an action is, the stronger the case for a gate.

Who sees it? Something that stays inside the working session can be wrong for a while without much harm. Something that lands in front of a customer, a teammate outside the project, or the public is a different category, because you cannot take back the fact that it was seen.

How expensive is a wrong answer to fix later? This question is the one that catches things the first two miss. Some actions are technically reversible and invisible, and still cost a lot to unwind because other work has been built on top of them by the time anyone notices.

An action that scores badly on any of those is a candidate for a gate. An action that scores well on all three usually is not, and asking a human about it is spending their attention on something that will be fine.

The three gates I would start with

From that rule I end up with three places, and I would start there before adding anything.

The first is before anything irreversible. Deletions, payments, migrations that cannot be rolled back, anything where "undo" is a recovery project. The agent proposes, a person clears it, and only then does it run.

The second is before anything that goes outside the team. Messages to customers, public posts, anything a person outside the working group will read. The point is not that the agent writes badly. It is that once something is out, the only correction available is another public message.

The third is at the plan stage. Before the agent starts executing a multi-step piece of work, a person reads what it intends to do. I think this one is the highest leverage of the three, for a simple reason. Changing a plan is cheap. It is a few edits to text that has not been acted on yet. Changing finished work is not cheap, because by then it has consequences: files rewritten, messages sent, follow-on steps already taken. The same objection costs a sentence at the plan stage and a cleanup afterward.

The plan gate also tends to make the other two lighter. If a person has read and shaped the plan, the irreversible and outbound steps in it are no longer surprises when they arrive.

What a good gate needs

A gate is only as good as what happens at it. I would look for three properties.

The reviewer sees exactly what will happen. Not a summary like "updating records," but the specific records, or the specific text that will be sent. A gate that hides the details is asking for trust, and trust is what the gate was supposed to replace.

The reviewer can say no, and mean it. That sounds obvious, but a gate where declining breaks the workflow, or where the agent simply asks again in slightly different words, is decoration.

The answer reaches the agent. A "no" that lives in someone's head, or in a chat thread the agent never reads, changes nothing. The decision has to land where the agent, or the session that holds its context, can act on it.

At the plan stage, that can be as ordinary as a document. Plan-stage review can mean a reviewer commenting on a live file, in a browser and with a sign-in, before the agent executes, and Gander is one place to do that. It is one way to place the gate, and the argument here does not depend on it.

How we handle it

We follow one rule ourselves, and it is a simple one. Nothing we publish or send goes out without a person clearing it first. That is the whole claim. I am not describing how many things that has caught or how it has performed, because I do not have that to offer, and it would not change the reasoning above.

What I will say is that a rule this narrow should be easy to keep, because it applies to the outbound edge, which is a small, clear boundary. A rule that tried to cover every intermediate step would be hard to follow, and I suspect it would be followed less.

Attention is the thing you are designing

The reframe I would leave you with is that a checkpoint is not a brake on the agent. It is a decision about where human attention gets spent. People have a limited amount of careful reading in them on any given day. Every gate draws on that supply, whether you meant it to or not.

So the question to ask about a gate is not "is this safer?" It is "is this the best place to spend a person's attention?" A gate before something irreversible passes that test almost every time. A gate on a step that could be repeated harmlessly a hundred times usually does not.

If you are deciding what an agent may do alone, start from the other direction. Assume it may do most things, and list the few actions where a wrong answer is permanent, public or hard to unwind. Put the person there, put the plan stage in front of them, and let them read closely. A small number of well-placed gates that people actually read is worth more than a wall of prompts that they click through.