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_requiredinstead 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
| Safety Class | Commit Record | Reconciliation | Approval Gate | State Revalidation |
|---|---|---|---|---|
| Idempotent | No | No | No | No |
| Write-once-checkable | Yes | Yes | No | No |
| Irreversible | Yes | Yes | No | Yes |
| Approval-bound | Yes | Yes | Yes | Yes |
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