Keep preparing an action separate from doing it

A support workflow can gather evidence, check policy and put together a complete proposed action without any write access at all. A person then sees exactly what will change before anything is modified.

I'd represent the proposal as data, instead of a paragraph buried somewhere in the conversation. It should include the target object, its current version, the proposed fields, the reason, source references, expected side effects and an expiry time. The interface can render that for review while keeping the exact payload that would be sent.

The approval screen should let the reviewer answer some basic questions quickly:

• Which object will change?
• Which fields will change, and what are the old and new values?
• Which external messages or downstream jobs will follow?
• What source material did the agent use?
• Did any source conflict, or was any of it unavailable?
• How long is this proposal valid for?

An approval should be tied to the specific proposed action, the target version and the reviewer. A general "allow" typed in chat is too easy to separate from what it was meant to approve. Store an approval record with the task ID, a hash of the proposal, the reviewer's identity, a timestamp and any fields they edited.

If the reviewer changes the payload, either treat the edit as a human action or create a revised proposal that shows the difference. Don't record the agent's original proposal as approved when something materially different was actually sent.

Each approval should be usable once. Replaying an old approval after a timeout, a task restart or a change to the target's state has to fail. I'd also recheck the reviewer's authority at execution time, because their role might have changed since the proposal was created.

Some low-consequence actions might eventually run without case-by-case approval. I'd treat that as its own policy decision, based on observed task results, how reversible the action is and what monitoring is in place. Someone clicking "approve" a hundred times doesn't change the policy. Broader authority should need an explicit policy revision with its own review.