How to Add Human Approval Gates to an n8n AI Agent

Short answer

Use n8n tool-level review to pause an agent before sending or changing records, then test denial, changed parameters and duplicate attempts.

Define the pilot before connecting accounts

Use a support-reply draft as a concrete example. The agent may read a sanitized ticket and draft a response, but a person must approve the actual send. Start with a sandbox inbox and synthetic tickets. This guide is a proposed implementation exercise; it does not configure or send messages from your DiscoverAI account.

Write down the permitted recipient, maximum message length, available tools and owner. Keep purchase, delete and unrelated record-edit tools out of the pilot. A prompt asking the model to be careful is not an execution control.

1. Separate reading from actions

Draw a simple sequence: ticket input, read approved knowledge, draft, review send parameters, execute approved send, record outcome. Use narrowly scoped credentials. Fix the sandbox recipient in configuration rather than letting arbitrary ticket text choose a destination.

Our recommended initial design treats the incoming ticket as data. A request inside that ticket to ignore instructions or contact another address should not change the allowed workflow. Give the reviewer the original ticket and the proposed reply so the decision has context.

2. Configure the documented review connection

n8n’s official guide describes opening the AI Agent’s Tools connector, adding Human review, configuring an approval channel and connecting action tools through that review step. Approval executes the proposed tool call; denial cancels it. Check your installed version for the described interface.

Review messages can expose $tool.name and $tool.parameters, including AI-supplied fields. Configure the agent’s system instructions to explain which tools require review and how to handle a denial. Approval channels include n8n Chat and supported messaging services.

3. Make approval specific and understandable

As an implementation recommendation, show the recipient, subject, complete reply and ticket identifier in the review message. Do not ask someone to approve an unexplained tool name. Never include credentials in the message. If the draft needs editing, generate a fresh proposal and obtain fresh approval rather than silently changing an approved action.

Record who is responsible for pending requests and how overdue proposals are closed. Do not treat silence as approval. Keep the production credential disconnected until the sandbox tests pass.

4. Test the failure paths

The last two checks need workflow design beyond the approval node. Use a persistent action identifier and reconcile uncertain delivery before retrying. If your connector cannot establish whether an action completed, route that case to a person.

5. Roll out with a small ceiling

As a suggested acceptance gate, pass every failure test and review ten synthetic tickets before connecting one limited production use case. Log proposal, decision and execution outcome separately. Count approved replies, corrections, duplicate attempts, errors and review time. Expand permissions only when those observations support the next step.

Read the n8n profile, the broader Make and n8n integration guide and our tool review library.