Every AI automation that takes an action without a human seeing it first is running a bet that the AI will never produce output you would have stopped. The checkpoint pattern is a single pause step that ends that bet, and it takes ten minutes to add to any workflow you already have running.
By the end of this article, you can add a pause point to any AI automation you have running today, one that sends you a Slack message or email with a summary of what the AI is about to do and waits for your approval before it proceeds. Workflows that were fully autonomous become ones where you are definitively in the chain for every action that matters.
What the checkpoint pattern is
When business leaders first set up AI automations, the goal is usually speed. The AI drafts the post, the post goes live. The AI qualifies the lead, the outreach email fires. The AI spots the anomaly, the report gets sent. Removing humans from the loop is the entire point.
That logic holds fine until the AI does something you would have stopped if you had seen it first. A social post that reads well in draft but lands badly given news that broke that morning. A lead flagged as high-priority who turned out to be a current customer. A financial summary with a figure that a bad data pull skewed.
These are not hypothetical edge cases. They are the predictable outputs of any workflow operating at scale without a review step. This week, security researchers at Sysdig published details on an autonomous AI ransomware attack that ran entirely without a human checkpoint: an AI agent found an exposed workflow server, swept its stored API keys, moved into a connected production database, and encrypted 1,342 records, all without a person directing a single step. The specific attack exploited a security misconfiguration, but the underlying condition was structural. No point in the chain required a human to say yes before something irreversible happened.
The checkpoint pattern exists to change that condition. It has three moves.
First, the AI completes its analysis, draft, classification, or processing, the part it is good at doing quickly and at scale.
Second, instead of proceeding directly to the action, the automation sends a formatted summary to a designated channel: a Slack direct message, an email, a mobile push, wherever the owner of this workflow actually looks within a reasonable window.
Third, the automation waits. The recipient reads the summary, approves or rejects it, and only after that response does the workflow proceed.
The technical term in engineering circles is "human in the loop." For practical purposes, it is just a checkpoint, a point in the workflow where a person has to say yes before the action becomes real.
What it looks like in Make.com
Make.com has a native Approval module that implements this pattern directly. You drop it into a scenario at the point just before the action you want to gate. When the scenario runs, Make pauses at that module, sends a Slack or email notification with whatever message you configure, and shows the recipient Approve and Reject buttons inside the notification itself. Clicking Approve resumes the scenario. Clicking Reject stops it, or routes it to a different branch you define. The entire configuration takes about ten minutes if you already have a scenario running: name the approval, set an expiration window, connect it to a Slack channel, and write a short message body describing what the AI prepared.
n8n, the open-source automation platform, accomplishes the same thing with its Wait node combined with a webhook trigger. The workflow pauses and sends a Slack message containing a link. Clicking the link fires a webhook that resumes the workflow. One more step to configure than Make's native module, but n8n is free to self-host and has no per-operation pricing.
Zapier has a functional approximation using its Filter step combined with a notification step and conditional logic, though it requires more workarounds than Make or n8n for a true approval gate.
A concrete example
Say your team runs an AI automation that drafts and schedules LinkedIn posts from company announcements. The AI reads the announcement, generates a post, and is connected to your LinkedIn account via API. Right now, it publishes on its own schedule.
The checkpoint version of that workflow: the AI still drafts the post. Before it publishes, Make sends the draft to your marketing Slack channel with an Approve button and a Skip button. You, or whoever owns this channel, reads it, checks the timing and tone, and clicks a button. The post goes live after that click, not before. If nobody approves within 48 hours, Make skips that post and logs the skip for review.
You have added roughly 30 seconds of human time per post. In exchange, you have eliminated the scenario where the automation publishes something tone-deaf because the news shifted that morning, or because the AI drafted something your brand would never say. More importantly, you are running the automation at full speed on the drafting step, which is the slow and repetitive part, while keeping a person in the seat for the publish step, which is the one that cannot be taken back.
The same structure applies to outbound sales sequences where AI drafts the first email, customer support responses generated from ticket data, financial summaries going to clients or board members, and any workflow where the final action crosses outside your internal systems.
When to skip the checkpoint
The checkpoint pattern is not right for every step in every workflow. It is the wrong tool for classification and processing steps in the middle of a workflow, where the AI is sorting, labeling, or transforming data internally. If you are using AI to classify 400 inbound leads per day into priority categories, a human review gate on each classification eliminates the entire benefit.
The checkpoint belongs at the output end of workflows, specifically on actions that are hard or impossible to reverse: publish, send, delete, charge, and create records others will see. Internal actions that generate drafts, log records, or update fields in your own systems for later human review carry lower risk and generally do not need a gate.
A useful rule: if you would be uncomfortable explaining to your team that an action happened without anyone noticing, put a checkpoint there.
The pitfall: approval gates that nobody watches
The most common way the checkpoint pattern fails is routing the notification to somewhere the right person does not actually check within the expiration window. A Slack approval notification sent to a general channel that receives 200 messages a day will get buried. The automation times out, silently skips the action, and nobody knows until someone asks why the post never went out or why that lead never got followed up.
Before you add a checkpoint, answer three questions explicitly: who specifically owns this approval, where exactly will the notification land and does that person check it reliably, and what happens if they do not respond before the timeout? That third question needs a deliberate answer. Timeout means cancel, timeout means queue for the next scheduled run, or timeout means escalate to a second person. Pick one and configure it. The workflows that fail quietly are the ones where the fallback was never defined, and the automation defaulted to doing nothing while everyone assumed someone else had approved it.
You can try this today
If you use Make.com and have at least one active scenario that publishes, sends, or modifies something externally, open the scenario, find the action module, and drop the Approval module directly in front of it. Connect it to a Slack channel you check at least once daily. Set a 24-hour expiration window. Write a short message body explaining what the AI prepared. Run the scenario manually, see the Slack notification appear, and click Approve. That is the complete implementation.
If you use n8n, the Wait node documentation walks through the webhook configuration in a few steps. If you are on Zapier, a Filter step before your final action combined with a separate notification is a serviceable starting point.
If you are not yet running AI automations, keep this pattern ready for the first one you build. Starting with a checkpoint is considerably easier than retrofitting one after the fact. It also lets you run an automation at full speed while you are still validating that the AI step produces what you expect, because you can watch every output before it becomes an action and calibrate your confidence before you remove the gate.
The real value of a checkpoint
The AI is not going to make fewer decisions as it gets more capable. It is going to make more, faster, across more systems at once. The checkpoint pattern is not skepticism about AI quality. It is the business-layer equivalent of a confirm-before-submit dialog: a small pause that keeps the decision yours before the action becomes theirs.
Every automation you hand off entirely is a bet that you would approve every output it will ever produce. Most of the time that bet pays. One time in a hundred it does not, and that one time is the one people remember. The checkpoint converts that bet into a review. The cost is 30 seconds per run. The coverage is structural.
The workflows that scale inside a business are the ones where someone can tell you, without checking a log, exactly where a human is still in the chain and why.