The Approval Checkpoint: Where a Human Still Has to Say Yes

It works. You have tested it. And you still cannot quite bring yourself to leave it running overnight.

That hesitation is not timidity and it is not a gap in your understanding. It is the correct response to the one thing about these systems that does not improve with better models, and the sooner you build for it the sooner you can actually let the thing run.

A system has no sense of magnitude.

Here is the mechanism, and it is worth reading slowly, because everything else in this post follows from it.

Somebody writes: send a thank you discount to our best customers.

To a person, that instruction has an obvious limit sitting inside it. Best customers means a few dozen people, the ones who buy regularly, and if the list came back with nine thousand names on it you would stop and ask.

To a system, there is no limit inside the sentence. It resolves best customers to whatever it can find that fits, which might be everyone with an account, and then it sends. Sending to forty people and sending to nine thousand are the same action performed a different number of times. There is no point in the process where it feels a lurch.

That is not the machine being reckless. It is the machine having no way to know that one of those outcomes would end your week.

There is a second, smaller risk worth naming once. If your system reads text that came from outside, from an email or a form or a web page, somebody can write instructions in that text hoping the system follows them instead of yours. It is uncommon and it is real, and it is another reason that anything reaching the outside world gets looked at first.

Permissions come before checkpoints.

Before you build a single approval step, take things away. This costs nothing and it removes most of the danger.

Give each automation only the tools and data its actual job needs. The one that summarises website traffic does not get access to the customer database. The one that drafts replies does not get the ability to send them. The one that reads invoices does not get permission to delete anything.

This is the cheapest safety you will ever buy, because it does not depend on the system behaving well. A workflow cannot do damage with a tool it does not have. Everything after this is about the actions you deliberately decided to allow.

The free AI Agents pack. The decision checklist for this is in there, the one I use to work out what may run without a human. It comes with over two thousand ready-made n8n workflows, a workbook on the twenty building blocks that cover most of them, and the Agent-Plus Prompt Builder for writing agent instructions. Download the AI Agents pack →

The three questions.

Copy this. Run every action your automation can take through it, once, before that automation goes live.

01 · Does somebody outside your company see it? An email, a message, a published page, a reply to a customer. Anything that leaves the building. 02 · Does it touch money? Refunds, invoices, discounts, orders, subscriptions, anything with an amount attached. 03 · Could you undo it in five minutes? Not in theory. In practice, on a Friday evening, with the tools you actually have.

A yes to the first or second, or a no to the third, means that action stops and waits for a person. Everything else can run.

Most of what your workflow does will pass. Reading, sorting, drafting, filing, enriching, summarising: none of that needs you. The list of things that genuinely need a human is usually three or four actions long, and it is almost always the same three or four. Sending to a list. Moving money. Deleting records. Publishing.

Make it a threshold, not a switch.

The version of this that survives contact with real work is not on or off. It is a line with a number on it.

Refunds below a set amount go through. Above it, somebody looks. Messages to one person go. Messages to more than a handful wait. A confidence score below your chosen level hands the task to a human instead of guessing.

Both Make.com and n8n let you build this as an ordinary step in the flow, and it is the same shape in both: the run pauses, a message goes to wherever you actually look, and the rest of the workflow continues when you say so.

Pick the number now, while nothing is at stake. Picking it during an incident is how people end up switching automation off entirely.

The same instruction, with and without.

Without a checkpoint. The instruction goes in and ninety seconds later the discount has gone to the entire contact list. Nothing can be recalled. You spend the next two days writing an apology and honouring a discount you did not intend to offer.

With a checkpoint. The system prepares the message, resolves the audience, and stops. You get one line: here is the message, here is who it is going to, here is how many. You read the number, notice immediately that best customers was never actually defined anywhere, fix the definition, and approve. Total cost to you: thirty seconds.

The system did the same work in both versions. The only difference is that one of them had a place to be interrupted.

Write down what it decided.

One more thing, and it takes ten minutes to set up.

Keep a record of what the system did and what it was working from when it decided. Which path it took, what it retrieved, what it sent, and when.

You will not read these logs. That is fine. They exist for the single day when somebody asks why a customer received something, and without them you cannot answer, because the run happened once, in the middle of the night, and reconstructing it afterwards is guesswork.

What this will not do.

A checkpoint does not make the system safe. It makes the mistake catchable. Those are different claims and only one of them is true.

It slows things down, and it is supposed to. If you find yourself approving without reading, you have not built a checkpoint, you have built a rubber stamp, and it is worse than having none because it feels like protection.

It does not move the responsibility. If it goes out under your name, you sent it. That is not a legal opinion, it is just how the customer will see it, and they are not wrong.

And it does not answer the prior question, which is whether this task needed to run unattended at all. Plenty of them do not.

One small thing to do before the next post.

List every action your automations can currently take that you could not undo in five minutes.

Just the list. No changes yet.

For most people it comes to three or four lines, and seeing them written down together is what turns the vague reluctance to leave it running into a specific, buildable piece of work.

If you want the whole thing in one place.

If you would rather have the complete system than one piece at a time, that is what I wrote AI Agents Bible for. Five books in one, with Custom GPTs, Make.com and n8n each built step by step, thirty worked examples you can copy, and the parts most guides leave out, about cost, reliability and knowing what not to let run on its own.

Both this and the prompt engineering book also come as one 12-in-1 volume, if you would rather have the whole system in a single place.