I used to think email was a terrible place for AI.
Too messy.
Too human.
Too full of forwarded chains from 2017 and HTML generated by software nobody at the company can name.
Then I spent some time reading inbox automation threads, especially a good one on r/openclaw about email flows, and the pattern finally clicked: Email is a great surface for AI if you stop making the model act like your mail server.
That sounds obvious.
But a lot of inbox automations still do this: new message arrives ask GPT-5 if it is support ask Claude if it is sales ask another model if it is spammy ask again which alias it belongs to ask again whether to reply now or later That is not intelligence.
That is expensive amnesia.
The better pattern is simple: code owns state, retries, scheduling, sync, and verification the LLM only handles decisions that actually require judgment That split made my inbox workflows cheaper, easier to debug, and way less fragile.
The rule I keep coming back to A comment from an OpenClaw workflow discussion said it better than most docs do: If your workflow stops working when you hit your LLM usage limit, the LLM is probably doing too much.
That was about coding agents, but it applies perfectly to inbox automation.
If your email pipeline depends on a model to remember mailbox state, dedupe events, handle retries, or re-check routing rules every run, you built the wrong system.
Models are good at judgment.
They are bad at being custodians.
Email feels chaotic, but the transport is already structured Humans experience email as chaos.
Machines do not.
Every message already arrives with useful structure: thread identifiers message IDs headers timestamps raw MIME attachment boundaries alias addresses That matters because a lot of routing decisions should never hit an LLM in the first place.
If invoices always go to , GPT-5 should not be rediscovering that rule every morning.
If support mail always lands on a specific alias, code should route it deterministically.
If a thread was already processed, your worker should know that from a database, not from a prompt.
What the model should do Use GPT-5, Claude Opus 4.6, Grok, Qwen, or Llama for the parts that actually need reasoning: classify ambiguous messages summarize long threads extract intent from ugly forwarded chains draft replies for human review decide whether an attachment looks like a contract, invoice, or support artifact What code should do Everything repetitive: sync mailbox changes persist sync tokens enforce sender and alias rules schedule follow-ups retry failures suppress duplicate processing verify whether a thread was already handled log decisions for auditability That architecture is less flashy than "AI inbox agent." It is also the architecture that still works next month.
Gmail’s quota numbers basically tell you how to build this This is the part that changed how I think about inbox pipelines.
Google publishes quota costs for Gmail API methods. = 2 quota units = 5 quota units = 20 quota units = 40 quota units = 100 quota units Those numbers are not trivia.
They are design hints.
Google is telling you to do this: watch for changes fetch only what changed apply deterministic filters call an LLM only for edge cases Not this: poll the inbox every minute fetch everything unread dump whole threads into Claude repeat forever If your workflow wakes up every minute and asks a frontier model to inspect all unread mail, you did not build automation.
You built a recurring bill.
A sane Gmail pipeline For Gmail, the pattern is straightforward: subscribe to inbox changes with receive events via Cloud Pub/Sub use to get changed message IDs fetch only the messages you actually need run deterministic rules first escalate ambiguous messages to GPT-5 or Claude Start the mailbox watch Minimal Node example for change processing The important part is not the code style.
The important part is the order of operations: cheap mailbox sync first deterministic routing second model call last