Agent stack build plans · № 2 · Hermes community manager

Set it up

Install, pick a model, connect three platforms, then spend the second half of the evening on the locks — that’s the right ratio.

1 · Install and pick a model

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

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

Run hermes once in the terminal and connect a model provider — Nous Portal, OpenRouter, OpenAI, or your own endpoint; Hermes is model-agnostic. For an always-on community bot, pick a mid-tier model now: every handled message is an inference call, and you can raise quality later once you’ve seen the volume. Config lives in ~/.hermes/config.yaml, secrets in ~/.hermes/.env (precedence: CLI args > config.yaml > .env > defaults).

2 · Connect the three platforms

Each platform needs its own credentials — a Discord bot token, a Slack app, a WhatsApp link. The exact variable names and app-scopes are in the messaging docs per platform (they change; we won’t transcribe them here and be wrong by August). Tokens go in ~/.hermes/.env, platform settings under the platform’s section of config.yaml. Then start the gateway:

hermes gateway

Once it works in the foreground, install it as a background service — the gateway supports systemd (Linux) and launchd (macOS) installation, so it survives reboots. Add platforms one at a time: Discord first (best tooling for verification), then Slack, then WhatsApp.

3 · Lock the door before you invite it anywhere

Gateway access is binary — a sender is either allowed to command the agent or ignored. The check order is: per-platform allow-all → DM-pairing approved list → platform allowlists → global allowlist → global allow-all → deny. Two rules for a community bot:

• Never enable allow-all on a platform where strangers can message the bot. On a public Discord, allow-all means every member — and every future member — can command it. It sits first in the check order, so it short-circuits every list you configure below it.
• Use DM pairing for humans, allowlists for known IDs. An unknown user who DMs the bot gets a one-time code; they read it to you, you approve it:

hermes pairing approve discord <code>

So: you and your mods pair and can command the bot everywhere; everyone else is community, not operator. There are no role tiers within one instance — if you want mods to get a more powerful bot than you’d trust the public with, that’s a second profile (hermes profile create mods, run with hermes --profile mods) with its own config, allowlist, and toolsets; hermes gateway list shows per-profile gateways. Most communities don’t need it on day one.

4 · Set the approval gates

Two settings in config.yaml carry the safety load:

• skills.write_approval — gates the agent editing its own skills via skill_manage. Keep it on. The prompts page has the agent writing three skills; you want to see each diff, because skill files persist and run scripts.
• approvals.mode — smart (LLM risk-assessment), manual, or off. Run manual for the first week while you learn what the bot actually tries to do, then decide. approvals.deny takes fnmatch globs for commands you never want run, whoever asks.

5 · The scheduler

Cron is built in — jobs live in ~/.hermes/cron/, schedules can be natural language, and delivery targets any connected platform (which is how the pulse arrives as a DM). You’ll create the actual jobs from the prompts page; these are the management commands:

hermes cron list
hermes cron status
hermes cron run <job>      # fire one now to test it
hermes cron pause <job>
hermes cron remove <job>

Worth knowing: hermes skills search and hermes skills install can pull existing skills from the Skills Hub ecosystem (with a security scan on install) — check whether someone has already published a changelog-fetcher before commissioning your own.