#BetterEmail — Gmail digest & triage for OpenClaw

1 messages · Page 1 of 1 (latest)

soft quail
#

For anyone running Gmail agents in OpenClaw who is tired of duplicate alerts, stateless cron runs, and wasted tokens.

My OpenClaw agent flagged the same email from my lawyer 8 times across different cron runs.

Every session was stateless, so none of them knew the email had already been handled.

So I built BetterEmail — an OpenClaw plugin that adds persistent email state and scheduled triage.

Install

openclaw plugins install @better_openclaw/betteremail
  • Visit the github repo link or ask your agent to read through the package repo to set up a useful cron job automatically

Why this exists

Agent sessions are inherently stateless.

If you run Gmail triage on cron jobs or across multiple sessions, there’s no shared memory of what has already been processed.

That leads to:

  • duplicate alerts
  • wasted tokens
  • repeated triage work

What BetterEmail does

BetterEmail polls your Gmail accounts in the background via gog, deduplicates everything, and keeps a persistent digest that tracks what’s been seen, handled, dismissed, or deferred.

The agent triages on a cron schedule in an isolated session and only pings you in main when something actually matters.

No more burning 30k tokens on raw gog calls just to find out there’s nothing new.

Architecture

Gmail → gog → BetterEmail poller
                  ↓
             persistent digest
                  ↓
           scheduled agent triage
                  ↓
      notify main session if needed

What it does

  • Background polling (no agent tokens wasted on fetching)
  • Persistent state across all sessions — dismissed stays dismissed
  • Auto-resolves threads you’ve already replied to
  • Simple tools: get_digest, handle, dismiss, defer
  • Agent runs triage in an isolated cron session and announces to main

How is this different from OpenClaw’s built-in Gmail Pub/Sub?

The built-in Gmail Pub/Sub fires a webhook on every incoming email.

That means a new agent session spins up for each one — newsletters, spam, DMARC reports, everything.

Each session has no memory of what previous sessions already handled, so you get duplicate alerts and wasted tokens.

It also needs extra infrastructure:

  • GCP project with a Pub/Sub topic
  • Tailscale funnel for the webhook endpoint
  • gog watch running as a daemon
  • OpenClaw webhook config wired together

BetterEmail’s approach

BetterEmail takes a different approach.

It polls in the background (no GCP, no Tailscale, no webhooks), deduplicates at the plugin level, and keeps persistent state across sessions.

Instead of reacting to every email individually, it collects them into a digest and lets the agent triage in batch on a schedule.

Dismissed stays dismissed.

Handled stays handled — even across cron jobs and context resets.

📊 TL;DR — Architecture difference

Gmail Pub/Sub

  • Event-driven (one agent session per email)
  • Stateless
  • Requires GCP + webhook infrastructure
  • Token cost scales per email

BetterEmail

  • Scheduled batch digest
  • Persistent state across sessions
  • No extra infrastructure
  • Token cost per triage run

BetterEmail turns email handling from stateless event spam into stateful scheduled triage.

Links

GitHub
https://github.com/maximilianspitzer/openclaw-betteremail

npm
https://www.npmjs.com/package/@better_openclaw/betteremail

Latest release info
#1479636402214797423 message

Maintainer

Maximilian Spitzer (@maximilianspitzer)

Feedback

If you’re running agents on email workflows, I’d love feedback on edge cases, better triage patterns, or additional agent tools.

Would love to get this on the community plugins page if it meets the bar.

violet kelp
#

Is there a reason you dont just........ mark the email as read?

soft quail
# violet kelp Is there a reason you dont just........ mark the email as read?

yes. more often than not, esp in work contexts you might read an email (which marks it as read), and dont reply yet- maybe because you're out and about, about to head to a meeting etc. this completely eliminates that annoyance, and also allows the agent to contextually defer notifying me when timing isnt ideal, such as me being in a meeting etc.

violet kelp
#

feels like extreme overcomplication and reinventing half of how email works but sure

soft quail
#

i mean by all means suggest a simpler approach, constructive criticism is always welcome :D

violet kelp
#

this is what works perfectly for me

#

if an email is unread, it needs to be handled, and if its read, then its already done

soft quail
#

i think we just have different use-cases: one of my main use-cases for openclaw is email notification/drafting and this plugin fixes the gripes i had with it.

but your solution is probably enough for most other people :)

smoky folio
#

this was exactly what I needed, I already had my own wacky mail matching and handling engine, but I couldn't be bothered to implement a proper state management system, and for me, as in your case, the 'read' status is not at all suitable as a handled flag, as I casually read through my mail in ways not at all synchronous with what my agent is doing

halcyon marsh
# violet kelp Is there a reason you dont just........ mark the email as read?

With AI agents, there now is a gap between the simple "read" flag and what is actually happening. Where before, a person acted on an email, and any "new mail" notifications could just react to new mails added to the top of the list, we now have an agent acting on the mail in addition to the user---unless we give the agent its own personal account.

This means, we now need to track "user has read the message" and "agent has read the message" seperately.

This plugin certainly is one way to do it, but maybe somethig more general is needed. Ideally there would be universal support for tags across all email provider and protocols, but alas, that's a pipedream.

split root
soft quail
soft quail
soft quail
#

v2.0.5

Improved the agent setup prompt in the README. It now explicitly explains when to use each triage action:

  • dismiss — spam, marketing, automated noise (permanent)
  • defer — not urgent, but needs action later (snoozes and resurfaces)
  • mark handled — already resolved or purely informational
  • leave in digest — unsure or important — let the user decide

Should lead to better out-of-the-box triage behavior without needing to tweak the prompt yourself.

Update your openclaw installation using:

openclaw plugins update @better_openclaw/betteremail

Release here:
https://github.com/maximilianspitzer/openclaw-betteremail/releases/tag/v2.0.5

soft quail
#

Please let me know any issues you encounter. would really like to improve this as much as possible :)