We turn down one kind of AI automation request: one that takes an irreversible, external action with nothing between the model’s output and the consequence. What we build instead is usually the same automation with an approval step in the right place. This post sets out where those steps go, how we specify them, and when one is unnecessary.
What actually gets turned down
Not the requests people expect. Drafting, summarising internal data and first-pass sorting suit automation well, because a person reads the output before it has any effect outside the business. What we push back on is an automation that sends to a customer list, changes a live price or publishes content entirely on its own judgement.
The question is not how good the model is at the task. A model can draft an excellent customer email and still be the wrong thing to let send it unsupervised. A rare bad output in thousands of inboxes is expensive; a short human check is cheap. That asymmetry is the whole argument.
Why average accuracy is the wrong test
Illustrative: a model right 99 times in 100 is a strong result for most work. For an action nobody can take back, it means one public mistake in every hundred runs, and at volume that arrives quickly. The rarity is also why teams stop checking, right up until the failure happens.
Nothing about the model changes between a safe set-up and a risky one. The same draft is fine when a person approves it and risky when nobody does. Only the checkpoint moved.
Where we put the approval step
We place checkpoints by the class of action, not by how impressive the automation is. The table is the rule we scope from; the examples come from the kinds of build on our workflow automation and agent pages.
| Class of action | Example | Checkpoint |
|---|---|---|
| Internal and reversible | Summarise tickets, tag leads, draft replies into a queue | None before the action; spot checks and logging |
| External, reaching one person | A reply to a single customer or a public review | A person approves, edits or rejects each draft |
| External, reaching many people | A campaign send, a social post, a published page | Approval before the send fires, every time |
| Above a threshold you set | A discount, a refund, a spend, a purchase order | Approval above the threshold; below it, the action runs and is logged |
| A write to a system of record | Changing a live price, a CRM status or stock levels | The automation proposes the change and its reasoning; a person applies it |
In an n8n build, the checkpoint is a wait and approval step inside the workflow itself: a person approves, edits or rejects in the tool, and the workflow proceeds only once they have. In our n8n automation example, a discount above 15 per cent waits for approval.
For agents, which choose their own steps, the checkpoint attaches to the class of action wherever it falls in the run, because there is no fixed step to put it on.
How we specify a checkpoint in the scope
A checkpoint that is only described as “human review” tends to become a button someone clicks without reading. So each one is written into the scope, before anything is built, with these answers:
- What triggers it: the action class and any threshold, in numbers you set.
- Who approves, and who covers when they are away.
- What the approver sees: the draft, the source data it came from and the reasoning, not just the output.
- What they can do: approve, edit or reject, and what happens to a rejected item.
- What happens if nobody responds: the action waits; it never proceeds by default.
- What is logged: the request, the draft, the decision and who made it.
Our sample AI and CRM scope records the same things at contract level: data sources, integrations, test cases, human escalation and account ownership. Before an agent is trusted to run without supervision, we test it against an evaluation set scored against your own baseline.
A worked case: automated replies to customer reviews
Drafting replies to reviews is a strong fit for a model: read the review, write a relevant, well-worded response, at volume. The risk sits entirely in posting it publicly, under your name, unread.
The failure modes are foreseeable. A model can read sarcasm as sincerity, answer a serious complaint in a tone that sounds dismissive, or state something subtly wrong about the product. Posted automatically, each becomes a permanent, screenshot-able mistake. In a draft queue, each costs nothing once a person catches it.
So the governed version drafts every reply and holds it in a queue for approval. The automation still removes most of the manual effort; the checkpoint sits at the one point where removing it would trade a small saving for a public risk.
- 01Read the reviewThe model reads each one, at volume
- 02Draft a replyRelevant and well-worded, written by the model
- 03QueueEvery draft held; nothing posts unread
- 04Human checkCatches misread sarcasm, a dismissive tone, wrong facts
- 05DecideApprove, edit or reject; no response means it waits
- 06LogThe draft, the decision and who made it
- Posted under your nameOnly after a person has read and approved it
When a checkpoint is unnecessary, or costs more than it saves
Not every automation needs one, and we say so. Leave the checkpoint out when the action is internal and reversible, when it reaches nobody outside the business, or when an error would be caught downstream anyway before it had any effect.
A checkpoint can also be badly placed. If approvals pile up faster than anyone reads them, people approve without reading and the step becomes theatre.
When that happens, we recommend narrowing what triggers the gate rather than keeping a check nobody performs. If a client still wants a checkpoint removed after hearing the trade-off, that is their decision, and it belongs in the written scope.
Whether the system is a fixed workflow or an agent changes how the checkpoint is drawn, which is covered in AI agent vs AI automation vs a chatbot.
Written by
Parvessh Agarwal
Founder and Chief Executive, Vinove
Parvessh founded Vinove in 2004 with one idea: build focused technology companies that earn their place in real markets. His focus is on the long game, on companies that survive and serve real customers long after launch.
LinkedIn →
