Classify actions by consequence and reversibility

HTTP method alone says little about the permission required. Sending an email, publishing a file, creating a user, moving money, changing access and starting a long-running job have different consequences and recovery paths. Classify the action using those properties.

Classify each action using concrete questions. Who can be affected? Can the action be undone? Does undo create another external event? Is there a deadline? Can the destination deduplicate a repeated request? Will another system act automatically on the result? Does the action expose private information to a new recipient?

Use policy rules to require stronger review for particular values or destinations. For example, a draft message to an address already attached to the case may have a normal approval path, while a new external recipient requires another check. Keep these rules in the tool gateway or policy service. Prompt wording is useful context for the model, but it is not an enforcement mechanism.

Execution needs idempotency. Give each approved proposal a stable action ID and send it as an idempotency key where the destination supports one. Record the destination's response and object identifier. If a timeout leaves the outcome uncertain, query by that key or route the task for reconciliation before retrying.

Return evidence after execution: the fields accepted by the destination, its version or reference, the completion time and any downstream work started. Do not claim success merely because the tool call returned without an exception. A queued action may still fail later.

Reversal should be a named operation with its own permission. Avoid a generic undo button that guesses how to compensate for several kinds of side effect. For an irreversible action, show that fact before approval and make the permission correspondingly narrow.