A person reviews a proposal to move 24 due dates to Friday. Before the agent runs, another task enters the project, one task becomes locked, and the connected account loses access to a second workspace.
The approval hasn’t answered what to do about any of those changes. An approval records a decision about the proposal the person saw. The product still has to decide whether that decision covers the operation the agent is about to run.
The useful starting question for approval design is: what exact work did this person agree to, and under whose authority can the work now happen? The approval card is one part of the answer. The selection, the arguments, the acting account, the checks at execution, and the receipt all have to agree with the card.
Turn the plan into an exact proposal
“Move the launch to Friday” could mean changing the launch date, shifting dependent tasks, or notifying customers. Approving a plan in those words doesn’t approve every action the agent later invents to carry the plan out.
Make the proposal narrower: change only the due-date field on these 24 unfinished tasks, in this project, to a specific calendar date. Show the selection rule and let the person inspect the list. Name the exclusions that matter, such as completed tasks. Keep the exact date visible rather than relying on “Friday.”
The operation record holds the proposal’s version, the target IDs, the intended values, and any condition that would make the proposal expire. The interface translates that record into readable language, instead of summarizing a vague instruction that execution will interpret again.
Not every detail belongs on the first screen. The person needs the facts that could change the decision: the project, the scope, the changes, any effect outside the product, and what recovery is available. Record-level detail can expand from there. Raw JSON is not a substitute for explaining consequences.
What the card can and can’t show
A private draft, a bulk edit, and a message to customers could each be a single tool call, with very different consequences. A title such as “Send to 1,240 customers” makes the outside effect visible. The title is still incomplete if the person can’t inspect which customers, what message, and which sending account. A count summarizes a selection; a count doesn’t explain one.
For a due-date change, the important limit might be that restoring dates will keep later edits and can’t recall notifications. A fact like that helps more than a risk badge with no explanation. Specific button labels, like “Move 24 dates” instead of “Continue,” keep the consequence next to the decision. A good label still can’t make an incomplete proposal safe.
Preparation and commitment can live in different places
Shopify documents Sidekick preparing changes that merchants review in the product’s own screens, and says the changes apply only after the merchant reviews them and clicks Save. The review gets a concrete destination: inspect the real fields, then save. The Save gate doesn’t establish a universal rollback, or prove that every Sidekick operation uses the same boundary. Shopify’s review and save guidance
The design question is where commitment becomes unambiguous. A conversational “Looks good” might approve a suggestion while a native Save applies the change. When those are separate steps, say what remains after the first one. Two reassuring confirmations don’t help when the person can’t tell which one acts.
The approver and the acting account may differ
Notion documents that MCP connections for Custom Agents use the credentials of the person who set up the connection. People who can interact with the agent can approve or cancel the agent’s writes, even without their own access to the outside tool. Notion’s MCP connection permissions
“The approver must personally hold the outside permission” is therefore not a universal rule. A product can deliberately let someone direct an agent that acts through a different account. The enforcement question is whether the delegation lets this person approve this operation, and whether the acting connection still has the access the change needs. Show a recognizable account and destination before execution, never the credentials themselves.
An approval record can’t create authority by stating that a user consented. The service must check the relationship.
When the world changes after review
The extra task in the opening forces a choice: keep the reviewed list, or prepare a refreshed proposal and ask for a new approval. Once approved, either policy freezes the exact list. A changed selection is only one way an approval can stop applying:
| Change after review | Decision the product needs |
|---|---|
| Another record matches the original search | Leave the record out, or prepare a new reviewed list |
| A reviewed record has a newer version | Keep the newer edit, report a conflict, or ask for a revised proposal |
| The destination or sending account changes | Decide whether the approval covers the new destination |
| The approver loses the delegated role | Check the approver’s authority again under the execution policy |
| The connected account loses write access | Block the write and explain what was blocked |
| The worker times out after the change landed | Look up the result before deciding whether to retry |
The table is a design checklist, not one policy for every product. Some tasks let eligible records go ahead while reporting exceptions; others need all-or-nothing. When partial completion would change the person’s decision, say which policy applies before the approval.
Checks must hold at the moment the effect happens. Reading a permission or a version, waiting, and then writing unconditionally leaves a gap. The backend or the destination service has to enforce the check; a warning in the interface can’t close the gap.
Standing approval
A person might set up a rule to prepare overdue-task proposals every morning. A rule like that can authorize future work without another click for each step, as long as the rule names its trigger, allowed actions, scope, limits, and acting account. “Always allow,” with no clear object, is hard to supervise. A rule that allows private drafts shouldn’t quietly grow to cover customer messages when someone adds a new tool.
An approval is useful when the approval lets a person make a better decision about real work. The decision needs an understandable proposal, a valid delegation, execution within the agreement, and a receipt that explains what happened, including the parts that didn’t.