Decisions and approvals

A decision records the authority result for a proposed action. Its policy effect, current approval status, and reported execution outcome answer different questions.

Question	Evidence
What did the policy decide?	Allow, Require approval, or Block.
Has a person authorized the exception?	Pending, approved, or rejected approval status.
Did the action happen?	The integration’s execution report.

An approved decision retains its original Require approval effect. A Monitoring decision can record any effect while its status is MONITORED; no human approval is created by that mode.

Human approval

In Enforcing mode, Require approval pauses the action. Eligible members of the requested approval group review the inputs and reason in Needs approval. Membership is checked again when they respond.

An agent connection key cannot approve its own request. Receiving a notification or being a workspace administrator does not by itself substitute for the required approval eligibility.

Approval authorizes the recorded request. It does not permit replacing the action’s arguments or prove that the provider completed it. Expired authorizations require a new request against current state.

Continue and report

For a plain authorization request, your application retains the operation and controls its continuation. Poll decision status with the same agent connection, and execute only once the relevant authorization is established.

For a managed call, the SDK preserves an execution handle and coordinates dispatch through a claim. Resume that saved call after approval; do not submit a new invocation merely to bypass the pending state.

A claim prevents competing hosts from both receiving permission to dispatch the same captured call. It cannot make an arbitrary external provider exactly once. Preserve the provider’s idempotency key and reconcile uncertain outcomes.

Use Review approvals for reviewer setup, MCP for managed continuation, and Inspect a decision to read the evidence.