Every product in this category runs into the same problem. To find the commitments buried in someone's inbox, you have to read the inbox. That is a lot of trust to ask for, and most companies handle the ask by writing a reassuring sentence about how seriously they take your privacy.
A sentence is not worth anything. What matters is what the system is physically capable of doing, because intentions change with funding rounds and acquisitions and architecture mostly does not.
So here is what actually happens to one of your emails.
What happens to a message
A message arrives in your Gmail. Wasp fetches it, deliberately fetching as little as it can: metadata and a snippet before anything fuller.
That text goes to a language model with one narrow question. Does this contain a commitment, and if so, what was promised, to whom, and by when?
The model answers. From that answer we keep a small number of derived facts: a one line summary written in our words rather than yours, who it involves, the date if there is one, and a link back to the original message in Gmail.
Then the message text is gone. It exists in memory and on the processing queue for the seconds the analysis takes, and after that it is not anywhere.
The important part is what that means for the database. There is no column anywhere in it that holds the body of one of your messages. Not encrypted, not truncated, not in a log. The schema has one field called body in the entire system, and it holds the text of Wasp's own push notifications, which we wrote.
Why that is a structural claim rather than a policy one
The distinction is the whole point of this post.
A policy is a decision about what to do with data you are holding. It can be revised. It can be quietly widened in a version of the terms nobody reads. It can be overtaken by an acquisition, or by a subpoena, or by a future team under pressure to build a feature that would be so much easier with the raw text.
Not having somewhere to put the data is a different kind of guarantee. If a court asked us for the contents of your inbox, the answer would not be a refusal. It would be that we do not have it. If a future version of this company wanted to train something on your correspondence, the correspondence would not be sitting there waiting.
This is also why we would rather you did not take it on faith. It is the kind of claim that can be checked. Ask us what tables exist and what is in them. Export your data, which is a button in the app, and look at what comes out. It is derived summaries and links, and it is much less interesting reading than you might expect, which is the intended result.
The honest exception
There is one, and burying it would undermine everything above.
When you ask Wasp to draft a reply, it reads the conversation you are replying to, plus a few of your own recent sent messages so the draft sounds like you and not like software. That is more content than the detection path ever sees.
Three things bound it. It happens only when you click, never in the background. The content is used for that one request and is not stored or logged. And it is the same class of processing that was already happening, just with more of the thread.
We could have left that out of the privacy page and almost certainly nobody would have noticed. It is on the privacy page.
What we do keep, and why it is dull
The derived record for a commitment is roughly: a short summary in our words, the person involved, a date if one exists, a status, and a link.
That link is the design decision that makes the rest work. Because there is a deep link back to the original message in Gmail, we never need our own copy of the content. When you want to see what was actually said, you open the real thing in the real place, authenticated as yourself. We are pointing at your data rather than duplicating it.
The same rule holds in the places where it would have been convenient to break. Wasp compares commitments against each other so that the same promise made in email and repeated in chat does not appear twice on your list. That comparison works on the derived summaries, never on the original text. The tokens that let us read your accounts at all are encrypted and writable only by the server, never by the browser.
What we do not do
Your data does not train models. We use commercial API tiers that contractually exclude it, and when we chose an embedding provider we picked the one whose API excludes training by default rather than one where we would have had to opt out and hope. An opt out is a setting. A default is a property.
We do not sell anything to anyone. There is no advertising business here and no data business, only a subscription, which is a large part of why the incentives stay simple.
And Wasp does not act on the outside world by itself. It does not send an email or book a slot in your calendar without you pressing the button.
The part that is genuinely a trade
Wasp is a cloud product. Your messages do transit our processing queue and our model providers during the seconds of analysis. We considered the fully local version and did not build it, and the reason is unglamorous: the product needs to work while your laptop is shut, because commitments slip at the weekend and deadlines pass overnight. An assistant that only chases you while you are already at your desk is not much of an assistant.
So the claim is not that your data never leaves your machine. That claim would be false and we are not going to make it. The claim is narrower and true: it passes through, it is used for one specific question, and what survives is a sentence we wrote about it.
That trade seemed like the right one to us. It is also stated plainly enough that you can decide it is not the right one for you, which is more than you get from a sentence about how seriously we take your privacy.