You hit confirm, and about six seconds later you see it. The TL;DR still carries the old delivery date — the one you fixed in the conversation and never fixed in the draft. Your hand goes looking for a button that is not there.
The answer for RelayLink is no. There is no unsend after delivery. What does exist is narrower than you want and better placed than you would expect, and it is worth being precise about both.
The only recall is cancel_draft, and it happens before delivery
Sending is two steps by construction. draft_package composes the package and parks it server-side. You read it rendered exactly as it will arrive. confirm_send, from your own account, releases it.
Everything between those two steps is fully reversible. cancel_draft destroys the package, list_drafts shows what is still waiting on you, and a discarded draft costs nothing because nothing was ever delivered.
After confirm_send there is no equivalent call. That is not a gap in the roadmap. The tool set has nine tools and none of them is unsend: the design treats the send as final and puts the reversible moment in front of it.
Most "undo send" is a delay, not a retraction
The undo you are picturing usually is not one.
The common pattern in ordinary mail is a hold window: your message sits for a few seconds before it actually leaves, and "undo" during that window means it never went. That is a cancel, not a recall — the same category as cancel_draft, with a shorter window that runs automatically instead of waiting for you.
The other pattern is retraction inside a closed system, where sender and recipient live on the same server. It works only within those walls, usually only if the message has not been opened, and it tends to announce itself in the process. Outside the walls it does nothing at all.
Neither one takes a message back from someone who already has it. Once the bytes are on another party's system, unsend is a request, not a capability.
A delivered briefing is already in several places
Trace where a briefing has gone the moment you confirm it.
It is in the recipient's email. RelayLink does not touch, read, or connect to anyone's inbox — it is a separate channel — so there is nothing on their side it could reach into even if the button existed. The magic link may be open in a browser tab. And if the recipient has their own assistant connected, that assistant may already have pulled the package and the content now sits in a private session on their side, a place no server can reach.
Thread status will tell you whether the latest package has been seen, but "seen" spans their assistant pulling it and a person opening the email — so you cannot know which of those happened. An "unsend" that quietly deleted the server copy while the email sat in their inbox and a paraphrase sat in their assistant's context would not be a retraction. It would be a comforting story about one, told to the only person it could still hurt.
Put the reversible step before the irreversible one
Every genuine undo does one of two things: it delays the action, or it reverses an effect that never left the system's own walls. Correspondence is neither. So the only honest place to put reversibility is before the send, which is the whole argument for the approval step.
That makes the pre-send read the highest-leverage thirty seconds in the flow, whatever you draft with. On RelayLink it shows the rendered package rather than a summary of it, and the pass that catches the most is reading it as the recipient rather than as the author. Four things break most often:
- Numbers and dates, which the assistant carried forward from an earlier turn in the session.
- The ask — whether the response shape you want is actually the one stated.
- Assumptions labelled inferred by sender's AI, which is where a reasonable-sounding claim you never made tends to appear.
- The recipient, checked last and out loud.
Then use cancel_draft without ceremony. Discarding a draft and redrafting is cheap; it is the only step in the flow that is.
Once it is out, the correction is the remedy
Something will still go out wrong, because review is a filter, not a guarantee. The repair is a correction on the same thread, sent quickly and written to stand alone: what was wrong, what the right version is, and what changes for the reader.
Same thread is the part people skip. A correction that lands on the original thread arrives attached to the thing it corrects, so anyone reading later — including the recipient's assistant — sees both together. A separate note saying "please ignore my last message" arrives detached from what it is about, which is why nobody ever ignores the last message. There is more on wording in how to correct something your AI got wrong.
The case nothing covers
Here is the honest limit. If you confirm a briefing to the wrong person, it is gone, and RelayLink will not even tell you whether they read it. There is no version of this design where that is recoverable, and no amount of good structure makes it feel better.
The mitigations all live upstream: the recipient is named on the review screen, reaching someone new is hard-capped per day and has to be a full briefing rather than a background ping, and every message carries an unsubscribe that blocks you permanently at the relay. That is thinner than an unsend button. It is also true, which an unsend button would not be — and a system that promises retraction quietly teaches you to review less carefully, which is the more expensive habit.
To see what review actually puts in front of you, walk through the full send flow, or connect your assistant and cancel your first draft on purpose.