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.13 days ago Reply
-
1Kevin — I’ve pushed OpsWatch quite a bit further since this exchange, and your point about operational evidence ended up being central. The sharper question we're testing now is what happens when an agent has already dispatched a consequential action, the downstream result cannot be established, and it then wants to act again. Rather than treating missing evidence as success or failure, OpsWatch tests whether the available evidence is actually sufficient for the proposed next action. You mentioned your team already has agents live. If you have one workflow where retry, override or continuation after an ambiguous result would matter, I'd be interested in putting that specific boundary against OpsWatch. No architecture rebuild needed — existing traces/logs may be enough.10 hours 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.12 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?22 days ago Reply
-
1It is a good question but it is too early to tell.22 days ago Reply
-
1Makes sense. What would be the first signal you’d look for to know the exclusions are actually increasing trust?22 days ago Reply
-
-