Integrations — หนึ่ง Gateway เชื่อมทุกช่องทางIntegrations — One Gateway, Every Channel

After I finished the seven-part OpenClaw for Organizations series, the question readers sent back most often was not about models or memory. It was the plainest question and the hardest one: how do I put the agent where my organization actually talks? An agent that can only be reached from its installer's terminal is one engineer's toy, not an organizational tool.

I answered that question for OpenClaw in OpenClaw Integrations. This year I am examining Nous Research's Hermes Agent seriously, and post #5 of this series has to answer the same question on the Hermes side: how it connects to the outside world, where it differs from what we know, and which parts deserve caution before you switch them on.

The short version, which the rest of this post unpacks: everything flows through a single gateway process; the README headlines five platforms plus the CLI while the real documented surface is 27+ platforms; the tool side bets on MCP in both directions; browser automation now treats Browser Use as the default driver; and the Nous Portal bundles a stack of tools behind one OAuth.

The gateway — one daemon for messaging, cron, and voice

Hermes's integration architecture starts from a single idea: the gateway is one background process that holds every channel's connection at once. And per the official messaging docs it does more than messaging — the same daemon runs the cron scheduler (ticking every 60 seconds) and handles voice delivery. Put bluntly: if the gateway dies, every channel goes silent together; if it is up, everything is up. That is an operational strength and a single point of failure in the same breath.

Before there is a gateway there has to be a Hermes — and installation is a one-liner on Linux, macOS, WSL2, or even Termux on an Android phone:

