Skip to main content
An approval is how a consequential action reaches a person before it happens. Somebody approves or rejects it with the evidence in front of them, and the action goes ahead only if they allowed that exact one.

​
Why a decision, not a rule

A guardrail is the right control when the answer is always the same: this tool call must never happen. An approval is for the case where the answer depends on the situation — restarting this particular workload, at this hour, given what the investigation found. That distinction is why both exist. A rule that has to be right for every case gets written permissively and stops protecting anything; an approval keeps a person on the trigger for exactly the actions where judgement is the point.

​
Where an approval comes from

1

A workflow step that asks a person

A workflow can contain a step whose job is to put a question to a human. The run parks there — it is not failed, and it is not quietly retried — until somebody answers, and the workflow continues from that answer.
2

A guardrail that holds a tool call

A guardrail set to Hold for approval, at the tool call gate, refuses the call it covers and registers an approval naming exactly that call — rather than blocking the whole class of them outright.
In both cases the request carries what a decision needs: what the agent proposes to do, which agent and run it belongs to, and the record it came out of — so you are approving a specific action with its evidence, not a permission in the abstract.
The two resume differently. A workflow step continues from the answer it was given. A held tool call does not resume by itself: the agent was refused at the time, so the call has to be attempted again, by that agent or by a later run. A grant is also single-use and specific to the call it names, arguments included, so approving one attempt authorises neither a different call nor a second attempt at the same one.

​
Answering one

Pending decisions collect in Attention, with approve and deny beside each one, and a run parked on a workflow step shows what it is waiting on — its status reads waiting, against the action it prepared. The platform overview carries the same queue as an Approvals card, counting the agent actions awaiting a human and linking straight into Attention. Approving allows exactly what was proposed and nothing wider; rejecting ends that path rather than leaving the action pending.
Nothing pushes an approval at you today — pending decisions wait to be found rather than arriving as a notification. If a workflow depends on a timely decision, make checking the inbox part of somebody’s routine.
Approvals are answered in the console. An agent cannot approve its own held action, and there is no chat or tool path to answer one — deciding is deliberately a human-only surface.

​
What the decision leaves behind

Every approval and rejection becomes part of the run’s durable evidence, and the guardrail decision behind a held action is recorded whichever way it goes. Afterwards you can answer both questions that matter: what was proposed, and who let it happen. A run that was held for a human is also distinguishable from one that resolved untouched — so “was a person in this loop?” is a property of the run rather than something you have to reconstruct from timestamps.

​
Next steps

Standards & Guardrails

The rules that decide when an action needs a person at all.

Runs & evidence

Where a paused run and its decision live.

Audit log

The record of who decided what.