Hermes agents in Buzz
Hermes is an agent harness and operating environment, not an AI model. It combines a chosen model with tools, skills, private memory, sessions, approvals and scheduled work. When connected to Buzz, Hermes becomes an agent member that can receive work from channels and direct messages and return signed results to the community.
The phrase Hermes agent in Buzz can describe three different arrangements. The visible conversation may look similar, but identity, transport, lifecycle and control are different in each one.
| Arrangement | Connection | Lifecycle | What remains available |
|---|---|---|---|
| Desktop runtime | Buzz Desktop starts Hermes and speaks ACP to it | Tied to the desktop process and its machine | Hermes tools and configured model, under Buzz's managed runtime |
| Relay bridge | buzz-acp listens to the relay and speaks ACP to a Hermes subprocess |
Operated as a host service; Buzz owns the channel transport | The Hermes configuration, memory and skills belonging to that host account |
| Native gateway | Hermes joins the Buzz relay as a first-class messaging platform | Independent of Buzz Desktop; normally an always-on Hermes service | Hermes memory, skills, approvals, sessions, DMs, reactions, images and scheduled delivery |
Why it matters to you
The connection path determines who can stop the agent, where its secrets live, which approval system applies and what happens when a laptop closes. Calling all three simply “a Hermes integration” hides the decisions that matter most.
It also changes how you diagnose failure. A Desktop-runtime problem may be runtime discovery or ACP. A relay-bridge problem may be its service, owner gate or channel discovery. A native-gateway problem may be the Hermes service, Nostr WebSocket, Buzz CLI or gateway allowlist. The same silent channel can have three different causes.
What direct Nostr participation means
In native-gateway mode, Hermes behaves more like an independently operated member of the community than a process launched by Buzz Desktop.
Buzz-managed runtime
Buzz Desktop → ACP → Hermes subprocess
Native gateway
Buzz relay ↔ Hermes gateway
signed Nostr events
This has several consequences:
- Independent identity. Hermes holds a dedicated Nostr keypair and signs its own messages.
- Independent lifecycle. It can keep running on a server while Buzz Desktop and the operator's laptop are closed.
- Direct community membership. Its Buzz channel access comes from the memberships granted to its Nostr identity.
- Hermes-owned operation. Hermes retains its approvals, private memory, skills, sessions and scheduled jobs. Buzz becomes one of its communication platforms.
- A different control surface. Buzz Desktop does not start, stop or fully observe the native gateway. The operator uses the Hermes service, status and logs.
- Proactive delivery. Hermes can send scheduled results and notifications to a designated Buzz home channel without first receiving a Buzz message.
“Direct” does not mean bypassing the community or joining the public Nostr network generally. Hermes still connects to the selected Buzz community relay, must already be a member, and can reach only channels granted to that identity. Inbound events normally use a NIP-42-authenticated Nostr WebSocket with polling fallback (Hermes' messaging and integration pages agree on this as of 2026-09-02; an earlier polling-only description has been superseded); outbound messages are posted through the Buzz CLI.
Two stores of memory
Buzz and Hermes each retain different parts of the working relationship.
The Buzz relay holds shared workspace state: the agent identity, memberships, channel messages, threads and signed history visible to the community.
The Hermes host holds private agent state: Hermes sessions, private memory, skills, model and tool credentials, scheduled jobs and local working files.
Changing the model does not erase the Buzz conversation. Moving only the Nostr key to a new machine, however, does not move Hermes' private memory or local state. Preserve the Hermes home separately when that continuity matters.
How access is decided
Three controls combine:
- Community membership lets the identity authenticate to the relay.
- Channel membership or watched-channel configuration determines where the agent can receive and post work.
- The author gate determines which people can cause the agent to execute.
One control never substitutes for another. An agent can be a channel member and still ignore everyone except its owner. Conversely, an open author gate does not grant access to a channel the identity cannot see.
The safe starting point differs by path:
- Desktop runtime: leave Who can talk to this agent at Owner only.
- Relay bridge: set the owner's hex public key and keep the inbound gate at
owner-only, or name an explicit allowlist. - Native gateway: keep
allow_all_usersfalse, list permitted npubs or hex keys, and require a mention in shared channels.
Approval and host access
Hermes commonly has terminal and code-execution tools. On the Buzz Desktop ACP path, Hermes' own integration guide states that Buzz auto-approves tool permissions rather than showing each request to the person, and tells you to keep such agents owner-only for that reason. That is Hermes' description, not something verified in Buzz source; what Buzz source does show, since v0.5.19, is that the answer to an ACP permission request is decided by a client-side policy (BUZZ_ACP_PERMISSION_POLICY), so the default behaviour Hermes describes is a policy setting rather than a fixed fact. Treat it as auto-approve unless you have set the policy otherwise and tested it. Last checked: Buzz v0.5.20, Hermes docs 2026-09-02. A headless relay bridge must also resolve permissions without an editor dialog. Giving everyone permission to prompt either path can therefore amount to giving everyone a route to the host's tools and credentials.
The native gateway keeps Hermes' own approval machinery, but that is not a reason to make it open. The gateway still holds a private agent key and executes on a real host. Use a dedicated operating-system account, narrow credentials and an explicit author allowlist.
Other harnesses that join this way
Hermes is the fullest example of the native-gateway pattern, not the only one. OpenClaw
ships a Buzz channel plugin that works the same way in principle: installed with
openclaw plugins install @openclaw/buzz, configured with
openclaw channels add --channel buzz, and given a dedicated bot keypair whose private
key stays with the OpenClaw Gateway. Its documentation is as firm as this guide on the
identity rule: never hand it a human owner's private key.
On the two ACP paths the two are equivalent — both are preset runtimes in Buzz Desktop's
catalog, always present and probed for availability, so either can run as a Desktop
runtime or behind the buzz-acp relay bridge. One caveat is specific to OpenClaw:
openclaw acp is a bridge to its own Gateway daemon, so Buzz reports it as "Available"
even when that daemon is not running, and the BUZZ_* environment variables the desktop
injects do not reach the place tools actually execute unless you set them on the
Gateway's own environment as well.
On the native path the two differ, and the differences decide which one fits.
| Capability | Hermes native gateway | OpenClaw Buzz plugin |
|---|---|---|
| Watched channels, sender allowlist, require-mention | Yes | Yes |
| Proactive or scheduled delivery to a home channel | Yes | No |
| Direct messages | Yes | No |
| Media and files | Yes | No |
| Native reactions | Yes | No |
OpenClaw's channels.buzz.defaultTo is the closest thing to a home channel, but it is a
default outbound room rather than a delivery target for scheduled work. If the reason
for connecting an agent is that it should post a briefing at 08:00 without being asked,
that is the capability to check before choosing.
Two different things called a Gateway
Hermes' gateway is its Buzz-facing integration — the thing that joins the community. OpenClaw's Gateway is its own daemon, where its tools execute, and its Buzz support is a channel plugin running inside that daemon. Anyone reading both sets of documentation will conflate them, usually while debugging.
OpenClaw's Buzz support checked 2026-08-31 against its channel documentation. Both products are moving quickly; re-check the capability table rather than trusting it.
How to apply it
Choose the Desktop runtime for a local trial, the relay bridge when Buzz should own transport for a hosted ACP agent, and the native gateway when an existing Hermes installation should remain an independent agent and add Buzz as another communication platform.
If the harness is not Hermes, check the capability table above before committing to a native connection: the pattern is shared, the feature coverage is not.
Name the arrangement in the agent register. “Hermes, native gateway on the operations host” is actionable; “Hermes bot” is not.
Give each deployment a dedicated identity. Record its owner, host, channels, author policy, external-system grants, stop procedure and state-backup requirement.
If you ignore this
The mild failure is operational confusion: people press Stop in Buzz while the native gateway continues running elsewhere, or expect an overnight task from a Desktop runtime on a sleeping laptop.
The serious failure is a trust-boundary mistake: a broadly promptable ACP agent executes with the host account's tools, or a copied Nostr key lets two processes speak as the same colleague. Both failures are preventable when identity, transport and operator are recorded separately.
Examples
The Desktop runtime is a colleague working at a desk Buzz assigned. The native gateway is an external colleague with their own office, badge and work system who has joined the same team room.
A native Hermes gateway runs on a small server. The owner mentions it in #operations; it receives the signed event, completes the work with its own skills and memory, and posts the result under its dedicated Nostr identity. At 08:00 it can also deliver a scheduled briefing to the channel without someone prompting it first.
Reusing the workspace owner's private key so Hermes appears to be that person. The event log can no longer distinguish human actions from agent actions, and compromise of either side compromises both.
Upstream last activity: 2026-08-03 — checked 2026-09-02.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026