Writing AI email rules that actually work
AI can filter email using plain-English rules, if you write them well. How to phrase deterministic rules, why vague ones fail, and patterns that hold up.
Filters you can write in English
Classic email filters match on mechanical facts: sender contains X, subject starts with Y. They're fast and predictable, but they can't answer questions like "is this a booking confirmation?" or "is someone actually asking me for something?" Those are questions about what an email means rather than what it contains.
AI rules close that gap. You write a sentence in plain English, and a language model evaluates each incoming email against it: keep or drop, route here or there. It feels like magic the first time. But there's a craft to it, and the difference between a rule that works every time and one that misfires weekly is entirely in how you phrase it.
The golden rule: describe the email, not yourself
Here's the failure mode we see most. Someone writes the rule "I like trains" and expects it to keep railway booking confirmations. The model now has to guess: does a National Rail marketing newsletter count? A news article mentioning a derailment? A LinkedIn job alert from a rail operator? The rule describes the user's taste, and taste is not a property an email has. Every evaluation becomes a coin flip weighted by the model's mood.
Compare: "Booking confirmation from any UK train company." Now the model is checking observable properties: is it a booking confirmation (a document type with clear signals: reference number, journey details, transactional tone), and is the sender a UK train operator? Both are things the email itself either exhibits or doesn't. Same intent, radically different reliability.
The test to apply before saving any rule: could a competent stranger, shown only the email and your sentence, decide yes or no without asking you a follow-up question? If they'd need to know your preferences, your history or your mood, the model needs that too, and it doesn't have it.
The anatomy of a deterministic rule
Strong rules tend to name three things: the type of email, the kind of sender, and the boundary cases you care about. You rarely need all three, but each one you add removes a dimension of guesswork.
- Type: "a booking confirmation", "a security alert", "an invoice or receipt": document categories with recognisable structure
- Sender kind: "from an airline", "from a bank or payment provider", "from an automated system rather than a person"
- Boundaries: "but not marketing or promotional content", "only if it requires an action from me", "excluding newsletters"
- One decision per rule. "Keep invoices and also anything urgent" is two rules wearing a trench coat. Split them.
Rules that work, and their vague evil twins
A few pairs from real usage. In each case the left phrasing behaves consistently; the right one drifts:
- "Order or shipping confirmation for a physical purchase", not "stuff I bought"
- "Security alert about a login, password change or new device", not "important account stuff"
- "A real person writing to me directly and expecting a reply", not "emails that matter"
- "Invoice, receipt or payment failure notice from any service I subscribe to", not "money things"
- "Job application or interview correspondence from a candidate or recruiter", not "work emails"
Layer AI on top of cheap rules, not instead of them
AI evaluations cost more than string matching (in money, latency and occasional wrong answers), so don't spend them where a dumb rule suffices. If everything from noreply@github.com should route to your dev channel, that's a sender match, not a judgement call. The efficient pattern is a cascade: deterministic rules handle the known senders and obvious spam first, and the AI rule only evaluates the residue where meaning actually needs judging.
This is how filtering is structured on HideMy.world: each address carries a rule set mixing classic conditions with AI rules written in plain English, and plans meter AI evaluations (250 a month on Lite, 1000 on Pro) precisely because the cascade means most mail never needs one. A well-ordered rule set spends its AI budget only on the genuinely ambiguous minority.
Debugging a rule that misfires
When a rule gets an email wrong, resist the urge to rewrite it from scratch. Diagnose like a bug: was the email genuinely ambiguous, or did your rule leave a gap? A misfire usually points at a missing boundary clause. The train company's "20% off spring fares" got kept? Your rule never said "but not marketing". A password reset was dropped by "security alerts only"? To the model, a reset you requested may not read as an alert. Name it explicitly.
Fix by adding the smallest clause that settles the case, then re-check your earlier examples still pass. Rules converge fast this way: most stabilise after two or three refinements, because each clause eliminates a whole family of ambiguity, not just one email. If a rule still wobbles after several rounds, that's a signal it's really two decisions: split it and let each sentence do one job.
Test like it's code, because it is
A plain-English rule is a tiny program, and untested programs are wishes. Before trusting one, run your recent real emails through it mentally (or better, literally) and check the verdicts. Pay attention to near misses: the marketing email from a train company, the newsletter that quotes an invoice. Those boundary cases tell you which clause to add.
And revisit rules occasionally. Senders rebrand, newsletters change tone, your own needs shift. The habit that keeps AI filtering trustworthy is the same one that keeps code trustworthy: when it surprises you, don't shrug: tighten the spec.
Written this way, AI rules stop being a novelty and become the most leverage-per-word automation you own: one careful sentence, filtering thousands of emails, exactly the way you meant it.