A plan is a proposed sequence of actions. Treat it as revisable application data, not a promise that every action is safe. Validate each action at execution time because permissions, resource versions, and user intent can change after the plan is generated.
Bind approval to an exact proposal
Suppose an agent proposes updating ticket 42. Store a proposal ID, ticket version, exact replacement text, expiration, and status. Show those details to the reviewer. The server verifies the reviewer’s authority and records approval of that specific proposal.
A useful state sequence is:
draft → awaiting_approval → approved → applied
↘ rejected
If the ticket changes after approval, the approved text may no longer be appropriate. Reject the stale execution and create a new proposal for review. The model cannot move a proposal into the approved state merely by saying the user agreed.
Separate reasoning from action
Planning can help with dependencies, but application code must enforce action permissions and stopping conditions. Add multiple agents only when separate responsibilities improve an observed problem; every additional handoff creates another place to lose context.
Exercise
Design approval for a sandbox ticket update. Simulate rejection, expiration, a ticket-version conflict, and duplicate execution requests.
Check: no unapproved write occurs; stale proposals require review; retries do not duplicate updates. Preserve the decision record without exposing sensitive ticket content in general logs.