How to Give Your Hermes Agent Its Own Email Inbox

Your Hermes agent needs email for the same reasons you do: outbound outreach, catching verification codes, handling inbound replies. The default options don't work. Gmail bans automated accounts. SendGrid is send-only. Building receive-and-reply infrastructure yourself is weeks of work. AgentMail is email built specifically for agents. Create an inbox in one API call. Send and receive immediately. No SMTP config, no OAuth. Because it connects to Hermes via MCP, every subagent Hermes spawns can provision its own isolated inbox for its task, automatically, in under a second.

How this is different from OpenClaw

OpenClaw adds email through a SKILL.md file. The agent reads it at runtime and the LLM interprets it to generate API calls. That works until it doesn't. Wrong parameter, malformed request, misread endpoint. It fails silently. The email doesn't send and you don't know why.

Hermes registers AgentMail as an MCP server. At startup, every tool is registered as a typed function with a defined schema: create_inbox, send_message, reply_to_message, list_threads. The agent calls the function directly. Bad parameter means an immediate explicit error. Wrong API key means you know on startup. Nothing fails silently.

What you need

• Hermes installed on your machine
• An AgentMail API key (free at console.agentmail.to, no card required)
• Node.js 18+

Step 1: Install Hermes

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Works on Mac, Linux, and WSL2. Takes about 3 minutes. When it finishes, the setup wizard runs automatically. Choose Quick setup, pick your model provider, and skip messaging platforms for now.

When done, reload your shell so PATH includes Hermes—or open a new terminal. Use the rc file your shell actually loads (not every install uses zsh):

source ~/.zshrc   # zsh (default on macOS)

source ~/.bashrc  # bash (common on Linux and WSL2)

If you use another shell (e.g. fish), run its equivalent reload or start a fresh session.

Step 2: Install the AgentMail CLI and confirm your key works

npm install -g agentmail-cli

export AGENTMAIL_API_KEY=YOUR_API_KEY

agentmail inboxes create --display-name "Test Agent"

You should get back:

{
  "inbox_id": "boldstory348@agentmail.to",
  "display_name": "Test Agent",
  "created_at": "2026-04-07T00:00:00Z"
}

If you see an inbox ID, your key works and you are ready for the next step.

Step 3: Add AgentMail to Hermes

Open the Hermes config:

nano ~/.hermes/config.yaml

Scroll to the bottom and add:

mcp_servers:
  agentmail:
    command: "npx"
    args: ["-y", "agentmail-mcp"]
    env:
      AGENTMAIL_API_KEY: "YOUR_API_KEY_HERE"

Save with Control + O, Enter, Control + X.

Start Hermes:

hermes

When Hermes loads, look for this line:

43 tools · 76 skills · 1 MCP servers

That 1 MCP servers is AgentMail. All tools are registered and ready. If you update the config while Hermes is running:

/reload-mcp

No restart needed.

Here is the full list of tools Hermes registers from AgentMail:

Step 4: Your agent's first email

In the Hermes chat:

Create an inbox called outreach-agent and send an email
to hello@example.com with subject "First email from Hermes"
and body "Sent via AgentMail MCP."

Hermes calls create_inbox, gets the inbox ID, then calls send_message. Two typed function calls. The email lands.

To check for replies:

Check the outreach-agent inbox for any new messages
and summarize what came in.

Hermes calls list_threads, reads the results, and summarizes. Your agent is now a full email correspondent.

Step 5: Every subagent gets its own inbox

This is where Hermes and AgentMail become more than the sum of their parts.

Hermes delegates tasks to isolated subagents running in parallel. Each subagent gets its own conversation context, its own terminal, and its own access to the full AgentMail MCP toolset. That means each subagent can create its own inbox for its task, use it, and delete it when done. No shared inbox state. No message bleed between agents. If a bad email lands in one subagent's inbox, it is scoped to that task alone.

Tell Hermes:

Spin up three parallel subagents. Each one should:
1. Create its own AgentMail inbox
2. Sign up for [service] using that inbox address
3. Check the inbox for a verification email and extract the code
4. Complete signup with the code
5. Report the account details back
6. Delete its inbox

What happens:

HERMES (parent)
│
├── SUBAGENT-1
│   └── create_inbox → signs up → extracts OTP → reports → delete_inbox
│
├── SUBAGENT-2
│   └── create_inbox → signs up → extracts OTP → reports → delete_inbox
│
└── SUBAGENT-3
    └── create_inbox → signs up → extracts OTP → reports → delete_inbox

Three parallel tasks. Three isolated inboxes. This pattern works for signup automation, parallel outbound threads, QA testing, and any workflow that benefits from isolated email identities at scale.

Scheduled email tasks

Hermes has a built-in natural language cron scheduler. Tell it what you want and it creates the schedule.

Every weekday at 9am, check the support-agent inbox for
unread messages, classify each one by urgency, draft replies
for anything urgent, and send me a summary on Telegram.

The task runs unattended through the Hermes gateway. No cron syntax, no config files.

Suggested Reading

New to agent email? Start here.

Why AI Agents Need Email The case for dedicated agent inboxes and why shared credentials break at scale.

AgentMail + Google ADK Same MCP pattern, different framework. If you are evaluating ADK alongside Hermes, read this next.

AgentMail + Browser Use Browser automation and inbox provisioning in the same session. Signup flows, OTP handling, the full loop.

AgentMail + OpenClaw How the SKILL.md integration works if you are running both frameworks.