Wasp can write the email you have been avoiding. It knows what you promised, who you promised it to, and how far past the date you are. It reads a few of your own recent messages to match how you actually write, drafts a reply that lands in the right conversation thread with the right people on it, and hands it to you.
It has the technical capability to send that email without you. It never will.
That is a product decision rather than a limitation, and since a great many companies are currently sprinting in the opposite direction, it is worth setting out the reasoning.
The distinction that matters
The obvious rule is "the assistant does not send email". It is also the wrong rule, because it makes the product worse without making it safer.
If you have read a draft, edited it, and pressed a button labelled Send, nothing alarming has happened. That is you sending an email. Forcing you to copy the text into another application to press a different button labelled Send is not a safety measure, it is an inconvenience wearing the costume of one.
So the rule we actually hold is narrower and, we think, the one that carries the meaning:
The difference is agency. Not whether an email can leave, but who chose that it should. Every send is a specific human decision about a specific piece of text, made after reading it.
In the code this is not a preference or a setting. Nothing scheduled, nothing automatic, and nothing that retries after a failure can reach the sending path at all. It is reachable from exactly one place: a button, pressed by a person, on a draft displayed on screen. If anything automated ever reached it, that would be a defect rather than a feature we had enabled.
Why we did not just take the safer sounding option
The version where the assistant sends its own chasers is genuinely attractive. It closes the loop entirely. You would never have to think about a slipped commitment again.
It also fails in a way that cannot be undone.
Almost every failure in software is recoverable. A wrong draft gets edited. A bad suggestion gets dismissed. A mis-parsed date gets corrected. Sending is the exception: the moment a message reaches another person's inbox, no amount of good engineering brings it back. You cannot apologize your way out of an email your software sent to a client in a tone you would never have used, about a commitment it had slightly misunderstood.
And our models do occasionally misunderstand. We have watched a date get read a day late. We have watched a reply that said "still waiting on legal, Monday instead" get treated as delivery of the thing rather than as a delay. Both were fixed. Neither would have been catastrophic in a draft you read before sending. Both would have been mortifying if the software had sent on its own.
The asymmetry is total. The upside of automatic sending is that you save a few seconds. The downside is a relationship. That is not a close call.
The part that is genuinely awkward
We would rather be straight about this than have you discover it on a consent screen.
To put a draft in your Gmail account at all, Google requires a permission that has no drafts-only version. The narrowest scope that allows creating a draft is presented to you, in Google's own words, as permission to send email on your behalf.
So the screen says one thing and our policy says another, and there is nothing we can do about the wording. We are not going to pretend that is comfortable. What we can do is be precise about the difference between what the permission technically allows and what the software actually does, and then constrain ourselves in the places where it matters.
The most important of those constraints is about recipients.
You cannot send to anyone you could not have drafted to
When Wasp prepares a reply, it does not ask the model who should receive it, and it does not accept a recipient list from the browser. The recipients come from the headers of the original message, on the server, and the interface can only narrow that list. You can remove someone. You cannot add anyone.
This closes a hole that would otherwise be wide open. Without it, the drafting feature would amount to a way of addressing mail from your Gmail account to any address at all. With it, the surface is bounded by conversations that already exist. Sending shares every one of those rules with drafting, which is what makes it safe to offer at all: there is no address reachable by the send button that was not already reachable by the draft button.
Before anything goes, the app asks you to confirm, and names every recipient in the confirmation rather than saying "send this?". You should always know exactly who is about to receive something.
What this costs us
We are aware this makes the product less magical in a demo. "It chases people for you automatically" is a better sentence than "it writes the chase and you press send".
We think the second sentence is the one that survives contact with a real business relationship. The value was never in saving you the click. It was in removing the part that actually stops people, which is sitting down to compose an awkward message about something you are late on. That part is done. What is left is reading four sentences and deciding they are right.
There is a broader version of this we hold to as well. Wasp is built to apply pressure to you. It escalates, it refuses to let you snooze indefinitely, and it will tell you when you have moved something eleven times. All of that pressure points inward, at the person who asked for it. The moment software starts acting outward, toward other people, on its own initiative, it is making decisions on your behalf in your relationships. That is a different product with a different risk profile, and it is not the one we are building.
The assistant chases you. You chase everyone else. It just makes that much easier than it was.