Email humanoids: IMAP IDLE, SMTP, and an agent that answers the inbox

Email is the channel nobody demos and everyone drowns in. Wiring an AI agent to a real mailbox — with a human holding the send button.

Every AI agent demo is a chat widget. Snappy messages, typing indicators, applause. Meanwhile, the actual queue your support team drowns in — the one with the invoices, the cancellation requests, the "it's been three days" follow-ups — is an inbox. Email is the channel nobody demos and everyone lives in.

I think that's precisely why it's the best first channel for an AI agent. Let me make that case, and show the wiring in rysh.

The wiring: a mailbox in the frontmatter

A rysh humanoid is an agent defined in one markdown skill file; channels are contact blocks in the frontmatter. Email is one block — the mailbox credentials come from environment variables, never the file:

---
name: support-bot
description: Answers support@ for Northwind Devtools
contacts:
  email:
    enabled: true
    address: "support@northwind.dev"
    password: "${SUPPORT_EMAIL_PASSWORD}"
    imap_host: "imap.fastmail.com:993"
    smtp_host: "smtp.fastmail.com:587"
---
You are support-bot, the support engineer for Northwind Devtools.

Answer only from the product facts below. If the answer isn't here,
say you don't know and offer to escalate to a human. Sign as
"support-bot (AI) — Northwind Devtools".

- Current release: nwcli v2.4.1. Install: brew install northwind/tap/nwcli
- Refunds within 30 days of purchase: yes, no questions. After: escalate.
- Roll back with: nwcli rollback <release-id>

export SUPPORT_EMAIL_PASSWORD="…"   # app password / from your secret manager
##humanoid spawn support-bot.md
##humanoid channel start support-bot email
##humanoid channels support-bot
# email [connected]

Any mailbox that speaks IMAP and SMTP works — Fastmail, Gmail with an app password, your own Postfix. No forwarding rules into a vendor's cloud, no "connect your Google account" OAuth ceremony handing a third party your mail. The agent logs into your mailbox from your machine.

IMAP IDLE: push, not polling

The adapter holds an IMAP IDLE connection — the mail-protocol equivalent of a WebSocket. Instead of polling every N minutes (the cron-job approach that turns "instant AI support" into "answers on the quarter hour"), the server pushes the moment a message lands, and the agent starts on it immediately.

Replies go out over plain SMTP, threaded into the conversation they belong to. Which matters more than it sounds: email has threads, and the humanoid keeps a separate conversation context per thread — a rolling 20-turn history with a 24-hour TTL. The refund chain and the API-key question are different contexts even when they're the same customer. No cross-thread bleed, no unbounded memory quietly accumulating customer history.

The killer feature: email is asynchronous

Here's the argument for email-first. Chat sets an expectation of seconds, which pressures you into full autonomy before the agent has earned it. Email's contract is minutes-to-hours — which means a human review step costs you nothing perceptible.

That's why draft-and-confirm governance — live today for email and website chat — fits this channel so naturally:

##humanoid governance support-bot human

Now an inbound email doesn't produce an outbound email. It produces a draft in your terminal pane: the customer's message, the agent's proposed reply, sitting next to the shell you're already working in. Read it. If it's right, confirm — one reply goes out, threaded, signed. If it's wrong, you've just learned exactly which fact is missing from the skill file. Edit the markdown, respawn, and every future draft improves — the fix is a git diff, not a vibe.

The customer experiences a fast, accurate reply. Your team experiences reviewing drafts instead of writing them, which is the actual productivity story with none of the "the bot told a customer what?" risk. And when a channel's drafts have needed zero edits for long enough, flipping it to autonomous is one command (##humanoid governance support-bot ai) — every exchange still logged. Or don't flip it. For email, human forever is a perfectly rational policy.

Ops, from anywhere

Because the humanoid lives in a rysh session on your hardware — a Mac mini in the office corner is genuinely enough — inbox operations are session operations:

rysh send home "##humanoid channels support-bot" --mode shell  # check status, headless
rysh attach home                                               # pick up the live session
##humanoid channel stop support-bot email                      # pause the mailbox
@@support-bot deactivate                                       # hard stop

Going on holiday? Stop the channel; mail queues in the mailbox like it always has — email's store-and-forward nature is your friend. Nothing about this setup is load-bearing on a vendor's uptime.

Honest scope

• Live channels today: Slack, email (IMAP IDLE + SMTP), and website chat. WhatsApp and phone are roadmap — not live, don't plan on them yet.
• Deliverability is your mailbox's story: SPF/DKIM on your domain apply to the agent's mail like anyone else's. rysh doesn't magic that.
• rysh runs on Claude, with your own Anthropic key; provider layer pluggable, no model-superiority claims.
• Self-hostable, not open source. Your mailbox credentials stay in your environment on your machine.
• Private beta.

The inbox is where the unglamorous, valuable work already is. Put the agent there first — with a human holding the send button until it's earned otherwise.

If your support@ is a queue you'd love to review instead of write, we're onboarding design partners — early partners are shaping exactly these workflows.

More in this series: governance ai|human: the draft-and-confirm switch · Per-thread memory