# Hermes Agent + Buzz VPS Guide: ACP, systemd and Security > Deploy Hermes Agent into Buzz channels from a Linux VPS with buzz-acp, dedicated identities, systemd supervision, restricted inbound access, and verification. - **Published**: 2026-07-29 - **Category**: DevOps - **URL**: https://agentpedia.codes/blog/hermes-agent-buzz-vps-guide --- > **Important callout** **Bottom line:** a persistent Hermes installation on a Linux VPS can participate in Buzz channels without opening a Hermes HTTP or ACP port. `buzz-acp` makes an outbound WebSocket connection to the Buzz relay and launches `hermes acp` locally over stdio. Keep the identity dedicated, the service account explicit, and **Who can talk to this agent** set to **Owner only**. This guide documents a complete restricted deployment verified on July 29, 2026: a signed Buzz mention reached Hermes on a supervised VPS, Hermes used its existing profile and tools, and the same Buzz identity posted the requested reply. The commands below are sanitized templates. They do not contain the live invitation, private key, owner authorization, community address, channel ID, provider credentials, or server username used during verification. Buzz and Hermes are both moving quickly. Pin the versions you test, read the linked release notes, and treat UI labels or optional external-agent presentation as version-specific. ## Choose the right architecture Buzz can connect to Hermes in three ways, each suited to a different deployment. | Path | Where Hermes runs | What Buzz owns | Best use | |---|---|---|---| | Buzz Desktop managed runtime | On the same Mac, Windows, or Linux desktop as Buzz | Starts and stops the local ACP process | Personal desktop use where the machine stays online | | Persistent `buzz-acp` relay bridge | On a VPS or other always-on host | Carries channel events and signed replies through the relay | Existing server-side Hermes with its current files, memory, skills, and tools | | Native Hermes Buzz gateway | Inside Hermes' messaging gateway | Platform session and delivery lifecycle | Operators who want Buzz configured alongside Hermes' other messaging platforms | This article covers the second path: ```text Buzz Desktop / Buzz channel ↕ Buzz community relay ↕ authenticated outbound WebSocket buzz-acp on the VPS ↕ ACP JSON-RPC over local stdio Hermes Agent ↕ Hermes profile, memory, skills, tools and VPS filesystem ``` Buzz Desktop does **not** SSH into the server in this design. Both Desktop and `buzz-acp` connect to the community relay. The VPS needs outbound relay access, but it does not need a new inbound ACP, HTTP, SSH-forward, or dashboard port. The Mac-to-VPS SSH launcher sometimes used in prototypes is a fallback, not the persistent architecture. It depends on the desktop staying available, passwordless SSH, compatible paths, and reliable local networking. A supervised bridge on the server has fewer moving parts. ![Official Buzz screenshot showing human and agent messages organized in a channel thread](/content-assets/hermes-agent-buzz-vps-guide/buzz-channel-thread.webp) *Buzz treats humans and agents as participants in the same channel and thread interface. This official project screenshot demonstrates the collaboration surface, not the private deployment used for this guide. [Source](https://github.com/block/buzz/blob/main/docs/assets/screenshots/channel-thread.png).* ## Prerequisites and trust boundary Before configuring the relay, make sure you have: - A working Hermes Agent installation on the VPS, with one provider configured and a normal CLI conversation tested. - Hermes' optional ACP dependencies and a passing `hermes acp --check`. - A current, pinned build of the official Buzz `buzz-acp` harness and `buzz` CLI. - A dedicated Nostr keypair for the agent--not the owner's human identity. - Membership in the Buzz community and explicit membership in only the channels where Hermes should work. - The owner's 64-character public key or a verified owner-attestation tag supplied through the host or operator's supported agent-creation flow. - A private test channel for the first round trip. - A service account whose Hermes home contains the intended configuration and state. If you still need to install or evaluate Hermes itself, start with the [general Hermes Agent guide](/blog/hermes-agent-guide); this page assumes Hermes already works on the VPS. > **Warning callout** Hermes ACP exposes terminal and code-execution capabilities. The Buzz harness can answer ACP permission requests in a headless session instead of displaying a human confirmation. Treat a Buzz-connected Hermes process as privileged automation running with the service account's permissions. Do not begin with a broad community channel. Use one dedicated identity in Buzz's `owner-only` mode, one private channel, one bridge worker, no heartbeat, and no unrelated public listeners. Expand only after testing allowed owners, unrelated authors, and verified same-owner sibling agents. ## Verify Hermes ACP First prove that Hermes works without Buzz: ```bash hermes hermes doctor hermes acp --version hermes acp --check ``` If `hermes acp --check` reports a missing adapter, install the ACP extra from the Hermes installation checkout: ```bash cd ~/.hermes/hermes-agent uv pip install -e '.[acp]' hermes acp --check ``` The standard Hermes installer already includes the full extras in current releases, so many users will not need the second step. Configure the model/provider with `hermes model` before debugging the bridge. A relay cannot fix an unconfigured provider. Use the native launcher when possible: ```text Command: hermes Arguments: acp ``` `hermes-acp` and `python -m acp_adapter` are supported alternatives. The bridge must run as the same operating-system user that owns the Hermes profile you intend to expose. A bridge started as another user will see another home, another configuration, or no provider credentials at all. ## Install buzz-acp and buzz Buzz Desktop release artifacts package the desktop application, but a server deployment needs the `buzz-acp` harness and `buzz` CLI. Use a current official artifact if the release provides one for your platform. Otherwise build from a pinned official tag or commit on a CI runner or development machine--not on a resource-constrained production VPS. ```bash export BUZZ_REF='' git clone https://github.com/block/buzz.git cd buzz git checkout "$BUZZ_REF" cargo build --locked --release -p buzz-acp -p buzz-cli sha256sum target/release/buzz-acp target/release/buzz ``` Install the two verified binaries for the Hermes service account: ```bash install -d -m 0755 "$HOME/.local/bin" install -m 0755 target/release/buzz-acp "$HOME/.local/bin/buzz-acp" install -m 0755 target/release/buzz "$HOME/.local/bin/buzz" "$HOME/.local/bin/buzz-acp" --help "$HOME/.local/bin/buzz" --help ``` Record the source ref, checksums, target architecture, and installation date. Do not copy a binary from an untrusted gist or anonymous file host merely because it starts. At the July 29 review point, Buzz Desktop `v0.5.0` included the generic Bring Your Own Harness mechanism and a Hermes preset. That preset supports a local managed runtime, which is separate from the server bridge described here. Because packaging, external-agent cards, observer UI, and session persistence have continued to change upstream, base acceptance on observed behavior rather than a screenshot. ## Create identity and membership Every visible, long-lived agent needs its own Nostr identity, which determines who signs messages, which channels the relay exposes, and which owner policy applies. ### Self-hosted relay If you administer the Buzz relay, follow the official `buzz-acp` README: ```bash # Run from the pinned Buzz source checkout. cargo run -p buzz-admin -- generate-key # On the relay host, register only the new agent public key. BUZZ_RELAY_PRIVATE_KEY='[REDACTED]' \ cargo run -p buzz-admin -- add-member \ --pubkey '' ``` The generated private key is not recoverable. Move it directly into the protected bridge environment file and remove transient copies. ### Hosted community Hosted onboarding is host-specific. Obtain a dedicated agent key and a valid NIP-OA owner attestation through the host or operator's supported agent-creation flow, or configure `BUZZ_ACP_AGENT_OWNER` when that deployment permits it. Use a community invitation only to join the relay; do not assume the invitation claim returns `BUZZ_AUTH_TAG`. 1. Generate a dedicated agent identity on the VPS or through the approved Buzz setup flow. 2. Obtain the owner attestation or approved owner public key separately through the host's supported agent workflow. 3. Create and claim a one-time community invitation for the dedicated agent identity. 4. Accept the community's current Terms, Privacy Notice, and age confirmation only after reviewing them. 5. Add the agent identity to the intended private channel. Community membership and channel membership are separate steps. 6. Store any returned key, attestation, or token only in the protected bridge configuration; do not paste it into chat, screenshots, issue reports, or shell history. The exact claim endpoint and UI can change. This article deliberately does not publish a copied private invitation or an unofficial hard-coded claim script. Use the onboarding flow supplied by your Buzz community and verify the resulting identity and channel membership with the official CLI. Once the bridge environment is loaded, confirm accessible channels without printing secrets: ```bash buzz channels list ``` The harness discovers channels where the agent identity is already a member. An identity can successfully join the community yet see zero channels; that usually means the channel-membership step is missing. ![Official Buzz screenshot showing agents available within a channel](/content-assets/hermes-agent-buzz-vps-guide/buzz-channel-agents.webp) *Channel membership is an authorization boundary. The bridge discovers and subscribes to channels where its dedicated identity is a member. [Source](https://github.com/block/buzz/blob/main/docs/assets/screenshots/channel-agents.png).* ## Configure the owner-only bridge Create a private configuration directory owned by the Hermes service account: ```bash install -d -m 0700 "$HOME/.config/buzz-hermes" install -m 0600 /dev/null "$HOME/.config/buzz-hermes/bridge.env" ``` Edit `bridge.env` directly on the VPS. Use placeholders like these: ```bash BUZZ_RELAY_URL=wss://community.example.com BUZZ_PRIVATE_KEY=[REDACTED] # Hosted communities may require one or both of these. # Preserve JSON quoting when a NIP-OA auth tag is supplied. BUZZ_AUTH_TAG='["auth","","",""]' BUZZ_API_TOKEN=[REDACTED] BUZZ_ACP_AGENT_OWNER=<64-CHAR-OWNER-PUBLIC-KEY> BUZZ_ACP_AGENT_COMMAND=/home/hermes/.local/bin/hermes BUZZ_ACP_AGENT_ARGS=acp BUZZ_ACP_RESPOND_TO=owner-only BUZZ_ACP_ALLOWED_RESPOND_TO=owner-only BUZZ_ACP_AGENTS=1 BUZZ_ACP_LAZY_POOL=true BUZZ_ACP_HEARTBEAT_INTERVAL=0 BUZZ_ACP_RELAY_OBSERVER=true ``` Delete `BUZZ_AUTH_TAG` or `BUZZ_API_TOKEN` when your relay does not use it; do not leave literal `[REDACTED]` values in a working file. Replace `/home/hermes` with the real home of the existing Hermes account. `BUZZ_ACP_ALLOWED_RESPOND_TO=owner-only` is a startup guard: the process refuses a future configuration that changes `BUZZ_ACP_RESPOND_TO` to a broader mode. Keep both lines. Do not use `anyone` for a host with terminal and filesystem tools. Buzz calls this mode `owner-only`, but in v0.5.0 it also accepts agents whose cryptographically verified NIP-OA profile proves the same owner. Treat those as trusted siblings, not unrelated authors. Test the registered owner, one verified same-owner sibling, and one unrelated author before relying on the gate. The optional observer publishes encrypted, owner-addressed ACP activity for Buzz Desktop's Activity view. It needs a resolved owner. If replies work but Activity remains empty, verify owner resolution and open Desktop before starting the test; observer relay frames are ephemeral, while Desktop's local archive is the durable copy. Do not automatically set `HERMES_ACP_SKIP_CONFIGURED_MCP=1`. That host marker skips Hermes' globally configured MCP servers. Use it only when Buzz deliberately supplies the required MCP servers through ACP `session/new`; otherwise it can remove tools you expected the existing Hermes profile to load. Recheck permissions without revealing contents: ```bash chmod 0700 "$HOME/.config/buzz-hermes" chmod 0600 "$HOME/.config/buzz-hermes/bridge.env" stat -c '%a %U:%G %n' \ "$HOME/.config/buzz-hermes" \ "$HOME/.config/buzz-hermes/bridge.env" ``` ## Run the foreground test Do not use a service manager as the first debugging environment. Load the environment in a private shell owned by the Hermes account, then run the bridge in the foreground: ```bash set -a . "$HOME/.config/buzz-hermes/bridge.env" set +a "$HOME/.local/bin/buzz-acp" ``` Expected behavior: - The bridge authenticates to the relay without printing secrets. - It discovers at least the private test channel. - It starts the configured Hermes ACP command. - ACP initialization succeeds. - The process remains running and waits for an allowed mention. A bounded smoke test can prove process survival: ```bash timeout 20s "$HOME/.local/bin/buzz-acp" printf 'exit=%s\n' "$?" ``` Exit code `124` means `timeout` stopped a process that was still running. It does **not** prove a complete Buzz-to-Hermes-to-Buzz exchange. For that proof, open the private test channel as the owner and send a fresh mention: ```text @Hermes VPS reply exactly: BUZZ-HERMES-OK ``` Success requires `BUZZ-HERMES-OK` to return from the dedicated agent identity in the same channel or thread. Stop the foreground bridge with `Ctrl+C` only after capturing the non-secret result and relevant timestamps. ## Make the bridge persistent Use the same user that owns the tested Hermes home. The example below assumes that account is named `hermes` and its home is `/home/hermes`: ```ini [Unit] Description=Owner-only Buzz bridge for Hermes ACP Documentation=https://github.com/block/buzz/tree/main/crates/buzz-acp After=network-online.target Wants=network-online.target [Service] Type=simple User=hermes Group=hermes WorkingDirectory=/home/hermes Environment=HOME=/home/hermes Environment=PATH=/home/hermes/.local/bin:/usr/local/bin:/usr/bin:/bin EnvironmentFile=/home/hermes/.config/buzz-hermes/bridge.env ExecStart=/home/hermes/.local/bin/buzz-acp Restart=on-failure RestartSec=5s KillMode=control-group KillSignal=SIGTERM TimeoutStopSec=30s UMask=0077 NoNewPrivileges=true PrivateTmp=true [Install] WantedBy=multi-user.target ``` Save it as `/etc/systemd/system/buzz-hermes.service`, then verify before enabling: ```bash sudo systemd-analyze verify /etc/systemd/system/buzz-hermes.service sudo systemctl daemon-reload sudo systemctl enable --now buzz-hermes.service sudo systemctl is-active buzz-hermes.service sudo systemctl status buzz-hermes.service --no-pager sudo journalctl -u buzz-hermes.service -n 100 --no-pager ``` Do not copy the `User`, home, or binary paths blindly. Running the service as `root` gives the agent root-level filesystem and process authority. For a fresh deployment, prefer a dedicated unprivileged account with access only to the projects and credentials it needs. If you reuse an existing Hermes installation, explicitly assess the authority that account already has. More aggressive systemd hardening can break legitimate Hermes tools. Add filesystem write restrictions, private devices, or network isolation only after mapping required capabilities and rerunning the acceptance tests. ## Verify the complete path A successful `systemctl is-active` check proves only that the service process is alive. Use this acceptance matrix to verify the complete path: | Check | Expected result | |---|---| | Service identity | `systemctl show` reports the intended non-root account | | Secret permissions | Config directory is `0700`; key-bearing file is `0600` | | Relay connection | Recent journal shows a successful connection without leaked credentials | | Channel discovery | Only intended member channels are visible | | Owner mention | Fresh mention produces the exact signed test reply | | Unrelated author mention | Ignored before reaching Hermes; separately test a cryptographically verified same-owner sibling | | Hermes state | Reply reflects the intended profile, model and workspace--not another user's home | | Activity observer | Optional lifecycle/tool/response frames appear only for the verified owner | | Restart | `systemctl restart` reconnects and passes a new test mention | | Reboot | Service starts after boot and passes another new test mention | | Rollback | Stopping this unit leaves Telegram, other gateways and unrelated production services online | Record time, installed versions, source ref, service state, and the harmless response event. Never record the invitation, private key, auth tag, API token, provider credentials, authorization header, or full environment file. ## Security boundaries ### Keep the author gate restricted The official Hermes ACP guide warns that Buzz can auto-answer permission requests. `approvals.mode: manual` is not a reliable safety boundary when the host answers on the user's behalf. Leave **Who can talk to this agent** set to **Owner only** and both bridge gate variables set to `owner-only`. In Buzz v0.5.0 that mode accepts the registered owner plus cryptographically verified same-owner sibling agents, so test both sibling and unrelated-author behavior. An allowlist can be appropriate for a tightly controlled specialist pool, but it should be a deliberate change with explicit public keys, narrow channel membership, tool restrictions, rate limits, and audit logs. "Anyone" is not a collaboration convenience here; it delegates the service account's tool authority to every reachable author. ### Treat channel membership as authorization The relay exposes channels according to the agent identity's membership. Add the identity only where it is expected to work. Remove it before repurposing a channel, and avoid using broad announcement channels as operational queues. ### Separate identities and accounts Do not reuse the owner's Nostr private key. Long-lived agents should have separate keys so one compromised specialist can be revoked without rotating every identity. Where roles need different filesystem or credentials, use separate Hermes profiles or operating-system accounts rather than relying only on prompt instructions. ### Protect every secret surface Sensitive material includes: - Nostr private keys and `nsec` values; - one-time invitations and signed owner-attestation tags; - relay API tokens and authentication headers; - provider API keys and OAuth files; - SSH keys, GitHub credentials, cloud credentials and package-manager tokens visible to the service account; - logs, backups and screenshots containing any of the above. Keep secrets out of command-line arguments where possible, because process listings and shell history can expose them. Use a `0600` environment file, a system credential store where available, or another secret manager compatible with the service account. ### Do not open a Hermes port `buzz-acp` talks to `hermes acp` over local stdio. Opening an unauthenticated ACP, dashboard, or HTTP port on the VPS adds risk without helping this architecture. If remote administration is required, use an authenticated private management path and keep it separate from channel traffic. ## Multi-agent design Increasing `BUZZ_ACP_AGENTS` adds worker capacity behind one identity. It does not create separate visible Buzz agents: every worker signs with the same Nostr key. For stable, user-visible roles, use a small pool of separately controlled identities: ```text Hermes coordinator ├── Research specialist ├── Coding specialist ├── Content specialist └── Operations specialist ``` Each visible specialist needs its own: - Nostr keypair and Buzz profile; - owner attestation or relay membership; - explicit channel memberships; - service or container; - Hermes profile or account boundary where needed; - role, tool and budget policy; - shutdown path and audit trail. Use mention- or task-based routing. The coordinator should assign bounded work; specialists should reply only to the owner, coordinator, or explicitly allowlisted siblings. Add recursion, rate, cost and concurrency limits so agents cannot trigger an uncontrolled response loop. Hermes' internal delegated subagents solve a different problem. They are temporary workers created inside one Hermes turn. In the stock ACP path reviewed for this guide, their lifecycle remains internal and their output returns through the main `Hermes VPS` identity. If temporary children are projected into Buzz in the future, the safest model is **one Buzz thread per temporary child**, not one permanent identity per child: ```text Hermes child starts -> bridge creates one Buzz thread under the parent identity -> bounded lifecycle updates appear in that thread -> authorized replies steer the live child -> late replies return to the parent after the child completes ``` That extension needs durable mappings among channel ID, Buzz root event, parent session, subagent ID, state, and last-seen event. It also needs self-event filtering, deduplication, edit/delete handling, owner checks, completion rules, rate limits and a kill switch. Until those controls are audited, keep temporary subagents internal. ## Current limitations - **Bridge restarts lose channel conversation bindings in Buzz Desktop v0.5.0.** `buzz-acp` stores channel-to-ACP session IDs only in process memory and does not call `session/load`; restarting the bridge starts a cold channel conversation. Durable binding work in PR #2633 was still unmerged at this review cutoff. - **Desktop presentation is version-dependent.** The underlying signed relay exchange can work even if an external agent card, avatar, presence state, or Activity panel differs between Buzz versions. - **Observer events are not a server-side audit log.** Owner-addressed Activity frames are ephemeral on the relay. Desktop must be online to receive them; the durable archive is local to the owner client. - **Headless approval remains powerful.** The host can approve terminal actions without surfacing a dialog, so restricted inbound access and OS-level containment are essential. - **Internal subagents are not native Buzz participants.** Worker count and Hermes delegation remain behind one visible identity unless you build a separate thread projection. - **Hosted onboarding can differ.** Invitation claim endpoints and owner-attestation flows are community- and release-specific. Follow the current host's official onboarding path. These limitations call for version pinning and explicit testing; they do not justify opening more ports or broadening the author gate. ## Troubleshooting ### `hermes acp --check` fails Install the ACP extra in the same Hermes checkout and interpreter used by the service. Confirm the service account's PATH resolves the expected `hermes` binary. ### Bridge starts, then Hermes exits Run `hermes`, `hermes doctor`, and `hermes acp --check` as the service user. Check provider credentials and home-directory ownership. A successful root shell test does not prove an unprivileged service account can read the same files. ### Authentication fails Check whether the relay requires an API token, owner-attestation tag, or signed invitation claim. A community invite is not the same as an API token. Do not paste either value into a public issue. ### The bridge discovers zero channels Community membership does not automatically grant channel membership. Add the dedicated agent identity to the private test channel, then reconnect or wait for the membership notification. ### Owner-only mode drops every message The gate fails closed when no owner is resolved. Verify `BUZZ_ACP_AGENT_OWNER` is the expected 64-character owner public key or that `BUZZ_AUTH_TAG` is valid for this agent identity. Do not switch to `anyone` to make the symptom disappear. ### Replies work but Activity is empty Confirm `BUZZ_ACP_RELAY_OBSERVER=true`, owner resolution succeeded at startup, and Buzz Desktop was online before the turn. Activity availability and archive behavior can vary by Desktop version. ### The service is active but no one receives replies Inspect recent logs, then test the full chain in order: ```bash sudo journalctl -u buzz-hermes.service -n 100 --no-pager sudo -u hermes /home/hermes/.local/bin/hermes acp --check sudo -u hermes /home/hermes/.local/bin/buzz-acp --help ``` Check the exact mention, identity, channel membership, and author gate. Process survival alone is not message delivery. ### A restart loses context Buzz Desktop v0.5.0 starts a cold channel conversation after a bridge restart because the channel-to-session binding lives only in process memory. Send `!rotate` as the owner when you intentionally want a clean channel session. Do not promise restart recovery unless a later pinned build implements and passes a harmless multi-turn `session/load` test. ## Rollback and removal Stop only the bridge: ```bash sudo systemctl disable --now buzz-hermes.service sudo systemctl reset-failed buzz-hermes.service ``` That should not stop the Hermes Telegram gateway, production containers, databases, reverse proxies, or unrelated services. Verify them independently rather than assuming the rollback is isolated. After revoking the agent's channel and community membership: 1. Archive only non-secret operational notes you need. 2. Securely remove the bridge environment file and any transient invitation material. 3. Revoke relay tokens and owner attestations where the platform supports it. 4. Rotate the Nostr identity if compromise is suspected. 5. Remove the unit and binaries only after confirming no other service uses them. 6. Keep the Hermes profile if it serves other interfaces; the bridge and Hermes state are separate layers. A clean rollback demonstrates that Buzz transport can be removed without dismantling the existing Hermes installation. ## FAQ ### What does buzz-acp do for Hermes Agent? buzz-acp receives authorized Buzz relay events, opens Hermes over the Agent Client Protocol on local stdio, and gives the Hermes process access to the Buzz CLI so it can publish signed replies. It does not expose a public Hermes port. ### Does Buzz replace Hermes memory, skills or model configuration? No. The relay bridge launches the existing Hermes installation under a chosen operating-system account. Hermes therefore uses that account's provider setup, profile, memory, skills, tools, and filesystem permissions. ### Why should the Hermes Buzz agent remain owner-only? Hermes ACP includes terminal and code-execution tools, while the headless Buzz harness can answer ACP permission requests without displaying a human approval dialog. Buzz's owner-only mode restricts access to the owner and cryptographically verified same-owner sibling agents, so test both unrelated authors and trusted siblings before expanding access. ### Does running several buzz-acp workers create several visible Buzz agents? No. Workers behind one bridge share the same Nostr identity, so Buzz users still see one agent. Separately visible long-lived specialists need separate keys, profiles, channel memberships, services, and narrowly defined permissions. ### Do Hermes subagents automatically appear as Buzz agents or threads? Not in the stock integration reviewed for this guide. Hermes can delegate internally, but temporary children remain behind the main Buzz identity. Projecting them into Buzz threads requires a separate audited lifecycle and reply-routing extension. ## Official sources - [Hermes ACP Host Integration](https://hermes-agent.nousresearch.com/docs/user-guide/features/acp) - [Hermes Buzz integration overview](https://hermes-agent.nousresearch.com/docs/integrations/buzz) - [Hermes Agent quickstart](https://hermes-agent.nousresearch.com/docs/getting-started/quickstart) - [Hermes ACP tool adapter source](https://github.com/NousResearch/hermes-agent/blob/main/acp_adapter/tools.py) - [Hermes delegation tool source](https://github.com/NousResearch/hermes-agent/blob/main/tools/delegate_tool.py) - [Buzz `buzz-acp` README](https://github.com/block/buzz/blob/main/crates/buzz-acp/README.md) - [Buzz Desktop v0.5.0 release](https://github.com/block/buzz/releases/tag/v0.5.0) - [Buzz Bring Your Own Harness implementation, PR #2773](https://github.com/block/buzz/pull/2773) - [Buzz durable ACP session work, PR #2633](https://github.com/block/buzz/pull/2633) - [Buzz Hermes/external-agent history, closed PR #2468](https://github.com/block/buzz/pull/2468) - [Hermes ACP documentation history, closed PR #69915](https://github.com/NousResearch/hermes-agent/pull/69915) - [Agent Client Protocol](https://agentclientprotocol.com/) - [systemd service unit reference](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) - [systemd execution environment reference](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html) - [systemd-analyze reference](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html) --- [Join the Agentpedia newsletter](https://agentpedia.codes/blog) [Browse related Agentpedia articles](https://agentpedia.codes/blog) --- - [All articles](https://agentpedia.codes/blog)