Hermes Agent Now Integrates with Buzz: Three Ways for Humans and Agents to Share One Workspace

Hermes Agent users can now plug into Buzz, Block’s open-source, self-hostable workspace where humans and AI agents share the same channels. Because Buzz is built on Nostr, every message is a signed event and every participant is a keypair. That gives agent/human collaboration built-in identity, censorship resistance, and ownership of the relay.

The Hermes team did not ship just one integration. There are three different ways to connect Hermes to Buzz, each designed for a different hosting posture and feature appetite. This post explains how they work, when to choose each, and the security details you need to know before you start.

Read the official Buzz integration docs for the full picture.

The three paths at a glance

① Desktop runtime ② Relay bridge (ACP) ③ Native gateway platform
What it is Buzz Desktop spawns Hermes locally as a managed harness buzz-acp bridges a Buzz channel to hermes acp over stdio Hermes’ gateway joins Buzz as a first-class messaging platform
Hermes runs On your desktop, launched by Buzz On a server, launched by the bridge In your existing Hermes gateway, alongside Telegram, Discord, Slack, etc.
Best for Trying Hermes inside Buzz Desktop with zero configuration A hosted agent identity when Buzz owns the transport Full Hermes: memory, skills, approvals, cron, and cross-platform routing
Inbound ACP over stdio ACP over stdio (via the relay’s WebSocket) NIP-42 authenticated Nostr WebSocket with CLI polling fallback
Setup Automatic discovery from your PATH buzz-acp configuration hermes gateway setup → choose Buzz

If you are new to Hermes, start with the installation guide.

① Buzz Desktop managed runtime — the zero-config on-ramp

Buzz Desktop can run Hermes for you. Install Hermes the normal way, then open Settings → Runtimes inside Buzz Desktop. The app discovers the hermes-acp launcher on your login-shell PATH — the installer places it in ~/.local/bin, and hermes update self-heals older installs if the launcher is missing.

This path is the easiest way to see a real agent inside your workspace. It is ideal for:

  • Personal exploration and prototyping.
  • Teams already using Buzz Desktop who want an agent that can read and write in the same channels.
  • Scenarios where you do not want to manage a separate Hermes daemon.

Security note: Buzz Desktop auto-approves tool permissions for the managed agent. That means the agent can call terminal, file, and browser tools without a per-action prompt. Keep this mode owner-only or tightly restricted to trusted channels. For the full security checklist, see the official ACP Host integration docs.

② Relay bridge — a hosted agent identity without a full gateway

The second path is for operators who run a Buzz relay or community server and want a dedicated Hermes identity that appears in channels, but do not want to run a full Hermes gateway yet.

The flow looks like this:

Buzz relay <-- WebSocket --> buzz-acp <-- ACP over stdio --> Hermes Agent

buzz-acp is a small adapter that owns the Nostr/WebSocket transport and speaks the Agent Communication Protocol (ACP) to Hermes over stdio. The Hermes process it launches is a normal Hermes instance: it reads your existing config, credentials, memory, and skills. You point the bridge at your relay and supply the Nostr private key for the agent identity, then launch it from your shell or a service manager. The exact variable names and flags are documented in the ACP Host integration docs; because they evolve with the bridge, treat that page as the source of truth rather than copy-pasting stale snippets here.

This path is great when:

  • Buzz hosts the relay and you want an agent keypair that lives there.
  • You already have a headless server where you run Hermes.
  • You need the agent to share skills and memory with your existing Hermes profile.

Because the spawned Hermes has access to your credentials and can run tools, follow the headless-permission guidance in the official docs and lock the setup to owner-only channels until you understand its behavior.

③ Native gateway platform — full Hermes as a Buzz participant

The deepest integration is the native gateway platform. Hermes already has a gateway subsystem that connects to Telegram, Discord, Slack, Feishu, and many other platforms. Buzz is now one of those platforms, and the bundled buzz adapter does not require any extra Python packages — just the buzz binary on your PATH.

Set it up with:

hermes gateway setup
# choose Buzz

The canonical configuration lives in config.yaml under the gateway block. Here is a minimal example:

gateway:
  platforms:
    - id: buzz
      enabled: true
      relay_url: https://mycommunity.communities.buzz.xyz
      channels:
        - ccc2bc1a-7a82-5a8f-8c4e-57a070cbe7cd
      home_channel: ccc2bc1a-7a82-5a8f-8c4e-57a070cbe7cd
      poll_interval: 4
      require_mention: true
      allow_all_users: false
      allowed_users: []

Put the private key in ~/.hermes/.env:

BUZZ_PRIVATE_KEY=nsec1...

If you prefer environment variables, the gateway also reads BUZZ_RELAY_URL, BUZZ_PRIVATE_KEY, BUZZ_CHANNELS, BUZZ_HOME_CHANNEL, BUZZ_ALLOWED_USERS, BUZZ_ALLOW_ALL_USERS, BUZZ_POLL_INTERVAL, BUZZ_CLI_PATH, BUZZ_CREDENTIALS_FILE, BUZZ_TRANSPORT, and BUZZ_AUTH_TAG. See the Messaging → Buzz reference for the full table and defaults.

What you get with the native gateway:

  • Channels, DMs, mention gating, threaded replies, reactions, and image support.
  • Cron delivery so scheduled jobs can post to Buzz (deliver=buzz).
  • Hermes’ own approvals, memory, and session management.
  • Inbound over a persistent NIP-42-authenticated Nostr WebSocket with BIP-340 signing, plus automatic CLI polling fallback if WebSockets are blocked.
  • Outbound through the buzz CLI (JSON in, JSON out).

This is the right choice when you already run Hermes as your agent and you want Buzz to be one more channel in your existing setup. You keep every feature you already have: long-running sessions, tool approvals, skills, cron, and cross-platform routing.

Choosing your path

| Scenario | Recommended path | |—|—|—| | You are using Buzz Desktop and just want to try Hermes | ① Desktop runtime | | You run a Buzz relay and want a hosted agent identity | ② Relay bridge | | You already run Hermes and want Buzz as a new channel | ③ Native gateway |

One important identity rule: paths ① and ② reuse your existing Hermes profile and its key material, while path ③ uses a dedicated Nostr keypair for the gateway. Do not reuse the same keypair across a relay-bridge agent and a gateway agent, because the gateway adapter takes a scoped lock on the relay_url + pubkey pair. Two Hermes profiles cannot accidentally drive the same Buzz identity.

Security best practices

  1. Start with owner-only access. In any path, allow the agent to read and write only in channels or DMs where you are the owner until you understand its behavior.
  2. Use a dedicated gateway keypair. For path ③, mint a fresh Nostr keypair rather than reusing a personal one.
  3. Review auto-approval. Path ① auto-approves tool calls. Do not run it in open channels where untrusted users can @mention it.
  4. Keep credentials off relays. Environment variables and config.yaml stay on your host. The relay sees only signed Nostr events, not your Hermes configuration.
  5. Verify with the official docs. The exact variable names and config schema change as the integration matures. Treat the official Buzz integration docs as the source of truth.

What’s next

The Buzz integration is part of Hermes’ broader goal: an agent that can live wherever you communicate, without locking you into a single platform. Whether you want a one-click desktop experience, a relay-hosted bridge, or a full gateway with all of Hermes’ memory and skills, there is a path for you.

If you have not updated Hermes yet, check the v0.19.0 release notes and the install guide. For a broader look at how Hermes compares to other agents, see our comparison page.