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:
    config:
      address: "support@northwind.dev"
      username: "support@northwind.dev"
      password: "${SUPPORT_EMAIL_PASSWORD}"
      imap_host: "imap.fastmail.com"
      smtp_host: "smtp.fastmail.com"
---
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>

##secret set SUPPORT_EMAIL_PASSWORD …   # app password; stored where git ignores it
##humanoid spawn ./support-bot.md
##humanoid channel start support-bot email
##humanoid channels support-bot
# email [connected]

The adapter speaks standard IMAP (over TLS) and SMTP, nothing provider-specific — 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. (If a server doesn't support IDLE, the adapter falls back to checking every 30 seconds.)

Replies go out over SMTP — Re: the original subject, In-Reply-To the message they answer — so they land in the customer's thread.

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 — which ships today for email and website chat — fits this channel so naturally. For email, it's one line in the contact block:

  email:
    governance: human

Now an inbound email doesn't produce an outbound email. It shows up in your terminal pane — the customer's message, marked [human-governed] awaiting your instruction, sitting next to the shell you're already working in. Ask the agent for a draft and read it. If it's right, type send — that draft goes out. 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 — keep the file in git and the fix is a 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). Or don't flip it. For email, human forever is a perfectly rational policy.

Ops, from any terminal on the box

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                                       # pause answers until activate

Going on holiday? Stop the channel; mail keeps landing in the mailbox like it always has, and when you start the channel again the agent picks up only mail that arrives after that.

Honest scope

• Live proof: website chat (nightly CI round-trip). Slack demonstrated once; email (IMAP IDLE + SMTP) ships unproven. Ten more ship but aren't proven live 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.
• Open-core — CLI Apache-2.0, server proprietary. Your mailbox credentials stay on your machine — in rysh's secret store or your environment.
• 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