Approvals and gates
The two ways a person stays in the loop on a run, what a paused run looks like, and how it comes back.
Some things should not happen without a person on the hook. Money moving, a contract going out, a message a customer will read. A workflow that otherwise runs itself still has to stop at those moments and ask.
All-Agents does that in two ways. The difference between them is who decides that a pause is needed.
The agent decides, in the moment. While a run is going, the agent stops before it does anything consequential and asks you first. It judges which actions qualify. There is nothing to switch on per tool and nothing to wire up per step. See approval requests.
You decide, permanently. A gate is a checkpoint you put into the workflow itself. It stops every run at that point, whether or not the agent would have asked, and it keeps stopping them long after the workflow is running on its own. See permanent gates.
Most workflows need only the first. Add a gate at the points where a human has to carry the responsibility every single time, regardless of how well the workflow is behaving.
What a paused run looks like
The run stops and its status reads "Waiting on you" everywhere it appears. Everything the run had already done stays done. Nothing after the pause happens. The pause is written into the run's own timeline, so a person reading the run weeks later can see that it waited and for how long.
A run can wait for minutes, hours or days. Nothing expires, nothing times out and nothing gives up. A paused run is pinned to the version of the workflow it started on, so publishing a change while it waits cannot move the ground under it.
A notification goes to the workflow's owner by email, and the decision itself is waiting in the console inbox. Responding to an approval walks through it.
How it comes back
When you approve, the run picks up exactly where it stopped and carries on.
When you reject, the run does not end. Your reason travels back into the run and the agent works with it. At a judgment step it drops the action it proposed and takes your answer into account. At a gate it corrects what the checkpoint showed you and puts the same checkpoint back in front of you. A rejection is a correction rather than a verdict.
The agent can also conclude that your answer means the run should not continue. Then it stops the run and says why. Either way nothing past the pause happens until you approve.
What approvals do not do
Approvals go to the workflow's owner, and only to the owner. There are no approval chains, no second approver, no routing to whoever is on shift, and nothing escalates when a decision sits unanswered. The owner, or nobody.
Two more limits worth knowing before you design around them:
- A gate has no condition on it. It fires on every run of the workflow, not only the ones over some amount.
- Email is the only channel a pending decision is pushed to.