all-agents docs
Approvals and gates

Approval requests

How an agent stops mid-run to ask you before it does something consequential, and what happens when you answer.

An agent running your work can act with a lot of freedom. Reading a mailbox, pulling a report, drafting a reply: none of that needs you. Sending the reply might.

So the agent asks. Before it does something consequential it stops the run, describes the action it wants to take, and waits for your answer. This is the agent's own judgment about the moment it is in, not a rule attached to a particular tool.

What makes it ask

The agent is told to stop for actions a person would want to see first:

  • sending a message someone will read
  • moving money
  • deleting data
  • submitting a form
  • posting something publicly

It applies that to whatever it is using at the time. The same rule covers a tool call, a command in its sandbox and a click in the browser, so an action does not slip past by arriving through a different route.

It is also told not to ask about read-only work or steps it can obviously undo. A workflow that stopped for every single step would be worse than one that never stopped at all.

What you see

An approval request carries two things the agent wrote for you:

  • The action, in one plain sentence. What it is about to do, specifically.
  • The reason, in a line or two. Why it wants your sign-off before it goes ahead.

There is no raw tool payload to decode. The request reads as the agent explaining itself, because that is what it is.

What your answer does

Approve, and the run continues from where it stopped and carries out exactly the action it described.

Reject, and the action does not happen. Give a reason and the agent is handed it, mid-run, as part of the conversation it is already having. It can then take a different path, or tell you it cannot continue and stop the run. Either way the work the run had already done is not thrown away.

You cannot edit an approval request before approving it. Its arguments belong to the agent that wrote them, and they are what the run will re-execute. If what it proposes is wrong, reject it and say what is wrong. Gate cards are different, and permanent gates covers that.

Where it applies

Both kinds of run can raise one:

  • Learning runs, where an agent is doing the whole job, ask this way throughout.
  • Codified workflows ask this way at their judgment steps, the parts that were deliberately left to an agent when the rest of the workflow was written down as code.

The interview is the exception. While you are building or repairing a workflow in the chat you are already present, so the agent asks you there in the conversation instead of raising anything.

This is judgment, not enforcement. The agent decides what counts as consequential, and it can be wrong about a specific action. Where a step must stop for a person every time no matter what the agent thinks, put a permanent gate there instead.

On this page