Approvals

Some actions are legitimate but too risky to automate — deleting cloud resources, running a destructive command, filing changes in an external system. For these, the agent runtime supports deferred approval: the agent pauses mid-task on a designated tool call, asks a human, and only proceeds if the human approves.

How an approval works

Specific tools on an agent can be marked as requiring approval. When the agent is about to call one of them:

1. The task is paused — not failed. Anyone checking the task's status sees it in a deferred state.
2. A notification is delivered to the configured approver destination (typically a Slack channel) describing what the agent wants to do — the tool name and a summary of its arguments.
3. An approver decides:
   • Approve — the tool runs and the task resumes as if it had never paused. The conversation continues normally.
   • Reject — the approver is prompted for a reason; the tool call fails with that reason, and the task ends in a failed state.
   • No decision in time — each approval has a timeout (minutes, not hours). If it expires, the call is automatically denied and the task fails. Silence never means yes.

Every step is captured as audit events: the pause, the decision (with the approver's identity and note), or the timeout.

Approving from Slack

When approvals are routed to a Slack channel the agent is connected to, the notification arrives as an interactive message with Approve and Reject buttons. Approving resolves the request immediately; rejecting opens a short dialog asking for a justification, which is recorded with the decision. After the decision, the message updates to show the outcome and who made the call.

For stricter control, an agent can carry an approver allowlist — a set of email addresses that are the only identities allowed to resolve its approvals. A decision from anyone else is refused and the request stays pending for a listed approver. This fails closed: an approver whose identity cannot be verified is treated as unauthorized.

What users of the agent see

From the requesting user's point of view, the agent simply takes longer on that step. If they are chatting with the agent through a channel, the conversation resumes seamlessly on approval. On rejection, the agent receives the failure — including the approver's reason — and can explain to the user why the action was not taken.

Approval windows are deliberately short. For conversations arriving through a chat channel, the runtime holds the request open for a bounded window (about six minutes); an approval that lands after the window is too late and the step fails. Design approval flows for a responsive on-call audience, not a queue reviewed hours later.

When to use approvals

• Actions that are dangerous but sometimes correct — use an approval so a human confirms the specific instance.
• Actions the agent should never take — do not use an approval; block them outright with the agent's policies and guardrails.
• Auditability requirements — approvals attach a named human decision to the action, which appears in the platform's Security area.