The gate: Human Approval before anything happens
Where the gate sits, what an expired approval means, who actually gets asked, and how to make it fail closed.
Everything so far has been preparation. This is the node that makes the difference between a system that proposes and a system that acts: nothing irreversible happens until a human says so.
The gate, and both of its exits
The condition routes on the verdict. Approved work reaches a human; rejected work becomes a task somebody owns.
Scroll for all 12 steps →
| Field | What it holds |
|---|---|
prompt | Question or prompt to show the user Defaults to Please review and approve to continue. |
inputType | Type of input interface One of: options · text · approval Defaults to approval. |
timeout | Timeout in seconds (0 for no timeout) Defaults to 300. |
allowModification | Allow user to modify the data before approval Defaults to true. |
showData | Display current data to the user Defaults to true. |
prompt
- What it holds
- Question or prompt to show the user Defaults to
Please review and approve to continue.
inputType
- What it holds
- Type of input interface One of:
options · text · approvalDefaults toapproval.
timeout
- What it holds
- Timeout in seconds (0 for no timeout) Defaults to
300.
allowModification
- What it holds
- Allow user to modify the data before approval Defaults to
true.
showData
- What it holds
- Display current data to the user Defaults to
true.
The two questions everyone asks
What happens when the timeout expires?
The run ends. It does not proceed, and it does not quietly approve — on a verified run the execution sat paused for the full hour and then expired with nothing executed. That is the correct behaviour and it is worth stating as a design choice rather than a default: an expired approval is a rejection. A timeout of zero — wait forever — is also a decision, and it means a run of yours is pending somewhere until someone finds it.
Who actually gets asked?
Whoever is watching the surface the run was started from. This matters more than it sounds: a run started from a chat panel raises the approval card in that chat, while a run started by a schedule or a webhook pauses and waits for someone to go looking. If your gate is on an unattended workflow, decide now who is notified, because the node’s job is to stop — not to find you.
The gate fails closed
On one run the reviewer itself errored. The verdict never arrived, the condition compared an empty value, and the workflow took the false branch — escalating to a human instead of approving. That is the behaviour you want and it is worth checking deliberately in your own build, because the opposite arrangement is easy to write by accident: a gate that tests for rejection and lets everything else through will approve on every error it ever meets.
Write the condition so that approval is the narrow path. Compare for the exact value that means yes, and send everything else — rejections, errors, empty strings, surprises — down the branch where a human owns the outcome.
What the false branch has to do
An escalation that goes nowhere is worse than no gate at all, because it looks like control. The rejected path here creates a task, with a title that says what happened, the reviewer’s score, and a priority — a thing that appears in somebody’s queue rather than a message in a log nobody opens.
A defect worth knowing about, because you may hit its shape elsewhere. Until recently this node could not run at all in any workflow started by an API key, a webhook, a schedule or an integration: it recorded the approver’s identity in a field that only accepts a proper user id, and a machine-triggered run has no user. Every such run died at the gate. It was a one-line fix, and it had been invisible for a long time for the reason lesson 17 is about — the gate is the point past which nothing automated had ever reached.
The rule
The gate sits in front of the irreversible tier. Always. Not in front of the agent, which would make every lookup wait for a human, and not after the write, which is a notification rather than a control. Immediately before the first node that changes something you cannot change back.
Related lessons
Base rates — what a piece of evidence is actually worth
A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.
ReadConfirmation and survivorship — what you never looked for
Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.
ReadLoss aversion, sunk cost and regression — what it costs you
Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.
Read