Your agent has drafted a customer email. The draft may be useful, but sending it introduces a different decision: who receives it, what information leaves the system, and whether the agent has authority to act.
Work through the checklist before enabling consequential actions such as sending messages, changing records or making purchases. The illustrative customer-email workflow gives each check a concrete operation to inspect.
Show the action that will actually run
Present the concrete operation, destination and arguments. For an email, that means the recipient, subject, body and attachments. For a record change, show the record and the fields that change. A summary such as 'contact the customer' leaves too much hidden.
Bind any required approval to those exact values. If the recipient or attachment changes after review, the old approval should not authorize the changed operation. Enforce this at the execution boundary; an instruction asking the model to be careful is not an authorization check.
Separate outside information from authority
An agent may read emails, webpages or documents that contain instructions. Treat that material as task data. It cannot grant permission to send a file, change a recipient or call a privileged tool.
Give each tool only the access its task requires. In a test environment, place a request to send dummy data to a test destination inside a retrieved document. Observe the attempted tool calls and authorization decisions, not just the agent's final text.
Make retries safe to reason about
A timeout after a send request does not tell you whether the recipient received it. Keep a record of the attempt and use the provider's supported deduplication or reconciliation mechanism. Document the limits of that mechanism rather than assuming a retry key works indefinitely.
For the email example, the review should answer what happens if the provider accepts the message but the application loses the response. An ambiguous operation needs reconciliation before another irreversible attempt. Test this failure path with a fake recipient and provider substitute.
Define when the agent stops
Write down the conditions for refusing or handing off an action: missing authority, conflicting instructions, an unverified destination or an unresolved earlier attempt. A model's confidence score alone does not establish permission.
Keep an audit record of the proposal, any required approval, the execution result and the responsible identity. Verify that revoking permission stops later execution. Start with a narrow task and expand its action set only after observing the failure paths.