Email rules in plain English: filters without the syntax

You can describe an email rule in a sentence and get a real one. Type “label anything from stripe.com Receipts and archive it” into Conduit Mail, an AI-powered email client in early access, and you get back an automation with a trigger, a condition tree, and an ordered list of actions — one you can open and read.

No operator syntax, no form full of fields to fill in first. That sounds cosmetic. It isn’t: almost nobody automates their inbox, and it was never because the idea was hard.

Why does everyone give up on Gmail filters?

Gmail’s filter dialog is a form: fields for the sender, the subject, words the message does and doesn’t contain, and checkboxes for what to do about it. Every part of it works. Together they ask you to translate a thought you already had — “stop letting deploy notifications interrupt me” — into a schema you hold in your head for the ninety seconds the dialog is open.

A form like that is easy to get subtly wrong, and a subtly wrong rule is worse than no rule. So the dialog gets opened a few times and then stops getting opened, and the triage stays manual. That isn’t a knowledge gap; it’s an interface tax, charged every time you have an idea.

Describing the rule in words removes the tax. You had the thought; the thought is the input.

What does a plain-English rule actually turn into?

Not a prompt that reruns forever. That distinction is the difference between an automation and a monthly bill.

You describe the rule once. The AI writes it once. What gets saved is a structured rule — trigger, conditions, actions — that then runs as ordinary code against your mail.

Deterministic conditions like “from this domain” or “has an attachment” are evaluated without a model. AI is spent only when a rule genuinely needs judgment, and a saved rule that uses AI carries a usage indicator on its card in Settings → Automations.

Here is the sentence, and here is what gets saved.

You type:

Label anything from stripe.com Receipts and archive it.

Conduit builds:

The values in that table are illustrative — the shape of the output is the point, not those exact fields.

Every part of it is on screen after you save, so you can read the trigger, conditions and actions back and check they’re what you meant. What you can’t do yet is change a field in place: there’s no per-field editor, so a rule you disagree with gets switched off or deleted and described again. Retyping a sentence is cheap, which is why reading what came back matters.

The 12 conditions and 12 actions a rule can use

This is the whole vocabulary: twelve things a rule can notice, twelve things it can do. Read both lists once and you can predict what any sentence will produce.

What a rule can notice

Twelve condition types, combined into AND/OR groups, and any single condition can be negated.

rate_exceeded is the one people don’t expect. It’s stateful: it counts messages per sender or per domain inside a time window you set, so you can write “when this thing starts flooding” rather than “when this thing emails.” It’s what gets the forty-first status-page email archived on arrival while the first one still reaches you.

A note on category_match: those six categories are assigned automatically as mail arrives, the sorting is not always right, and an overhaul is queued for exactly that reason. If a rule matters — money, school, your boss — anchor it on a sender or a domain and use the category as a broad net, not a guarantee. (More on the sorting in what Conduit does with a Gmail account.)

What a rule can do

Twelve actions.

Listed order holds among actions of the same kind: label first, then archive, and the label is on the message when it leaves the inbox. Across kinds it’s fixed. The actions that change the message — label, archive, star, mark_read, trash — apply first, and the ones that generate text or fire outward run after, so listing summarize above label doesn’t push the label any later.

Rules that need judgment, and what they cost

ai_match is the way out of the schema when no field can express what you mean — “the sender is asking to reschedule,” “this is a receipt rather than a shipping update.” Use it where you need it, and let deterministic conditions catch everything they can, because those cost nothing to run.

The cost model fits in three lines, worth knowing before you save a rule to a sender who emails you forty times a day:

• Writing the rule from your sentence uses AI once, when you create it.
• A rule made only of deterministic conditions and deterministic actions (label, archive, star, mark_read, trash, notify, save_to_notes) runs on no AI at all, however often it fires.
• A rule containing ai_match, summarize, draft_reply, or custom_prompt spends AI usage every time it fires.

Two actions sit outside that split. webhook costs nothing unless you turn on AI extraction of the payload, in which case it spends on every fire. digest only collects today: the batching is free, and the scheduled pass that would summarize and deliver a batch is still being built.

That third line is why a saved rule that uses AI carries a usage indicator on its card in Settings → Automations, showing the share of your usage it has spent. A rule that summarizes every message from a chatty sender is one you want to notice before it eats the month. The indicator is hidden if you’ve turned off AI-usage transparency or brought your own API key.

