Zero Inbox Without Reading Email: My AI Mail and Calendar Agent
Email is the oldest dashboard there is. It sits open all day, and the only way to find what matters is to scan everything that does not. In my stock bot post I argued that the next step for analytics is alerts and agents instead of dashboards. This is the same idea applied to the most boring system I own: my inbox and calendar.
Since September 2026 an AI agent has been doing my email triage. I have not sorted a newsletter since.
TL;DR: key takeaways
- Zero inbox by rule, not by discipline. Only threads that need a reply or a payment from me stay in the inbox. Everything else is labelled and archived.
- Two digests a day. Around 05:00 and at 19:00 I get one short message: what needs me, what was filed, and the next two weeks of calendar.
- Draft before send. The agent writes replies as editable drafts. I review, edit and press Send. It never sends, deletes or drafts on its own initiative.
- Measurable volume. Across eight sampled runs it filed about 17 mails per run and left 3 to 5 action threads.
- Estimated time saved: roughly 1.3 to 1.9 hours a week on triage and calendar review alone. The assumptions are below.
- No code. Scheduled Grok Bot routines plus Gmail and Google Calendar connectors. The logic is a rule set in plain language.
The architecture in one picture
- Inputs. My Gmail inbox, which the agent may read, label and archive, my Google calendars, and whatever I ask for in chat.
- Scheduled routines. Two Grok Bot routines: a morning digest around 05:00 and an evening digest at 19:00, Stockholm time. Both follow exactly the same rules; the evening run covers what arrived since the morning. No server, no cron job of my own.
- Triage rules. A short rule set decides where every mail goes.
- Outputs. A zero inbox, an up-to-date calendar and a digest in chat.
- A human in the loop. Anything that leaves my account, a reply above all, waits for me.
The triage rules
The rules are deliberately boring:
- Action/Reply and Action/Payment stay in the inbox. Those are the only reasons for a mail to take my attention.
- Newsletters and Updates are labelled and archived. Receipts, renewals and service notices are still searchable, and the important ones get one line in the digest.
- Everything else is labelled Processed and archived.
- Recurring invitations from organisations I’m part of are added to the right shared calendar if they are missing, without inviting anyone.
- A known noisy sender is discarded. It is the only exception to the no-delete rule, and it is written into the rules.
Everything else is forbidden by default: the agent never sends, never deletes, never trashes and never creates a draft unless I ask. That list of what the agent may not do was the first thing I wrote, before anything about what it should do.
What a digest looks like
A typical morning digest has four short parts, in Swedish:
- Needs you. Usually three to five threads, each with one line on what the other person wants and what my next step is.
- Tidied. How many mails were filed and of what kind, with one line for anything worth knowing: a domain renewed, an invoice that will be charged automatically, a case number from a supplier.
- Calendar, two weeks ahead. Appointments, recurring events and reminders.
- Follow-ups. Open loops, such as a meeting that is agreed but not yet booked.
When nothing has changed, the digest says so in two lines. That is the point. A quiet day should cost me ten seconds.
Draft before send
The most useful part is not the filing. It is what happens when a thread needs me. I tell the agent in a sentence what I want to say, for example “reply factually with dates, who waited for whom and the next step”. It reads the whole thread, builds the timeline and writes a draft. The draft shows up as an editable card in chat, or as a Gmail draft if I prefer to send from there. I adjust it, often in two or three short rounds, and press Send myself.
That boundary is the governance model. The agent does the reading and the first draft. I own what goes out. It is the same principle as in the stock bot: models do the work that is cheap to check, humans keep the decisions that are expensive to get wrong.
How much time does it save?
I want to be careful here, because measuring whether AI actually improved anything is exactly where most claims fall apart. So here is what is measured and what is assumed.
Measured, from the digests themselves: across eight sampled runs the agent filed 38, 35, 27, 19, 8, 4, 3 and 3 mails, about 17 per run, and left 3 to 5 threads that needed me. The very first clean-up run filed 64 and is left out.
Estimated, with stated assumptions:
| Item | Assumption | Per day |
|---|---|---|
| Mail filed | ~17 per run × 2 runs | ~34 mails |
| Manual triage avoided | 10 to 20 seconds per mail to open, judge, label and archive | ~6 to 11 min |
| Calendar review | ~5 minutes to check two weeks ahead and add invitations | ~5 min |
| Total | ~11 to 16 min/day, about 1.3 to 1.9 h/week |
That excludes reply drafting, which varies too much to put a number on, and the harder-to-price gain: I no longer open the inbox “just to check”. The real value is fewer context switches, not the minutes.
Why this belongs in the alerts-instead-of-dashboards story
An inbox and a dashboard fail in the same way. Both wait for a person to look, and both make that person find the signal in the noise. The agent turns that around:
| Inbox by hand | Inbox with an agent |
|---|---|
| Scan everything to find what matters | Only threads where I am the next step remain |
| Open the inbox whenever there is a gap | Two fixed digests a day |
| Remember to check the calendar | Two-week look-ahead in every digest |
| Write every reply from scratch | Review and send a draft that has read the thread |
| Rules in my head | Rules written down, auditable and changeable |
The same pattern fits shared mailboxes, support queues and procurement inboxes in any company. Rules decide where things go, the agent explains what needs attention and drafts the next step, and an accountable person approves. It is a small version of what I wrote about proof of effect: you can count the mails filed and the threads left, so you can show the effect instead of claiming it. And it raises the same question as whether we should still think in KPIs and functions: the job moves from processing information to deciding on it.
What I would tell someone building their own
- Write the forbidden list first. Send, delete and draft-on-its-own should be off until you have a reason to turn them on.
- Use labels, not folders of opinion. A handful of labels with clear meanings beats a clever taxonomy.
- Fixed times beat notifications. Two digests a day is enough for almost everything.
- Make quiet days cheap. If nothing happened, the digest should say so in two lines.
- Keep the human on Send. The agent reads and drafts; you decide what goes out.
- Count something. Mails filed per run and threads left are free metrics, and they make the effect visible.