Approvals
An approval is a human gate on an agent action that would change the outside world. When an agent at the Suggest or Act tier encounters a write or destructive tool call, the platform pauses that call, queues it, and waits for a yes or no before proceeding.
The agent does not block while waiting. It continues any work it can do without the paused action, and picks up the result as soon as a decision is made.
Screenshot needed: The Approvals queue page: a table of pending approvals across every agent in the environment, with columns for risk class (Write / Destructive), tool name, agent, requester, and Approve / Deny buttons.
:::
Why approvals exist
LLMs are non-deterministic. The same agent with the same context can choose a slightly different tool call on different runs. For reads, that's fine. For writes, the worst case is a deleted resource, a billed action, or an outage. You can't reverse those by clicking Undo.
An approval queue makes the worst case survivable: the agent proposes, you decide. Combined with scope and limits, approvals are what make it practical to run higher-autonomy agents against production systems.
What triggers an approval
Every tool a molecule exposes carries a risk class. The agent's autonomy tier determines what happens when the agent tries to call it.
Risk classes
| Risk class | What it means | Examples |
|---|---|---|
| Read | Fetches data, no side effects | List open tickets, get an account's renewal date |
| Write | Makes a change that is normally reversible | Post a ticket comment, update an opportunity stage, create a follow-up task |
| Destructive | Makes a change that is hard or impossible to undo | Close a ticket, cancel a subscription, charge a card |
Molecules classify their own tools. zendesk_get_ticket is Read, zendesk_add_comment is Write, stripe_cancel_subscription is Destructive.
Autonomy tiers and approval requirements
| Tier | Read | Write | Destructive |
|---|---|---|---|
| Observe | Runs | Not visible to the agent | Not visible to the agent |
| Suggest | Runs | Approval required | Approval required |
| Act | Runs | Runs | Approval required |
| Act (destructive) | Runs | Runs | Runs |
Start agents at Suggest or Act for new integrations. Once you trust the agent's behavior, you can raise the tier. Or leave it and just clear the approval queue on a cadence.
The approval queue
The queue lists every pending approval across all agents in the environment. Each row shows:
- Risk class (Write or Destructive)
- Tool name and the integration it targets
- The agent that proposed it and the user who triggered that agent
Clicking a row opens the detail page.
The approval detail page
Screenshot needed: Approval detail page split into two columns: left side shows the agent's plan with the current step highlighted; right side shows the proposed tool call with arguments rendered as a clean form, plus large Approve / Deny buttons.
:::
The detail page gives you full context before you decide:
- What is about to happen: tool name, arguments, and the integration it would call
- Why: the agent that proposed it, the goal that was running, and the tool calls that led here
- Context: entities the agent touched along the way, so you can verify the action makes sense
Two buttons: Approve and Deny. You can attach a reason to either decision. The reason is preserved in the audit trail.
Approval lifecycle
Every approval moves through one of four end states.
| State | What it means |
|---|---|
| Pending | Waiting for a human decision |
| Approved | Decision made; tool call executing or complete |
| Denied | Human said no; agent receives a denial and may re-plan |
| Expired | No decision within 24 hours; treated as a soft deny |
Expired is intentionally distinct from Denied. "No one got to it" is a different operational signal than "a human said no." Dashboards and notifications surface these separately. The default expiry window is 24 hours.
When an approval executes, the tool result is recorded back on the same row. If the call succeeds, the agent picks up the result and continues. If it fails, the failure is visible on the same row you just actioned.
MFA step-up for destructive actions
Approving a destructive tool call requires a second factor. The dashboard prompts you to re-verify with your authenticator app or SMS code before confirming. Write-tier approvals are a single click. Destructive approvals require a click plus a one-time code.
Without MFA configured on your account, you cannot approve destructive actions. If the option is greyed out, check your account security settings.
Screenshot needed: The MFA step-up modal that appears when approving a destructive action: labeled "Re-verify to approve destructive action," with a code input and a "Why this is required" link.
:::
This keeps friction proportional to risk. Routine write approvals stay fast. Irreversible deletes slow down.
Cancelling a running agent
If an agent should not be running, cancel its task from the Tasks view. Any pending approvals attached to that task are marked cancelled immediately, and nothing further executes. The agent loop unwinds within seconds.
Audit trail
Every approval is permanently linked to the task that proposed it, the agent the task came from, and the trigger that fired the agent (if any). The full plan, trace, and all tool results are recoverable.
You can always answer: who approved this, when, why, and what did it lead to, even months later.