Separate preparation from execution

A support workflow can retrieve evidence, check policy and prepare a complete proposed action without write access. A person then sees what will change before any mutation occurs.

Represent the proposal as data, not a paragraph hidden in the conversation. It should include the target object, current version, proposed fields, reason, source references, expected side effects and expiry time. The interface can render that record for review while preserving the exact payload that would be sent.

The approval screen needs to answer basic questions quickly:

• What object will change?
• Which fields will change, from what value to what value?
• Which external messages or downstream jobs will follow?
• What source material did the agent use?
• Did any source conflict or remain unavailable?
• How long is this proposal valid?

Approval belongs to the proposed action, target version and reviewer. A general "allow" response in chat is too easy to detach from its context. Store an approval record with the task ID, proposal hash, reviewer identity, timestamp and any edited fields.

If the reviewer changes the payload, either treat the edit as a human action or create a revised proposal that shows the difference. Do not record the original agent proposal as approved when a materially different action was sent.

Approval should be consumed once. Replaying an old approval after timeout, task restart or target-state change must fail. Recheck the reviewer's current authority at execution time because their role may have changed since the proposal was created.

Some low-consequence actions may eventually run without case-by-case approval. Make that a separate policy decision based on observed task results, reversibility and monitoring. Repeated confirmation does not change the policy; broader authority requires an explicit policy revision and its own review.