Daily Workflows with the Email Agent

Dear Readers,

the infrastructure is in place. Four layers of guardrails are configured. Now let’s talk about actually using this thing day to day.

Morning Triage

#

My first Telegram message most mornings:

@email Summarize my inbox since yesterday morning

The agent returns something like:

Needs reply today:

• Sarah Chen — re: Q2 budget review. Asking for your sign-off on the revised numbers.
• Marco (DevOps) — Staging deploy failed. Wants to know if you can look at the logs today.

Informational:

• GitHub — 3 notifications: PR review requested, issue assigned, release tagged.
• Jira — Sprint board updated, 2 tickets moved to review.

Newsletters / Automated:

• Hetzner — Monthly invoice available.
• TLDR Sec — Weekly security newsletter.

Two seconds of reading and I know what needs attention. The PII handling rules from the SOUL.md mean I don’t get phone numbers or addresses dumped into Telegram — just names, subjects, and summaries.

Reading Full Threads

#

When a summary isn’t enough:

@email Show me the full thread with Sarah about the Q2 budget

The agent pulls the complete thread with gmail_get_thread, presents it chronologically, and preserves the reply structure. For long threads, it’ll include a brief summary at the top before showing the individual messages.

This is where Sonnet earns its keep over Haiku. Understanding a 15-message email thread with different participants, quoted replies, and inline comments requires real comprehension.

Drafting Replies

#

Here’s where the confirmation flow matters:

@email Draft a reply to Sarah. Approve the numbers but ask
if we can revisit the contractor line item next quarter.

The agent responds with:

Here’s the draft:

---

Hi Sarah,

Thanks for putting this together. The revised numbers look good — happy to sign off.

One thing: could we revisit the contractor line item next quarter? I think there’s room to optimize there once the current project wraps up.

Best, Patrik

#

Should I create this draft?

I review, maybe tweak the wording:

Looks good, but change "room to optimize" to "room to adjust the allocation"

The agent updates the draft, shows it again, and I confirm. Only then does it call gmail_create_draft. The draft appears in Gmail, ready for me to hit send manually.

The send is always manual. That’s by design.

Search with Gmail Operators

#

The agent passes search queries to Gmail’s native search, which means you get the full operator syntax:

@email Find emails from:sarah subject:budget after:2026/01/01

@email Search for has:attachment filename:pdf from:accounting

@email Find all unread emails in my inbox older than a week

Gmail’s search operators are powerful, and the agent translates natural language to operators when needed:

@email Find that email from last month about the API migration

This turns into something like from:* subject:API migration after:2026/01/20 before:2026/02/25 under the hood.

Cross-Agent Workflows

#

The email agent and the PA agent don’t share a workspace, but they can work together through you:

@email Summarize the thread with the DevOps team about the staging issue

Read the summary, then:

@pa Save a note in Work/Infrastructure: staging deploy issue from Feb 25,
Marco reported failed deploy, linked to the Node.js upgrade from last week.
Need to check logs.

The email agent reads, you synthesize, the PA agent files. It’s not automated cross-agent communication — and that’s intentional. You’re the router, and you decide what moves between contexts.

Honest Limitations

#

Things the email agent doesn’t handle well:

• Attachments. It can see that attachments exist and their filenames, but it can’t read PDFs, spreadsheets, or images. You’ll get “this email has an attachment: Q2-report.xlsx” and nothing more.
• Rich formatting. HTML emails get stripped to plain text. Formatted tables, colored text, and embedded images are lost in translation.
• Very long threads. Past about 30 messages, the agent starts losing context. For deep threads, ask for a summary first and then dive into specific messages.
• Real-time. There’s a delay between emails arriving and the agent seeing them. It’s querying the API on demand, not watching a live stream. Don’t use it as a notification system.
• Non-English. The agent handles English well. Mixed-language threads work okay. Fully non-English threads are hit or miss depending on the language.

These are real constraints, not theoretical ones. I run into the attachment limitation weekly and the formatting issue daily. Knowing what doesn’t work is part of using the tool effectively.

The Human in the Loop

#

After a few weeks of using this setup, here’s what I’ve landed on: the email agent is a reading and drafting tool, not an email manager. It’s excellent at:

• Cutting through inbox noise in the morning
• Pulling up thread context before meetings
• Drafting replies that match the right tone
• Searching for that one email you vaguely remember

It’s not a replacement for reading your own email. Critical messages still need your eyes. Sensitive conversations still need your judgment. The agent handles the volume so you can focus on the messages that actually need you.

The four-layer guardrail model means I don’t worry about the agent doing something catastrophic. The worst case is a draft I don’t approve. And honestly, most of the drafts are good enough that I send them with minor edits.

That’s the whole point — an agent that’s useful enough to use daily and safe enough to trust with your inbox.

This wraps up the Email Agent Playbook series. We went from paranoid OAuth credentials to daily workflows, with three layers of technical guardrails and one human between the agent and the send button. If you followed along from the Installation series, you’ve now got a full self-hosted setup: server, dashboard, Telegram bot, knowledge base, and email agent — all on a single ARM64 box.