Skip to main content
Every tool registered with Invoke gets a safety class. The class tells Invoke how to handle the tool at runtime — what checks to run, whether to require approval, and how to reconcile unknown outcomes.

​
The four safety classes

​
Idempotent

Safe to call multiple times with the same result. No special handling is needed.
  • Examples: read_customer, list_invoices, get_deployment_status
  • Behavior: Invoke executes immediately with scope validation. No idempotency enforcement needed.

​
Write-once-checkable

A single write that can be verified after the fact by querying live state.
  • Examples: stripe.charge_customer, create_linear_issue, send_email
  • Behavior: Invoke writes a commit record, then on retry checks live source-of-truth state before allowing another attempt. If the first write already succeeded, the retry is blocked.

​
Irreversible

Cannot be undone once executed. Invoke applies strict identity and scope checks.
  • Examples: delete_account, cancel_subscription, purge_data
  • Behavior: Invoke enforces additional scope checks and identity validation. Mismatched state triggers replan_required instead of proceeding.

​
Approval-bound

Requires a human decision before executing.
  • Examples: issue_refund, deploy_to_production, send_mass_notification
  • Behavior: Invoke stages the action and waits for approval. Before executing after approval, Invoke revalidates state to ensure conditions haven’t changed since the approval was granted.

​
How safety classes affect execution

​
Configuring safety classes

You define safety classes in your Invoke project configuration when you register tools:

​
Next steps

  • Reconciliation — how write-once-checkable tools handle unknown outcomes
  • Approvals — how approval-bound tools work end to end
  • Execution Records — the durable record created for every non-idempotent call