Permanent gates

A permanent gate is a checkpoint you put into the workflow at a point where a human has to sign off every time. It is a step, in a position you chose, with an explanation of what is being approved and a list of exactly what the approver should look at.

The word doing the work here is permanent. Once a workflow is written down as code and runs without anybody watching, the gate still stops it. That is the whole reason gates exist separately from the agent's own judgment: the gate does not care what the agent thinks about this particular run.

When to add one

Add a gate where the answer to "should a person always be on the hook here?" is yes for reasons that have nothing to do with how well the workflow works. Sending a contract. Paying an invoice. Anything where somebody has to be able to say afterwards that they personally approved it.

Actions the workflow takes through a live browser session deserve a hard look. Once a form is submitted or a message is sent in a real account, no later step can take it back, so the moment to look at it is before it happens.

Everywhere else, leave it to the agent. It already stops for consequential actions, and a workflow that pauses at every step is a workflow nobody operationalises. The trade is simple: a gate is safer and always pauses, the agent's judgment is faster and still asks a human when it matters.

Adding one

Gates are written during the interview, in the conversation where the workflow gets turned into repeatable steps. Say where a human must always sign off and what that person needs to see, and the gate is written into the workflow as a step alongside the rest. There is no per-tool setting to find and no checkbox buried in a step's configuration.

The part worth thinking about is what the gate puts in front of the approver. Those values are chosen when the gate is written, and they are all the approver gets. Pick the handful somebody needs in order to decide. A gate that shows everything the run happens to be holding is a wall of text, and a gate that shows too little is a rubber stamp.

What happens at a gate

The run stops. The steps before the gate have already run; the steps after it have not started. The run's status reads "Waiting on you", the wait is recorded in the run's timeline with the values the gate is presenting, and a notification goes to the workflow's owner.

A gate always suspends. There is no mode, no flag and no kind of run that walks past one.

A gate is a checkpoint rather than a transform. It produces nothing that the later steps read, and no step can be written to consume its output. It sits in the sequence purely to make somebody look.

After you decide

Approving releases the run and it continues with the next step.

Rejecting does not end the run and does not let it through. Your reason goes to the agent watching the run, which is shown what the gate presented and what you said about it. It answers in one of two ways: it corrects what the checkpoint displays and puts the same gate back in front of you, or it decides your answer means this run should not continue and stops it.

You can go back and forth more than once. Each revision costs the run one of the agent turns it is allowed, so a rejection loop cannot quietly run up a bill. When that budget is gone the run stops instead of asking again.

Whichever way it goes, the run's timeline keeps both halves: what the gate showed you, what you decided, who decided it, and the values that were approved.

The limits

• A gate is unconditional. It fires on every run of the workflow. There is no way to express "gate this only when the amount is over 500", because a codified workflow is a sequence of steps in order with no branching.
• A gate never expires. It waits for a decision indefinitely. Nothing reassigns it and nothing escalates.
• A gate goes to the workflow's owner, like every other approval.
• A gate belongs to a codified workflow. While a workflow is still learning, an agent is doing the work and it asks you directly. See approval requests.