Separate preparation and execution
An agent can prepare a task, order or response without sending it yet. Define the draft state and the action that makes it effective. Before meaningful approval, show the recipient, amount or proposed change. A generic approval does not explain the specific operation that will occur.
Classify consequences
Distinguish reading, reversible changes and externally consequential operations. Define amount, volume and recipient limits where relevant. Decisions affecting money, permissions or customers need explicit controls. Begin with a bounded process and expand only when logs and tests support an assessment of its operation.
Handle uncertainty and retries
When a tool does not respond, distinguish failure from an unknown outcome. Before retrying, check whether the operation already occurred. Record verifiable identifiers and states. Provide human handover when systems disagree; inventing a success message hides the problem and makes recovery harder.
Test the full process
Rehearse insufficient permissions, incomplete data, declined approval and a system outage. Check that the agent stops at the right point and leaves a useful explanation. Define who can disable it and how work continues manually. The goal is operable automation, not just a flawless demonstration.
Worked example: preparing replenishment
In a fictional scenario, the agent detects a need for 120 units using a previously agreed inventory rule. It prepares a draft showing item, quantity, proposed supplier, source and data timestamp. If the current price is missing or the supplier is unauthorised, it neither invents the information nor submits the order. It asks for the draft to be completed or reviewed. Once information is sufficient, it displays the exact effect and requires the configured approval. After execution, it retains the returned system reference and distinguishes created, rejected and unknown outcomes. Detecting a need is not, by itself, authorisation to spend.
Acceptance checklist before real actions
Check that approval applies to a specific draft version and becomes invalid when relevant details change. Verify that an unauthorised user cannot approve, rejection prevents execution and repeated requests do not duplicate the operation. Test external material that attempts to change instructions and confirm it grants no new authority. Define a stop mechanism and incident owner. Records should reconstruct what was proposed, who approved it, which tool acted and the observed result. Start in test systems with data that cannot affect real orders. Passing a conversational demonstration is not sufficient evidence that these execution boundaries work.
Key takeaways
- Good approval shows the specific action and its consequences.