Does an approval button before “send” stop a bad message, or only delay it?

It only delays a bad message. An approval button stops the send only when the agent cannot proceed without that click, the screen shows the exact recipients and the full body, there is no second tool that sends, and you actually read those bytes. Most buttons fail at least one of those. What they do instead is pause for as long as it takes you to tap Approve on a summary. The message that goes out is still the bad one. The button added ten seconds and a false sense that a person checked it.

I would rather have no send tool than a button I have learned to clear. The button is a speed bump. A missing tool is a stop.

The card I approved between meetings

The button showed a title the model had written: “Reply to Sam about the date.” Under it, one line: “Confirms Thursday and keeps the tone short.” I was on my phone, walking out of a room. Thursday was the day I had been considering. The summary matched the task I thought I had set. I tapped approve.

The message that left included a CC to a second person named in an old note, and the body said we would deliver on Thursday, not that Thursday was a possibility. The summary had not listed the CC. It had turned a hedged date into “confirms.” The button worked. The gate was the summary, and the summary was written by the same model that wrote the bad message.

That is the ordinary failure. Not a bypass, not a bug in the dialog. A person approved a description of the message. The description was marketing. The bytes were the send.

What the button has to show, or it is only a delay

To, Cc, Bcc, Subject, and the full body. Not a model-written headline. Not the first eighty characters. Not “1 attachment” without the filename. If any recipient is hidden behind “and 3 others,” the button is a delay until you tap through, and you will not tap through when you are late.

Attachments matter as much as prose. I have approved a short note and only later seen that the agent attached a spreadsheet that was open in the folder, because the card said “notes for Sam” and the file was called notes. The button delayed the send by the length of my glance. The glance was at the title.

If the product cannot show the exact message in the approval surface, do not use the button as your control. Write the draft to a file and paste it yourself. Pasting is slower and it is the version where your eyes touch the recipients. A card that cannot hold the body is not a review. It is a notification with a green button.

Habit is the delay

The first week I read every card. The third week I read the title and the first line, because the previous twenty had matched. The model had learned nothing from my care. I had learned that the button was in the way of a task I already believed was done. Approval fatigue is the design working as experienced, not a personal failing you can slogan away.

A second click that says “I read this” does not help if it sits directly under the first and you press both. I do not want a ritual. I want the default to be that nothing sends. The button inverts that. The default of an agent with a send tool is to reach the button, and your default becomes clearing it. Delay is the time between those two habits.

Batching approvals is worse. A queue of six “ready to send” cards at the end of the day is how a bad one hides between two boring ones. I will not clear a queue. If there are six, the tool is sending too much, and the drafts should have been files.

A yes in the chat is not the button, and it still sends

Some setups treat a later “yes,” “ok,” or “go ahead” as the approval, because the button was annoying and the chat is where you already are. That is a shorter delay with less to read. The model attaches your yes to whatever send it has queued, including one you have not opened. I stopped saying yes in a thread where a send tool exists. I say yes to a file path. If the only way to approve is a sentence in chat, I do not count that as a button at all. It is a delay of one word, and the word is easy.

The same trap is a button on a different action. You approve “save draft,” and the next step the agent takes, already authorized by a broader grant, is send. You approved the calm verb. The tool list still had the other verb. A button stops a message only if send cannot happen until this click, and no other click you already made counts.

When the button does not even delay

If the agent can send while the dialog is sitting there, through a second integration, a browser session that is already logged in, or a retry that uses a different tool name, the button did not delay anything. You get the card and the sent mail. I check for this once, on purpose, to myself: trigger a send, do not press the button, and watch the sent folder. If the message arrives, the button is theater. Remove the other path before you debate the wording on the card.

A timeout that sends anyway is the same failure with a clock. “If you don’t respond in ten minutes, I’ll send” is not an approval. It is a delay you lose by being in a meeting. I turn that off or I stop using the product. Silence is not a yes.

The case where I would keep a button

I would keep one only as a second line behind a draft I already read, and only if I am not the person speed-running it. Two people: one writes, the other sees To, Cc, subject, body, and attachments, and the message cannot leave until the second person acts. That can stop a bad message, because the second person is not trying to finish their own task. A solo button on your own agent is you approving yourself, tired, on a summary.

Even then I want the draft to exist without send. The button is for the moment of sending, after the text is frozen. If the agent can edit the body after you approved the card, the thing you read is not the thing that leaves. Freeze the bytes. Approve those bytes. Or do not send.

Which mistakes the button is supposed to catch

People install the button to catch a rude sentence. The mistakes that actually cost me were a recipient and a promise. Tone is what the summary is good at describing, which is why the card looked fine. The CC line and the Thursday commitment were facts, and the card had paraphrased them into something I already believed. If your button is there to stop embarrassment, it will feel successful right up until it approves a clear, polite, wrong commitment.

I also do not use one approval to cover a series. “Approve sending updates” is how the third message in a thread goes out with a detail you only checked on the first. Each send is its own bytes. A standing approval is a delay of zero on every message after the one you read. If the product offers “always allow send to this contact,” that is the send tool coming back under a calmer name. Sam is not a safe recipient for every future sentence. He is the person who received the Thursday promise.

What I do instead

The agent writes the file. I open it. I copy it into the mail client. The client is the button, and it shows the fields the mail provider will actually use. There is no agent-side Approve that I can tap from a lock screen on a title. If that feels too slow for the volume, the volume is the problem. I am not behind on email because I lack a green button. I am behind because I gave an agent a send tool and then had to babysit the babysitter.

If you already have the button, change what it displays before you trust it. Exact recipients, full body, attachment names, no send on timeout, no send on a chat “yes,” no second path. Then watch yourself for a week. If you tap through on the title, the button has gone back to being a delay. Take the send tool off. The bad message does not need a faster pause. It needs to not be able to leave. A button you can clear from a lock screen is a delay you have already agreed to stop noticing.