# Install Hermes Agent (Linux / macOS / WSL2 / Termux)
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# On Windows
iex (irm https://hermes-agent.nousresearch.com/install.ps1)

# Gateway lifecycle — from the official messaging docs
hermes gateway setup      # wizard: pick channels, paste tokens
hermes gateway install    # install as a background service
hermes gateway start      # or start it by hand
hermes gateway status     # check every adapter
hermes gateway stop

Readers coming from the OpenClaw series will find this familiar — OpenClaw also funnels every channel through one gateway process. Hermes did not invent the pattern; it inherited and refined it. And for organizations already running OpenClaw, the docs note that the migration command hermes claw migrate carries your existing messaging tokens across, so you are not re-registering a bot on every platform.

Once the gateway is running, most day-to-day control happens inside the chat itself, with the same command set on every platform:

/model             # live model switching mid-conversation — every platform, since v0.8.0
/voice             # voice mode
/bg                # push long work to the background
/platform pause    # pause a single platform's intake
/platform resume
/reload-mcp        # reload MCP servers without restarting the gateway
/new /reset /sessions /personality /update

💡 My favorite operational detail: cron and messaging live in the same process, so a scheduled job — a morning news digest, a weekly report — delivers its output straight back into a chat channel with zero glue code.

From five to twenty-seven-plus — the real platform surface

The Hermes README leads with a memorable sentence: Telegram, Discord, Slack, WhatsApp, Signal, and CLI — "all from a single gateway process." That is five messaging platforms plus one terminal. Open the docs' integrations index, though, and the number is a different story: more than 27 supported platforms, with the messaging guide enumerating roughly 28 adapters, from open protocols to the complete Chinese chat ecosystem.

Two rows deserve a second read. First, WhatsApp appears twice: an unofficial route through the Baileys bridge, whose docs warn about account-ban risk in plain words, and the official route through Meta's Cloud API, which needs a Business account. Second, iMessage is bridge-only — if you were hoping to plug an agent into iMessage directly with no Mac-shaped machinery in between, the documentation makes no such promise.

I read the "five vs. 27+" gap less as marketing and more as a lesson in document literacy: the README showcases the most stable channels, while the integrations index is the actual, much wider surface. When evaluating a tool, trust the docs page over the repo's front door.

Per-channel control — allowlists, pairing, and channel_overrides

With a surface this wide, the first IT question has to be "who gets to talk to it?" Hermes answers in layers. Layer one is a per-platform allowlist through the *_ALLOWED_USERS family of environment variables — anyone off the list is denied by default:

# ~/.hermes/.env — who may talk, per platform
TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=haruki#1234
[email protected]

# The open-to-everyone switch exists — think hard before using it
# GATEWAY_ALLOW_ALL_USERS=true

Layer two, for when you do not want to collect user IDs up front: DM pairing. A new user messages the bot, receives a code, and an administrator approves it from the CLI:

hermes pairing approve telegram 483920   # approve the code the user received
hermes pairing list                      # who is already paired
hermes pairing revoke telegram <id>      # revoke later at will

If you followed the OpenClaw news cycle this year, you know the big early wound was gateways left open on the internet with no fence at all. Hermes launched after those incidents and was deliberately designed against them — every channel is default-deny from the start, and a new user's only way in is a pairing code that a human approves from the CLI.

Layer three is something I have not had this cheaply from comparable tools: channel_overrides in ~/.hermes/gateway-config.yaml, which assigns a different model and system prompt per channel ID. The DevOps room gets the expensive model and a strict prompt; the general Q&A room gets the economical one. The rough shape looks like this (the full schema is in the messaging docs):

# ~/.hermes/gateway-config.yaml — a personality and model per room
channel_overrides:
  "telegram:-1001234567890":     # the DevOps team room
    model: a specific model for this room only
    system_prompt: a strict prompt for infra work
  "discord:555555555":           # the general Q&A room
    model: an economical pick for everyday questions

My reading: these three layers are the concrete face of the default-deny posture I analyzed in post #4, Hermes Security. Many channels are not the scary part — unfenced channels are, and Hermes ships the fences as defaults.

Concrete setups — Telegram, WhatsApp, Email, WeCom

Enough theory. Here are four real channel hookups that, between them, cover most organizations I meet — the first is the gentlest, the later ones carry conditions you want to know before pressing enter.

Telegram — the lowest-pain starting point

Create a bot with BotFather to obtain a token, then run hermes gateway setup, choose Telegram, and paste the token into the wizard. Set TELEGRAM_ALLOWED_USERS in .env before starting the gateway, and the agent is live in Telegram. The feature depth here is solid: since v0.8.0, Telegram and Slack render approval buttons, so users confirm risky actions with a tap instead of typing.

The most popular community recipe is exactly this pair on a cheap VPS. The heyuan110.com guide (April 2026, v0.9.0-era — a third-party source) walks the whole path: install with the official script or run the nousresearch/hermes-agent:latest Docker image with ~/.hermes mounted as a volume (config, sessions, and tokens all live in that folder), on a $4-5/month VPS from Hetzner, DigitalOcean, or Vultr, with OpenRouter recommended as the entry provider for anyone who holds no API keys yet.

WhatsApp — two routes, two very different risk levels

The first route is the built-in wizard: run hermes whatsapp and scan the QR code from your phone (Settings → Linked Devices). This path rides the unofficial Baileys-style bridge.

# ~/.hermes/.env — WhatsApp via the Baileys route
WHATSAPP_ENABLED=true
WHATSAPP_MODE=bot              # or self-chat
WHATSAPP_ALLOWED_USERS=66812345678   # number with country code, no plus sign

# the session lives at ~/.hermes/platforms/whatsapp/session

Email — old-fashioned, effective, and demanding of discipline

The email channel has no magic in it — plain IMAP/SMTP through env vars. It polls the UNSEEN mailbox every 15 seconds by default and threads its replies properly with In-Reply-To/References headers:

# ~/.hermes/.env — email over plain IMAP/SMTP
[email protected]
EMAIL_PASSWORD=app-password-here     # always an app password
EMAIL_IMAP_HOST=imap.company.co.th   # port 993
EMAIL_SMTP_HOST=smtp.company.co.th   # port 587
EMAIL_POLL_INTERVAL=15               # seconds — the default
[email protected]
[email protected]  # where automated jobs deliver

WeCom — a worked example from Enterprise WeChat

For organizations working with Chinese partners, Tencent Cloud's techpedia guide (April 2026) documents the WeCom side clearly:

# Per Tencent Cloud's techpedia guide (April 2026)
# 1) create a bot in Enterprise WeChat; note the Bot ID and Secret
# 2) put both values into ~/.hermes/.env
# 3) install the gateway as a service
hermes gateway install

The same guide notes that other platforms configure through the hermes setup wizard, and Tencent went as far as launching a one-click Hermes template on Lighthouse in mid-April 2026 — a signal of how quickly the Chinese market adopted this tool.

MCP both ways — OAuth 2.1 and hermes mcp serve

Chat channels are the inbound side. For the outbound side — external tools — Hermes bets fully on MCP (Model Context Protocol). Servers register under mcp_servers in ~/.hermes/config.yaml, over stdio or HTTP/SSE transports, and the part that outclasses what I had in the OpenClaw era is end-to-end OAuth 2.1: set auth: oauth and the system handles PKCE and Dynamic Client Registration automatically (this landed in v0.8.0 on April 8, 2026):

# ~/.hermes/config.yaml — rough shape (full schema in the MCP docs)
mcp_servers:
  internal-kb:
    transport: stdio           # run as a local subprocess
  issue-tracker:
    transport: sse             # connect over HTTP/SSE
    auth: oauth                # OAuth 2.1 — PKCE + Dynamic Client Registration, automatic
    include:
      - "issue_*"              # keep only the tools you want, by glob
    exclude:
      - "*_delete"             # cut whole classes of dangerous tools

Details from the MCP docs that I noted down specifically:

• Tool names register as mcp_<server>_<tool> — every tool is auditable back to its server
• MCP sampling is on by default at 10 requests/minute, and elicitation carries a 300-second timeout
• Injection defense: Unicode tag characters U+E0000–U+E007F are stripped from tool results — the invisible-instruction trick that has been exploited in the wild this year
• OSV malware scanning checks MCP packages before install (since v0.8.0), and mutual-TLS setups get client_cert/client_key

Management gets a complete CLI, and the last line below is the one that flips this whole post's direction:

hermes mcp                    # interactive catalog picker
hermes mcp install <name>     # install from the catalog (the optional-mcps/ folder)
hermes mcp login <name>       # per-server OAuth login
/reload-mcp                   # hot-reload mid-session, no gateway restart

hermes mcp serve              # reverse the flow: expose Hermes AS an MCP server

💡 hermes mcp serve turns Hermes itself into an MCP server with 10 tools (stdio only) for Claude Code, Cursor, or Codex to connect to — meaning the agent inside your code editor can drive Hermes. That direction is why I titled this section "MCP both ways."

The curated side is growing fast too: release v0.20.6 (August 27, 2026) catalogued more than 50 vendor MCP servers, and v0.21.0 (August 31, 2026) added a desktop MCP command center — a merged servers-and-catalog page with background health checks, a 30-day cost overlay, and hermes:// deep links that always confirm before acting.

Browser automation — Browser Use as the default driver

This one deserves an accurate timeline. The first turning point was v0.8.0 (April 8, 2026), whose release notes say it outright: "Switch managed browser provider from Browserbase to Browser Use" (PR #5750, a community contribution), with Firecrawl added as another cloud browser in the same release. By September 2026 the browser docs go further: Browser Use is the default driver — when browser.backend is unset and the browser-use CLI is runnable, the agent gets a single tool named browser_exec that covers everything (the docs reference Browser Use CLI 3.0; which release flipped the default is not pinned in the docs, so I will not claim one).

# ~/.hermes/config.yaml
browser:
  backend: "browser-use"       # explicit, or leave unset for auto-detect
  # use_real_profile: true     # v0.20.6+ — consent-gated snapshot of your real profile

# ~/.hermes/.env
BROWSER_USE_API_KEY=bu_xxx     # for Browser Use Cloud

The flexibility comes from one driver composing with many backends:

/browser connect     # attach to local Chromium over CDP, from inside the chat
# caveat: Chrome 136+ requires a dedicated user-data-dir
# never point it at your main logged-in profile

Two late additions close the timeline: v0.20.6 brought real-profile browsing — a snapshot of your actual browser profile, cookies and logged-in sessions included, behind an explicit consent gate — and v0.21.0 let the agent drive the desktop app's in-app browser directly. To me, real-profile is both the most powerful and the most dangerous feature in this post: cookies are the keys to every house you own. Enable it only once you understand its price.

Voice, calendars, and the Nous Portal Tool Gateway

Voice was the headliner of v0.20.0, "The Herald Release" (August 3, 2026): clause-by-clause streaming TTS while the answer is still generating, barge-in — interrupt it by simply speaking — and on-device wake words ("hey Hermes") that do not stream your room's audio to a cloud. The provider roster is broad:

For calendars and productivity email, the centerpiece is the first-party Google Workspace skill — Gmail, Calendar, Drive, Contacts, Sheets, Docs over OAuth2 with automatic token refresh. The interesting part is that setup is agent-driven: Hermes walks you through creating the Google Cloud project, enabling APIs, and creating credentials, step by step, inside the conversation (under the hood the skill prefers the gws CLI when available and falls back to Google's Python client libraries). Outside the Google universe there are community CalDAV plugins (Yandex, Nextcloud) in the community-run awesome-hermes-agent directory — community-built, not Nous's.

Then comes the piece designed to put everything in one box: the Nous Portal Tool Gateway. One OAuth grants a model plus a tool bundle: web search and extraction (a Firecrawl partnership), image generation through FAL with 9 models (including FLUX 2 Klein, FLUX 2 Pro, and Z-Image Turbo), OpenAI TTS, Browser Use's cloud browser, and an optional Modal cloud terminal. Auth is a refresh token at ~/.hermes/auth.json that mints short-lived JWTs:

hermes setup --portal    # one OAuth: model + tools together
hermes model             # or pick provider/model from the menu
hermes tools             # toggle tools individually

One more development worth knowing: MiniMax. Around early April 2026, Nous posted on X that it is "partnering across product and models" with MiniMax, inviting users to try MiniMax M2.7 through the Nous Portal (no commercial terms were disclosed, so I can only relay what the post says). The tangible artifacts: MiniMax's own official platform docs carry a dedicated Hermes Agent page wiring its subscription-style Token Plan into Hermes with a Subscription Key — explicitly distinct from pay-as-you-go API keys — and "MiniMax M3 free" showed up in the v0.21.0 model catalogs:

npx -y mmx-cli@latest agent setup
# or: hermes model → choose "MiniMax (global endpoint)" and paste the Subscription Key

Beyond chat — A2A, webhooks, ACP editors, and the API

The last layer of this surface is not human at all — it is other systems and other agents. v0.20.0 shipped A2A v1.0, a wire protocol for agent-to-agent conversation, alongside outbound signed webhooks; v0.21.0 added hermes peer for direct bot-to-bot DMs between two instances, and multi-agent group rooms come via Bot Mode, bundled into the desktop app by v0.21.0 with per-bot @-mentions. All of this continues the multi-agent story from post #2 of this series.

For developers there are two attachment points. The first is ACP (Agent Client Protocol), which brings Hermes inside VS Code, Zed, and JetBrains — chat, tool activity, file diffs, and terminal commands rendered in the editor itself. The second is an OpenAI-compatible HTTP API server for programmatic access: anything that already speaks that API shape can point its endpoint at Hermes with barely a code change.

One small detail that genuinely lowers switching costs: Hermes reads other ecosystems' context files natively — CLAUDE.md, AGENTS.md, and .cursorrules, on a first-match priority chain. A team that already invested in context files for OpenClaw or Claude Code keeps using them from day one.

Even the small parts are pluggable: web search offers 8 backends (Firecrawl by default, with SearXNG, Brave, DuckDuckGo, Exa, Parallel, and xAI among them), and memory providers swap the same way, 8 of them — a topic I covered in depth in post #3, Hermes Memory.

I will close with two names that say a lot about where this project is heading: Home Assistant is simultaneously a chat surface and a door into home automation, and Buzz — a Nostr-based collaboration workspace — is treated as a first-class gateway platform on par with Slack, not a sideboard experiment. This team already defines "channel" more broadly than "chat app."

A closing tip for the automation-minded: the Hermes docs publish machine-readable indexes at /docs/llms.txt (a compact ~17 KB) and /docs/llms-full.txt (the full ~1.8 MB) — when you want your own AI assistant answering Hermes questions from the real documentation instead of guessing, point it at those two files.