Free plans get Standard AI; paid plans get Smarter AI and a much larger monthly allowance — Plus is about 6× Free. The details are on the pricing page.

Triggers: what actually starts a rule

The rule format carries more than one trigger type. Exactly one runs against your mail today, and knowing which saves you from building a rule that quietly does nothing.

On new email. The one that runs. Every plan, fires as mail arrives, and it’s what you get when your sentence doesn’t name a trigger.

On a schedule. A cron trigger with a real IANA timezone, so “every weekday at 07:00 in New York” survives the clocks changing. Creating one is a Pro feature, but the piece that runs a scheduled rule against your mail is not wired up yet. Until it lands, a scheduled rule sits there without acting — don’t plan a cleanup around one.

Schedules are worth wanting because some conditions can’t be answered on arrival. You cannot ask a brand-new message whether it’s a month old, so anything built on age_hours needs a clock.

Everything you can build today starts on arrival instead:

When my kid’s school emails, summarize it and send me a notification.

Trigger: on new email. Conditions: domain_match: the school's domain. Actions: summarize → notify. Illustrative — the domain and the actions are yours to set.

Five rules free, unlimited on paid plans

The Free plan allows five automation rules. Paid plans are unlimited.

Five is enough to prove the idea and not enough to run your life on, which is worth saying here rather than at rule six. Most rule sets get built one sender at a time — one per school, one per airline, one per bank — and that crosses five quickly.

So on Free, spend the five on the senders that cost you the most attention, and use domain_match rather than sender_match where a whole domain behaves the same way: one rule for @yourbank.com beats three.

Billing is not live during early access, so nothing is charged today; the plan prices are what paid plans will cost at public launch. Free is $0, Plus is $9/mo, Pro is $27/mo. The full breakdown lives on the pricing page.

What this doesn’t do yet

Three limits, stated plainly, because a how-to that only lists strengths isn’t one.

No back-test, no dry run, no match preview. Nothing shows you which of your existing messages a rule would have caught, and no pass goes back over what’s already there. An on-arrival rule only sees mail that arrives after you turn it on.

That means a cleanup is two jobs. Write the rule to handle everything from here on, then do the backlog by hand in Gmail (here is the full afternoon): search for the sender (from:receipts@store.com), use Gmail’s option to extend the selection to every conversation matching the search, and apply the label or archive in one action. Backlog first, then turn the rule on, and the two halves meet in the middle.

Until a preview exists, start a new rule with a label instead of an archive, watch what it catches for a day, then add the action that moves mail.

AI conditions consume AI usage. A rule with ai_match, summarize, draft_reply, or custom_prompt spends AI every time it fires, and so does a webhook with AI extraction turned on. Everything else costs nothing to run, no matter how often it triggers. Rules that do spend show their share on their card in Settings, so a chatty rule surfaces rather than staying mysterious.

Webhook actions are fenced in. A rule that POSTs your mail somewhere runs its destination through an SSRF filter, so it can’t be aimed at addresses inside our network, and every delivery lands in the delivery log in Settings → Automations, which is where you find out that one is firing more than you expected.

How to describe a rule so it comes out right

Four habits, all downstream of one fact: the sentence is a one-time input, and the rule is what you live with.

Name the trigger in the sentence. “When it arrives” and “every morning” produce different rules, and only one runs today. Say nothing and you get on-arrival, which is the one you want.

Be specific about the deterministic parts, loose about the fuzzy part. “From stripe.com” beats “from Stripe.” Save the vague description for the one condition that genuinely needs judgment.

Say what happens to the message, in order. Label, then archive. Draft, then notify. Within a kind, the order you say is the order it runs.

Read what came back. The rule is right there in fields on its card. Ten seconds now beats finding out next Tuesday that it matched a whole domain when you meant one address — and since you can’t edit a field in place yet, catching it early costs one retyped sentence instead of a week of mislabeled mail.

That last habit is the whole argument. A sentence is a good way to create a rule and a bad way to store one, because next month you won’t remember what you meant. So the sentence is the input and the structured rule is the artifact: readable, inspectable, yours to replace when it’s wrong. Same split we keep making everywhere else in the product, for the reasons we started building it.

Write your first rule as a sentence — get early access. Start with the sender that interrupts you most.