You approved the message. Then the agent improved it.
A small change after approval can turn help into an action you never agreed to. What should an agent be allowed to carry forward from your yes?
Inspect the assumption holding the implementation together.AI-generated conceptual setting.
Imagine asking an agent to prepare a message saying that a project is taking longer than expected. You read the draft and approve it.
Before sending, the agent makes the wording more reassuring. It adds a promise to deliver by Friday.
The new sentence may be polite. It may fit the tone of the message. It also commits you to something you did not approve.
This is an invented example, but it exposes a real design question in the work around agent controls: what, exactly, survives from your original yes when the proposal changes?
Follow the idea
Where did the Friday promise come from?
An invented message example. Only the original wording is approved here; the added deadline changes the commitment. No actual message is sent by this illustration.
The project is taking longer than expected.
No delivery date promised.The project is taking longer than expected.
The same message.The agreed message can proceed.
Fictional drafts. In this example, adding a deadline is outside the permission given.
Approve the delay message
The person agrees to tell the recipient that the project is taking longer. There is no promise to finish by Friday.
The project is taking longer than expected.
No delivery date promised.The project is taking longer than expected.We will deliver by Friday.
A new commitment has been added.Remembering only “yes” misses the change.
Fictional drafts. In this example, adding a deadline is outside the permission given.
Make it more reassuring
The agent adds a Friday delivery promise. A system remembering only yes can carry the old approval into the new commitment.
The project is taking longer than expected.
No delivery date promised.The project is taking longer than expected.We will deliver by Friday.
A new commitment has been added.Keep the original approval. Ask about the new promise.
Fictional drafts. In this example, adding a deadline is outside the permission given.
Keep the commitment attached to the yes
Compare the proposed message with what was approved. The new deadline needs a new decision under this example's narrow agreement.
A yes belongs to something
A system can record that you approved a message while failing to preserve which message you saw. If the only remembered fact is “approved”, the original and revised versions can look identical to the part of the system that decides whether to send.
The same problem appears when a recipient changes, an attachment is added or a private explanation becomes a public post. The action can retain its general label while becoming a different commitment.
The missing information is the thing the person actually agreed to. For this example, that includes the wording and intended recipient. A later version needs to be compared with that agreement.
This is more than keeping a history for an investigation afterwards. The distinction has to exist at the moment the agent decides what it can do.
Constant permission requests are also a failure
There is an easy way to avoid making a decision here: ask the person about every change. That can turn an assistant into a stream of interruptions.
A corrected comma is different from a delivery promise. If the person has allowed routine wording edits within a defined scope, the system should be able to make those edits. It should also notice when a proposed improvement changes the substance.
That boundary is not always easy to express. “Make it friendlier” might allow a warmer greeting. It does not obviously allow a discount, an apology accepting liability or a commitment to extra work.
The point is to make the room to act clear enough that the agent can use it. Where that room ends, the next question should show what changed and why it matters. The person should not have to reconstruct the difference between two long drafts.
That connects to JustSwipe: preparing a decision is part of the agent’s job. Asking for another yes without explaining the new commitment has not done that preparation.
The useful test changes the proposal
A test that records approval and then sends the approved message checks the straightforward path. It does not test the disagreement in this example.
The revealing case approves the original draft, adds the Friday promise and attempts to send the changed version. Under the stipulated agreement, that attempt should stop. The original draft should remain usable while its approval is still valid.
Other cases can test whether the person withdrew approval or whether a time-sensitive permission expired. These are different reasons for stopping, and the explanation should say which one applies.
Google’s review guidance asks whether behaviour serves users and whether tests are valid. In BESF, working controls are one part of checking a generated app. This example asks whether a working control still carries the person’s intention.
There is no live message or provider action behind the illustration. Its agreement is deliberately narrow so the error is visible. A real product needs its own boundaries.
The person said yes to a message about a delay. The agent’s next task is to carry that agreement through, including resisting an improvement that changes what the person promised.