I added a setting that makes my AI product worse at its one job — on purpose
SignalAI's entire pitch is one sentence: it reads your inbox and texts you when something's genuinely urgent. That's the whole product.
I just shipped a setting that lets you tell it to stop doing that, for specific senders — completely. Not "don't text me," which already existed. Fully skip: the email is never even read by the AI, never classified, never stored. It just... doesn't happen.
Which means if something urgent ever came from that sender, you'd never know. I built a way to make my own product actively worse at the one thing it exists to do.
Here's why I think it's right anyway: some senders are your therapist, a lawyer, a specific relationship you don't want an AI anywhere near, period — not because the classification would be wrong, but because you don't want it to happen at all. No amount of "we don't train on your data" fixes that if the actual ask is "don't look."
Genuinely curious how others think about this — where's the line between a feature that's more private and one that's just a hole in your own product's usefulness?
-
1The enforcement point matters as much as the promise: for "never read" to hold up, the sender check has to run on headers alone, before the body ever reaches the model pipeline — same ingestion-boundary problem as exemption lists in enterprise mail gateways. And it pairs naturally with the independent-settings split from your Aug 30 post: exclusion at ingestion and suppression at notification should be two separate checks with separate audit trails, so a notification bug can never silently widen a privacy exclusion.6 days ago Reply
-
1You're right about the settings split — suppress_sms and skip_entirely really are two separate columns, checked independently, no shared path between them. To be direct about the "never read" part: for an excluded sender, the email is never classified, never sent to Claude, never stored in the database. That's the actual behavior. One precise nuance, though — on IMAP specifically, the fetch does pull the full message into memory before the sender check discards it, so it's not headers-only at the network level like your enterprise-gateway comparison. The enforcement point is right after that, not before it. Worth noting that moment never leaves memory, never gets written anywhere, and never reaches a model — even for senders that aren't excluded, Anthropic doesn't train on anything sent through the API at all, under the DPA covering it.5 days ago Reply
-
-
1The “don’t look” distinction feels important here. Have users who enable sender exclusions become more comfortable trusting SignalAI with the rest of their inbox?16 days ago Reply
-
1It is a good question but it is too early to tell.15 days ago Reply
-
1Makes sense. What would be the first signal you’d look for to know the exclusions are actually increasing trust?15 days ago Reply
-
-