Skip to content
AM

Pending actions: review, approve, reject

When the AI COO proposes a material write, it does not execute the write immediately. It creates a pending action, shows the exact preview, and waits for an approve or reject decision.

What this is

A pending action is a tenant-scoped record with:

  • The canonical action or MCP tool name, such as inblack_post_entry.
  • Normalized arguments and preview data.
  • A preview hash, when available.
  • The initiating principal, status, result ID, creation time, resolution time, and expiry time.
  • Status values of PENDING, CONFIRMED, REJECTED, or EXPIRED.

The operator queue lives in Accounting at /ai-actions. The page queries pendingActions, defaults to the pending filter, and can switch between pending, all, confirmed, rejected, and expired actions.

When you’d use it

  • Review actions the agent has staged but has not executed.
  • Approve a proposal whose preview matches what you want done.
  • Reject a proposal that is wrong, stale, or no longer needed.
  • Review confirmed, rejected, and expired actions for audit context.
  • Open the reconciliation batch confirmation flow when the pending action is inblack_commit_reconciliation.

Walkthrough

The queue shows each action with its title, status badge, tier badge, preview summary, preview fields, created time, expiry countdown, and result ID when present.

Preview. The row renders the persisted preview summary and up to eight preview fields. If available, it also displays the preview ID, preview hash, and args hash. If no preview information is available, the row warns that the preview is unavailable.

Tier badge. The current UI shows:

  • Confirm - the standard confirmation path.
  • Destructive - a louder badge when the row tier is destructive.

Approve. Clicking Confirm calls the AI COO Worker pending-action resolve endpoint with {"approved": true}. The request uses credentialed fetch, sends X-Tenant-ID, and requires VITE_AI_COO_URL to be configured. On success, the page refetches the queue and shows a success toast. If execution fails, the returned summary or error is surfaced to the operator.

Reject. Clicking Reject calls the same endpoint with {"approved": false}. The action is resolved as rejected and is not executed.

Expiry. Pending rows show an expiry countdown. Expired rows are still visible through the expired or all filters, but they are not actionable.

Auto-approval

Agent policy includes autoApproveBelowCents and maxDailyT3Actions. Actions below the auto-approval threshold can skip the pending-actions queue; daily T3 limits can force later T3 actions back through confirmation. Review and edit those operator-facing controls on the Agent activity timeline.

T4 is different

T4 tools are not turned into pending actions. They are blocked by policy before execution. Blocked attempts are reviewed in the agent activity timeline rather than approved from the pending-actions queue.

Tenant policy can promote lower-risk tools to a higher risk tier. It cannot downgrade a catalog T4 tool into an executable T3 path.

Programmatic access

  • GraphQL (accounting-api): pendingActions(status) lists the queue and pendingAction(id) fetches one row. The legacy confirmPendingAction mutation now fails closed with an instruction to use the AI COO Worker resolve endpoint.
  • AI COO Worker HTTP: POST /pending-actions/{id}/resolve with {"approved": true} or {"approved": false} is the first-party UI decision path. X-Tenant-ID is required.
  • MCP: inblack_confirm_action is the agent-side confirmation tool for MCP clients.
  • Internal service paths: the Worker uses internal pending-action routes to create, claim, release, and resolve records.

See Pending actions and the approval flow for developer-facing details.