Every worry about letting software run your operations comes down to the same sentence, whether or not anybody says it out loud.
What if it does something stupid, fast, and nobody notices until it has done it four hundred times?
That is a reasonable fear and it deserves a real answer rather than reassurance. The answer is a specific piece of design called the gate, and where you put yours is the most important decision in the whole build.
What a gate actually is
A gate is a point where the work stops, on purpose, and waits for a person.
Not a notification. Not a log entry you could read later. A hard stop: nothing proceeds until somebody decides. The work sits there, visible, with everything already prepared — the document read, the fields extracted, the reply drafted, the numbers assembled — and a person makes the call.
The important half is what happens either side of it. Before the gate, everything is done for you. At the gate, nothing happens without you. Not a compromise between automation and control; both, in the right places.
Where gates belong
Four categories. If any step touches one of these, that step gets a gate, and it is worth being unbending about it.
- Money leaving. Payments, refunds, credit notes, anything that reduces what you are owed. No exceptions worth making here.
- Anything a customer sees. A message, a quote, an invoice, a status update. The system drafts it. A person sends it.
- Permissions and access. Who can log in, who can see what, who is added or removed. Quiet failures here are the expensive kind.
- Anything irreversible. Deletions, cancellations, submissions to somebody else’s system that cannot be recalled.
Everything else is a candidate for running on its own — reading, sorting, matching, calculating, drafting, moving, recording. Those are all reversible and all boring, which is exactly the definition of work that should not need you.
The two ways gates go wrong
Too few, and you have built something that can be wrong at scale. That is the fear at the top of this piece and it is a real failure mode. The tell in a proposal is that everything is described as fully automatic, with no screen where a person appears.
Too many, and you have built a form that emails you. This is the more common failure and nobody warns you about it. Every step needs a click, so the work still moves at the speed of somebody’s attention. Six weeks later the approvals get rubber-stamped without being read, which is worse than no gate at all — now there is a record showing a human approved something nobody looked at.
Which gives you the test that matters: a decision nobody has ever said no to is not a gate. It is a delay wearing a tie. Look at your existing approvals in whatever systems you already run and ask how many have ever been rejected. The ones that never have are ceremony, and they are training everybody to click yes without reading.
What has to be on the screen
A gate is only as good as what the person sees, and this is where most implementations are thin. When work stops for you, your screen needs four things.
- What it wants to do, in a sentence, in plain language.
- What it based that on — the source document, the message, the record. One click away at most.
- What it is unsure about, named specifically. “The total was hard to read” is useful. A confidence percentage on its own is not.
- What happens if you say no, and where it goes then.
If approving means clicking yes on a summary you cannot verify without opening three other systems, you do not have a gate. You have a rubber stamp with extra steps.
Why I hold this line hard
I build open-source tooling for governing AI agents in my own time. The core idea in it is that a piece of ordinary, inspectable code sits outside the model’s loop and judges the work by evidence and executable checks, never by how confident the model sounds. It is genuinely pre-release and its own README lists the gaps rather than hiding them.
That design came out of getting it wrong first. I built a hosting control panel fast, with an AI agent doing the typing and anime on the second screen. It was working, until it was not — hours gone to bugs that should never have existed, the agent reporting success while the code kept failing. Better prompts did not fix it, because prompting was not the problem.
Intelligence bolted onto a bad structure is not intelligence. It is faster chaos. The gate is the structure. It is the difference between a system that helps and one that is confidently wrong at a speed you cannot keep up with.
Place your own gates
- Take one process and list every step from arrival to finished.
- Mark each step against the four categories. Money, customer-visible, permissions, irreversible.
- Every marked step gets a gate. Everything unmarked is a candidate for running on its own.
- Now count your gates. More than two or three in one process and you should ask which are ceremony.
- For each one, write what your screen shows. If you cannot describe it, that gate is not designed yet.
- Audit the approvals you already have. How many have ever been refused? Ceremony is worth removing, not automating.
What to do next
Take one process, mark every step against the four categories, and count your gates. If you end up with more than two or three, some of them are ceremony — and ceremony is worth deleting rather than building.
Then audit the approvals you already have for how many were ever refused. If you want the rest of the machinery, the six parts covers where the gate sits among them.
If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.
Common questions
What if I’m away? Does everything just stop?
That is a design decision to make deliberately rather than discover, and it should be written down before build. Each gate needs a named alternate, and some gates should have a time rule — hold for four hours, then escalate to a second person. What you should refuse is a gate that quietly proceeds on its own after a timeout, because that turns your safety mechanism into a delay with an automatic yes at the end.
How is a gate different from the approval workflow our current system already has?
Frequently it is not, and if yours already stops work and shows you what you need, you have a gate. The differences that matter are whether it holds the work rather than just notifying you, and whether the screen shows the evidence rather than a summary. A notification you can ignore while the process continues is not a gate, whatever it is called in the menu.
Can the same system decide which items need a gate and which don’t?
Yes, and that is exactly where it earns its keep — routing the routine ones through and stopping on the unusual ones. What matters is that the rule for what counts as unusual is one you can read and change, not something buried in a model’s judgement. If nobody can tell you why this item stopped and that one did not, the routing is not inspectable and you should treat it with suspicion.
Doesn’t a human at every important step defeat the point of automating?
Only if you think the point is removing people. The point is removing the carrying — the gathering, re-typing, checking and chasing between decisions. A process with three genuine decisions in it should have three human moments, not thirty, and the thirty is what you have today. You end up making the same calls with better information and none of the assembly.
Leave a Reply