You want to automate something, but you're afraid of losing control. So you're stuck between two options, and both are bad.
Option A: approve every step. Safe — but you've just turned yourself into a "continue" button, and the agent's whole speed advantage evaporates. Option B: let it run to the end and look afterward. Fast — but you're praying, and the previous piece in this cluster already covered how hard autonomy can bite back.
The problem isn't that you picked the wrong one of the two. It's that you think there are only two.
01That binary is false — and it charges you at both ends
The two options look like the two ends of a dial: safety here, speed there, you slide back and forth hunting for balance. But it isn't a dial. It's two poles, and both poles bill you.
Babysitting every step: you pay with your own time — and worse, your attention thins out after the tenth step, so you're watching without really looking. Letting it run to the end: you pay by only finding the error once it's already too deep to fix cheaply.
The third way isn't between the poles. It's on a different axis: instead of asking "how much to approve?", ask "where to approve?"
No stopping at every step, no eyes-shut to the finish. Two gates placed at the two points of no return — between the gates, it runs at full speed.
02A gate isn't for watching what it does — it's for blocking what can't be undone
This is the easiest part to misread. A mid-run gate sounds like a lighter version of "babysit every step" — pause to glance at what the agent is up to. It isn't.
A gate placed right isn't for you to observe. It's for you to decide — right before an action that can't be taken back. The agent can run thirty steps without a single one being worth stopping for, then hit exactly one: overwriting real data, sending something outward, locking a branching choice that shapes everything after. That's where a gate belongs.
Notice this is a different thing from splitting work into phases. Splitting phases rearranges the workflow. A mid-run gate inserts a human yes into a run the agent is still driving itself — it doesn't touch how it runs, it just watches for the threshold where it's about to walk through a one-way door.
03Where the gates go: three kinds of point worth stopping for
Not every step. Just three kinds of point — and there are usually fewer of them in a task than you'd guess.
Overwrite, delete, send, publish, charge — any move where "undo" doesn't exist or is expensive. Put the gate right before it. Let the agent build the draft up to that point; only the final commit needs your hand on it.
The moment a result reaches someone else — a client, a colleague, a downstream system — is the last place you can still catch an error before it becomes their problem. One verify gate here is worth ten checks after it's already gone out.
When the agent is about to pick a direction everything downstream depends on — choosing an approach, locking a big assumption — a wrong turn here multiplies through the whole chain. A nod at the fork is far cheaper than turning the whole convoy around later.
The executable line fits one template: "Run on your own until you reach <this point>, then stop and wait for my approval before continuing." You're not describing what it should do — you're naming the exact threshold where it has to halt.
04The gate changes the size of work you'll even hand over
The real payoff of a mid-run gate isn't just catching errors. It's that it changes what you dare to delegate.
When the only options are watch-it-all or let-it-all-go, every high-stakes task gets pulled back toward "I'll just do it myself" — because letting go is scary and watching leaves no gain. Once you know how to place a gate, that ceiling lifts: you can hand off bigger, scarier work, because you've decided in advance exactly where you'll step in. Everything else, you let go for real.
Autonomy doesn't grow with how much nerve you have. It grows with the quality of the gates you know where to place.