Decide which actions an automation may take on its own, which need a person, and build the approval gate and audit trail that make that decision stick.
Module 10 ~50 min read + lab No codePrerequisites: Module 9: Multi-agent workflows, and the triage flow you built in Module 6.
Modules 5 to 9 taught you to make things happen automatically. This module teaches you to decide, on purpose, what should not happen without a person. That order is deliberate. Until you have watched an automation act on its own, the need for a gate feels theoretical. After the first wrong email goes to a customer, it feels obvious.
"Human-in-the-loop" (HITL) is the general name for any design where a person can see, approve, change or stop what an automated system does. It is not a single feature. It is a set of decisions about where the person sits, what they see and how much they are asked to do. Get those decisions right and the automation is trusted and used. Get them wrong and one of two things happens: the gate is ignored because it fires too often, or the gate is missing where it mattered.
For every action in a workflow, ask: If this ran wrongly a hundred times before anyone noticed, what would it cost? The answer decides the tier, and the tier decides the control.
Every tool an agent can call falls into one of five tiers. The tier is about the consequence of a wrong call, not about how clever the step is.
| Tier | What it does | Examples | Control needed |
|---|---|---|---|
| 1. Read-only | Looks something up, changes nothing | Search a sheet, read a calendar, fetch a ticket | None beyond logging. Let it run. |
| 2. Reversible write | Changes internal data that can be undone | Add a row, set a label, create a draft, move a card | Review after. Spot-check a sample weekly. |
| 3. Irreversible internal | Cannot be undone, but stays inside the organisation | Delete a record, overwrite a file, close a ticket | Approve before, or convert to reversible (archive instead of delete). |
| 4. External / customer-facing | Leaves the organisation | Send an email, post to a customer portal, reply on social media | Approve before, or edit-then-approve. Always. |
| 5. Money, people, legal | Commits funds, affects a person's status, or creates legal exposure | Issue a refund, approve leave, sign a contract, change pay | The system prepares; a named person decides. No auto-run, ever. |
Two habits make tiering easy. First, tier the tool, not the workflow: an "email" tool is Tier 4 wherever it appears. Second, look for a cheaper tier that gives the same result. "Delete" becomes "archive" (Tier 3 to Tier 2). "Send email" becomes "create draft in the sender's mailbox" (Tier 4 to Tier 2), with the human pressing send. Most approval gates can be avoided by choosing a lower-tier tool.
An agent that "usually" only reads but "occasionally" sends is a Tier 4 agent. Controls follow the highest tier the agent can reach, not the average.
Once you know the tier, pick the pattern. There are only four, and each answers a different question: before or after, and every time or only when unsure.
The workflow pauses and shows the person exactly what it is about to do. Nothing happens until they say yes. Use for Tier 3 and 4 actions. Cost: one click per run, so volume must be manageable.
The action runs, and the person sees a digest (daily or weekly) of what happened, with an undo path. Use for Tier 2 writes at high volume. Cost: near zero per run, but mistakes live for a while before they are caught.
The system drafts, the person adjusts and sends. The best pattern for customer-facing text: the person stays the author, the machine removes the blank page. Cost: a minute per item, so it suits tens per day, not thousands.
The workflow runs alone when the model is sure, and routes to a person when it is not. Use when most cases are easy and a few are hard. Requires the AI step to report a confidence or a category such as "unsure".
Real workflows combine them. The Module 6 triage flow, for example, can run alone for labelling (Tier 2), escalate anything the model marks "unsure", and use edit-then-approve for every outgoing reply (Tier 4).
Under every approval gate is the same mechanism, whatever tool you use. The workflow reaches a checkpoint, saves its state (everything it knows so far), stops, and waits for a signal. When a person sends the signal, the workflow resumes from exactly where it stopped, with the person's decision added to what it knows.
In developer frameworks this is explicit. LangGraph, for example, lets a designer mark a step as "interrupt before": the graph pauses just before that step, a checkpoint is stored, and a human call is needed to continue. The same idea appears in every no-code tool under a friendlier name:
| Tool | How the pause is built | How the human resumes it |
|---|---|---|
| n8n | Wait node set to "resume on webhook call" or "on form submission" | Clicks an approve or reject link in Slack or email; the link calls the resume address |
| n8n (simpler) | Gmail or Slack node with "Send and wait for approval" | Presses Approve or Decline in the message |
| Power Automate | Approvals action ("Start and wait for an approval") | Responds in Teams, Outlook or the Approvals app |
| Make / Zapier | Split into two scenarios: one ends by sending the request, a second starts from the approval webhook | Clicks a link that fires the second scenario |
Three design details decide whether a gate is any good:
If you want to see the mechanism in code, the LangGraph tutorial on this site walks through checkpointing and interrupt-before step by step. You do not need it for the labs; it is there for the curious.
Approval gates control which actions run. Two more controls limit how much can go wrong between gates.
An agent (Module 8) loops until it decides it is done. Give it a ceiling: at most 10 tool calls per task, at most a fixed model spend per run, at most 50 runs per hour for the whole workflow. In n8n's AI Agent node this is the "max iterations" option; in most builders it is a similar setting. When the ceiling is hit the agent must stop and hand the task to a person with what it has so far, not silently give up.
An audit trail answers, months later, "what did the system do, and who said it could?" At minimum log one row per gated action:
A Google Sheet or Airtable base is enough to start. The important properties are that the log is append-only (nobody edits history), complete (every gated action, including rejections and timeouts), and readable by someone who was not there.
A gate that fires 200 times a day gets rubber-stamped by lunchtime, and a rubber-stamped gate is worse than none, because it creates false confidence. Warning signs: median approval time under five seconds, approval rate above 98%, the same person approving everything. Fixes: lower the tier of the tool (draft instead of send), batch approvals into a digest, escalate only low-confidence cases, rotate approvers, and review the numbers monthly.
You will add an approval gate to the email-triage workflow from Module 6 so that no reply leaves without a person seeing it, and every decision is logged. You need your n8n workspace, a Gmail or Slack connection, and a Google Sheet named Approval log with the columns from Section 5.
Open the triage workflow. Beside each node, note its tier: the trigger and the classify step are Tier 1, the label step is Tier 2, and the reply step is Tier 4. That last one needs a gate.
Between the "draft reply" AI step and the "send email" node, add an approval step. Easiest: replace the send node with a Gmail node set to Send and wait for approval, addressed to yourself, with the drafted subject and body in the message. Alternative: a Wait node set to "resume on webhook call", preceded by a Slack message containing the draft and two links built from the Wait node's resume address (one with ?decision=approve, one with ?decision=reject).
After the gate add an IF node: if the decision is approve, continue to the real send node; otherwise go to a node that labels the email "needs human" and stops.
On each branch add a Google Sheets: append row node writing to Approval log. Map the timestamp, run id, the proposed reply, the tier, your name as approver, the decision, and the final text. Rejections must be logged too.
In the Wait or approval node set a time limit of 24 hours. On timeout, route to the "needs human" branch and log the decision as timed out. Confirm that a timeout never reaches the send node.
Send two test emails to the triage inbox. Approve the first draft and reject the second. Check that exactly one email was sent, both rows appear in the log, and the rejected email carries the "needs human" label.
If your flow has an AI Agent node, set its maximum iterations to 8. Add a note on the canvas recording the tiers you assigned and why the reply step is gated.
An export of the gated workflow, a screenshot of the approval message showing the full draft, and the Approval log sheet with at least one approved, one rejected and one timed-out row. Save as M10-approval-gate.
Pick one answer per question, then check your score. These mirror the style of the final exam.
Answer in your own words first, then open the model answer.
Read-only (look up a record), reversible write (add a row or label), irreversible internal (delete or overwrite), external (email a customer), and money/people/legal (approve a refund or leave). Any concrete mapping is acceptable if the consequence matches the tier.
The workflow reaches a checkpoint and saves everything it knows. It stops and waits for a signal from a person. When the signal arrives, it continues from the checkpoint with the person's decision included.
Timestamp, workflow and run id, the proposed action and tier, the approver, the decision including rejections and timeouts, and the final content. Append-only so that history cannot be edited after the fact and the record is trusted.
Further reading: LangGraph: checkpointing and human-in-the-loop · n8n guide: error handling and approval steps
