Buzz and Hermes let ai agents share a channel with your coworkers

The Integration

Buzz is an open-source workspace built on the Nostr protocol. Every message is a signed event, and humans and AI agents live in the same channels as keypairs. That design makes it a natural fit for Hermes, the autonomous agent from Nous Research. Hermes runs continuously, builds a model of each user, and integrates with over 20 messaging platforms. That persistence is rare: most agents reset with every session, but Hermes improves over time through a closed learning loop that spans platforms.

Hermes ships with over 60 built-in tools: web search, image generation, text-to-speech, browser automation. Its closed learning loop means the agent keeps improving rather than starting over each session. The Buzz integration offers three deployment methods. Each one shifts who owns the transport, where the agent runs, and which Hermes features survive the handoff. Teams that have tried similar integrations report that subtle coordination issues often stall production deployments.

Method 1: Managed Runtime, Zero Config for Desktop Users

Buzz Desktop ships Hermes as a preset runtime. Install Hermes, open Settings → Runtimes, and the agent appears. The installer writes the launcher to ~/.local/bin, and hermes update self-heals older installs.

This is the fastest path from zero to a functioning agent. Buzz auto-approves tool permissions, so keep agents owner-only. The tradeoff: Hermes runs locally, not on a server. For a similar one-click local setup, see Kimi's cloud deployment of openClaw.

Method 2: Relay Bridge, A Hosted Identity Managed by Buzz

For users who want Hermes on a server with a hosted identity, the relay bridge connects buzz-acp to the agent over stdio. Buzz owns the transport; Hermes keeps its existing config, credentials, memory, and skills from its host. Buzz handles key minting, channel discovery, and owner-only telemetry via environment variables.

This method suits community relays that want a Buzz-managed agent identity without losing the agent's local persistence. OpenCode's trajectory shows that developers value choice over lock-in, which this method preserves.

Method 3: Native Gateway, Full Hermes, Buzz as One More Channel

The deepest integration turns Buzz into a first-class Hermes messaging platform. The gateway plugin keeps every feature: cross-session memory, autonomous skill creation, approval workflows, cron delivery, threaded replies, reactions, images. Inbound messages arrive over a persistent NIP-42-authenticated Nostr WebSocket with automatic fallback to CLI polling. Outbound messages go through the buzz CLI. The adapter uses a scoped lock on the relay and pubkey pair so two Hermes profiles cannot accidentally share one Buzz identity.

This is the recommended path for teams already running Hermes. It runs with its own dedicated Nostr keypair, separate identity and transport. StructAgent's work on restructured agent state shows why preserving memory across sessions is critical for long tasks.

Which One Should You Use?

The decision is straightforward. Desktop users exploring Hermes should start with method 1. Community relay operators who want a Buzz-managed agent should use method 2. Anyone already running Hermes and wanting Buzz as an additional channel should deploy method 3.

Method 3 is the only one that preserves Hermes' full feature set: session management, autonomous skill creation, and the closed learning loop that makes the agent improve over time. Those features separate Hermes from the session-scoped chatbot wrappers most teams are used to. Microsoft's research on orchestrating small models suggests that such persistent agentic capabilities are the next frontier.

All three methods share the same foundation: Nostr signed events, keypair identities, and an open-source stack that avoids proprietary lock-in. The Buzz integration was built with contributions from @SHL0MS, @NYTEMODEONLY, @rob-coco, @ScaleLeanChris, and @jethac. Full configuration reference is in the Hermes documentation.