Building an AI agent that touches email, money, or customer records almost always leads to the same early decision: what does it ask before it acts? Get that wrong in either direction and you end up with something that's either useless or dangerous — or worse, something that looks safe but isn't.
This comes up constantly among practitioners building agents with n8n, Make, and similar tools. The question isn't whether to have approval steps. It's where to put them and how to tell if they're actually working.
Two ways this goes wrong
The first failure is too many gates. You're building an agent that moves money or sends email, you're nervous, so you put a pause before every action. The approver sees forty requests a day and starts clicking Approve without reading. A few weeks in, your audit log shows near-100% human approvals and zero caught mistakes. That's not oversight — it's the appearance of oversight.
The second failure is the opposite: no gates, or one gate at the very end of a long chain. By then the agent has already made four decisions you didn't review. A refund goes to the wrong customer. A bulk email goes to the wrong list. The human checkpoint was technically present but caught nothing that mattered.
A gate that's almost never used to say no isn't a gate. It's a confirmation box that trained your team to click through.
Both failures share the same root: approval steps placed by intuition rather than by a clear rule about what they're protecting.
The irreversibility test
The simplest rule that holds up in practice: gate any action the agent can't undo.
Sending an email is irreversible. Issuing a refund is irreversible. Deleting a record, posting publicly, submitting a form to an external system — irreversible. Writing a draft to a folder, reading from a database, scoring a lead — reversible, or at worst low-stakes if wrong. Those can run at machine speed with no gate.
The other side of the test is blast radius. A wrong classification on one lead is recoverable. Sending a mis-personalized email to 2,000 contacts is not, even if each individual email could technically be followed up. Think about both dimensions together: reversibility and how many things go wrong if the agent gets this one wrong.
Actions with high reversibility and small blast radius: no gate. Anything else: gate it, at least until the agent has enough of a track record to earn more autonomy on that action type.
The approve rate test
Here's the metric most teams skip: what percentage of requests through each gate actually gets approved?
Track it per gate. A gate running above roughly 95% approvals is being rubber-stamped — the reviewer has learned the agent is almost always right here, so they click yes. The gate exists, but it isn't catching anything. That human attention is being spent on a check that does no work, and it'd be better spent on the step two decisions later that actually surfaces real problems.
A real gate rejects things sometimes. If yours never does, that's diagnostic information, not a sign that the agent is perfect.
When a gate's reject rate is near zero, you have two options: either widen the auto path (let the agent run this action type without approval) or investigate why rejections are so rare. Sometimes the threshold is too conservative and you're bottlenecking easy calls. Sometimes the gate catches real problems occasionally — once a month, say — and you need to look more carefully at what's slipping through between those catches.
Either way, approve rate is a signal. Ignoring it means your gate configuration never improves.
Protecting the approval itself
One pattern that comes up in production agents that the initial HITL setup usually misses: approvals that execute against the wrong payload.
The propose-action pattern works like this — the agent proposes an action, the approval request goes out, and when the approver confirms, the queued action runs. Simple enough. But if anything changes in the underlying data between when the action was proposed and when it's actually approved — a re-run rewrites a field, another process updates the record, the agent retried with different parameters — the approval executes something the person never actually saw.
The fix is to bind the approval to a hash of the exact payload, not just the queue row ID. Before executing, the workflow checks whether the payload still matches what was approved. If anything changed, it re-asks rather than proceeding. Two extra lines of logic, and the approval means something again.
Approval TTLs help too. An approval that's 24 hours old isn't really an approval — it's a signature someone gave before the situation may have changed. Set expirations based on how fast the relevant data can move. For anything involving live pricing or inventory, that window might be 15 minutes. For a drafted email pending a quick review, a few hours is probably fine.
Putting this into practice
For n8n users specifically: since version 2.32.0, the HITL feature on the AI Agent node lets you gate individual tools rather than the whole workflow. That's the right shape — the email-sending tool gets a gate, the CRM-lookup tool doesn't. See our breakdown of what the 2.32.0 HITL update actually changed for implementation specifics.
The actions almost always worth gating: anything that sends outbound (email, SMS, DMs, especially with personalization or financial content), refunds and credits, hard deletes, and external API calls that trigger downstream billing or notifications.
The actions that usually don't need a gate: internal reads and lookups, draft creation before anything is sent, calculations and scoring against known data, and low-value actions where the cost of human review exceeds the cost of a mistake.
If you're building AI agents that touch customer data or money, mapping the right gates early — before the first bad approval happens — saves a lot of cleanup later. If you want a second opinion on where your lines should be, drop us a line. That's a 30-minute conversation, not a sales pitch.
— Cole
Sources
- n8n Community — n8n users running AI agents: where do you still keep a human approval step? (thread that prompted this post)
- ExplainX.ai — Human-in-the-Loop AI: When to Gate Agents (2026)
- Waxell.ai — AI Agent Approval Workflows: Human Oversight That Scales