Multi-agent setup: Profile-based agents generate responses but fail to publish to hosted relay

[sunilsucb]

Summary

When running multiple Hermes Agent profiles as separate managed agents in Buzz (v0.5.2) connected to a hosted community relay (*.communities.buzz.xyz), only the first/default agent successfully publishes responses to channels. Additional profile-based agents initialize correctly, receive messages, generate responses (visible in streaming preview), but the responses never persist in the channel.

Environment

• Buzz version: 0.5.2 (macOS desktop app)
• OS: macOS 26.5.2 (Apple Silicon)
• Agent runtime: Hermes Agent v0.19.1 (2026.7.30)
• Relay: Hosted community relay (wss://sunilsharma.communities.buzz.xyz)
• ACP bridge: buzz-acp (bundled with Buzz 0.5.2)

Setup

I have multiple Hermes Agent profiles configured as separate managed agents in Buzz:

Agent Name	Hermes Profile	Pubkey (from logs)
DustyBot_Main	(default)	2a29f6c0...
ElevenBot_Health	eleven	097d3586...
LucasBot_Finance	lucas	1e42bd3d...
MaxBot_Productivity	max	(separate)
MikeBot_Creativity	mike	(separate)
WillBot_Family	will	(separate)

Each agent uses a HERMES_PROFILE env var in managed-agents.json. All use the built-in Hermes runtime via hermes-acp wrapper.

Expected Behavior

All managed agents should publish responses to channels on the hosted relay.

Actual Behavior

1. DustyBot_Main (default profile) works - responds and responses appear in channel.
2. All other profile-based agents fail silently - they start, connect, subscribe, receive messages, generate responses (visible in streaming preview), but responses never persist in the channel.

Diagnostic Details

Working agent (DustyBot_Main) startup:

buzz_acp starting: relay=wss://sunilsharma.communities.buzz.xyz 
  pubkey=2a29f6c0... agents=1 respond_to=anyone subscribe=Mentions

Failing agent (ElevenBot_Health) startup:

buzz_acp starting: relay=wss://sunilsharma.communities.buzz.xyz 
  pubkey=097d3586... agents=10 respond_to=anyone subscribe=Mentions

ElevenBot generates a response (Turn ended, response_len=79) but it never publishes. No error logged.

LucasBot_Finance:

Same pattern - generates multi-turn responses with claude-opus-4-8, completes turns successfully, but nothing published. Also encounters:

Tool terminal error: auth_error: BUZZ_PRIVATE_KEY is required

managed-agents.json:

Shows pubkey: "" and relay_url: "" for all agents, even though buzz-acp clearly generates pubkeys (visible in logs).

Hypothesis

The hosted relay may only authorize publishing from the first agent pubkey. Additional pubkeys from "Add Agent" may not be added to the relay allow-list, causing silent rejection.

Steps to Reproduce

1. Create a hosted Buzz community
2. Add first agent (Hermes runtime) - works correctly
3. Add more agents via "Add Agent" with HERMES_PROFILE env vars
4. Mention a secondary agent in a channel
5. Response streams in preview but does not persist

Workarounds Attempted (none worked)

• Restarting Buzz app
• Stopping/starting individual agents
• Changing respond_to settings
• Using different models
• Setting HERMES_PROFILE as env var vs args

Questions

1. Do hosted relays support multiple agent pubkeys publishing to the same community?
2. Is there a registration step to authorize new agent pubkeys on hosted relays?
3. Should pubkey/relay_url fields in managed-agents.json be populated, and what populates them?

[iroiro147]

Confirmed the mechanism in-source — and the "silent rejection" hypothesis is right, but the allow-list detail differs slightly from the issue's guess.

The relay enforces NIP-43 membership on publish, with an NIP-OA owner fallback: an agent that isn't itself a relay member may still publish if its event carries a valid auth tag proving its owner (crates/buzz-relay/src/api/mod.rs:61 check_relay_membership → MembershipDecision::ViaOwner when the owner is a member). The fallback path (enforce_relay_membership, mod.rs:124) returns 403 relay_membership_required when neither the agent nor its NIP-OA owner is a member.

So the question is whether secondary agents' publish events carry that per-agent auth tag. The relay only consults it when present (auth_tag_header). Events carry NIP-OA auth only if the publisher attaches it (BUZZ_AUTH_TAG / agent_auth on the event builder — see buzz-sdk/src/builders.rs:1781, which only adds the ["auth",...] tag when one is provided). The countdown-bot example and the e2e/bench flows pass a per-agent computed auth tag explicitly (examples/countdown-bot/src/main.rs:100 compute_auth_tag(&owner_keys, &bot_keys.public_key(), ""); bench BUZZ_AUTH_TAG). If the desktop "Add Agent" path doesn't mint + attach a per-agent NIP-OA auth tag for each added profile, every secondary publish goes through the fallback without an auth tag → Deny → 403.

That explains the exact symptom set: the default agent publishes (it's a member / has its tag), secondary profiles generate a full response but the relay 403s it, and the client swallows the rejection ("no error logged" — the publish error isn't surfaced to the streaming preview).

Two separate maintainer design calls, both worth deciding explicitly:

1. Desktop / buzz-acp: should "Add Agent" (or the acp bridge) mint a per-agent NIP-OA auth tag from the creator's owner key and attach it to every publish, so secondary agents pass the owner-delegation fallback? Or should remote agents on a hosted relay be auto-added as members at "Add Agent" time instead?
2. Relay / client error surfacing: when the relay 403s a publish, the rejection should reach the user instead of being silently dropped — otherwise this whole class of authorization failure is invisible.

I'd rather not guess which contract the maintainers intend before writing a patch; happy to implement whichever direction you prefer.

[sunilsucb]

Thanks for the deep dive! From a user perspective, option 1 (auto-minting the auth tag at "Add Agent" time) seems like the right default since it matches how the countdown-bot example already works and doesn't require relay-side changes.

Separately, surfacing the 403 as a visible error in the UI would be a huge QoL improvement for debugging. Without it, this whole class of authorization failure is completely invisible to the user.

Happy to test a patch if one lands.

[gianlucanatali]

I have been running a similar setup, Hermes Agent profiles as managed agents in Buzz Desktop, and ran into two things that might be relevant here. Both are observations from my own deployment rather than claims about yours, and the second one is really just a footnote to @iroiro147's ViaOwner explanation.

A note on the snippets below: they import Hermes' own modules, so they need the interpreter Hermes ships rather than the system python3. The launcher exports it as HERMES_PYTHON, and it survives into a terminal tool call, so inside an agent's own shell it is already there. execute_code drops it on purpose, so you would want the absolute path in that context. On a Homebrew install it is …/hermes-agent/<version>/libexec/bin/python3.

HERMES_PROFILE did not select a profile on my build

The table above gives each agent a HERMES_PROFILE env var in managed-agents.json. On Hermes 2026.8.18 I could not get that variable to select anything. _apply_profile_override() in hermes_cli/main.py takes the profile name from -p/--profile in argv or from ~/.hermes/active_profile, and does not appear to consult it. The readers of HERMES_PROFILE I found in that release all use it for attribution or scoping rather than to resolve a path: the Kanban author (kanban_db.py: "HERMES_PROFILE is the author the kanban_comment tool defaults to"), profile-scoped secret aliases, the a2a adapter's agent id, and a couple of allowlists that let the name through to a child process.

What did select the profile for me was HERMES_HOME, since a profile seems to be an independent Hermes home directory (hermes_cli/profiles.py: "Profiles live under ~/.hermes/profiles/<name>/ by default" and "Each profile is a fully independent HERMES_HOME directory").

$ env -u HERMES_HOME "$HERMES_PYTHON" -c "from hermes_constants import get_hermes_home as g; print(g())"
/Users/<user>/.hermes

$ env HERMES_PROFILE=cao "$HERMES_PYTHON" -c "from hermes_constants import get_hermes_home as g; print(g())"
/Users/<user>/.hermes          # unchanged

$ env HERMES_HOME=/Users/<user>/.hermes/profiles/cao "$HERMES_PYTHON" -c "from hermes_constants import get_hermes_home as g; print(g())"
/Users/<user>/.hermes/profiles/cao

I have not tested 0.19.1, so this may not carry over. If it does, it might be worth ruling out before digging further into the publish path, because it would mean the six agents are sharing one profile rather than having one each: the same SOUL.md, AGENTS.md, memory bank, sessions database and state.db. Not necessarily the default one, either. With HERMES_HOME unset and no -p, the name comes from ~/.hermes/active_profile, so whichever profile is sticky-active would be the one they all get. The first command above, run on your own build, would tell you either way.

For what it is worth, a full-tree grep of block/buzz at main finds no reference to HERMES_PROFILE or HERMES_HOME in 4396 files, which I read as Buzz passing the variable through verbatim rather than translating it into -p.

One thing that caught me out after switching to HERMES_HOME: the value is used verbatim, with no home expansion (hermes_constants._hermes_home_from_env does return Path(val)). A ~ stays a literal character and you get a relative path that does not exist, rather than a fallback to anything:

$ env HERMES_HOME='~/.hermes/profiles/cao' "$HERMES_PYTHON" -c "…"
PosixPath('~/.hermes/profiles/cao')   exists: False

Where the CLI stops short of the owner fallback

On my relay, which runs BUZZ_REQUIRE_RELAY_MEMBERSHIP=true and BUZZ_ALLOW_NIP_OA_AUTH=true, agents created in Desktop do seem to be admitted through ViaOwner without a relay_members row of their own. What I have to go on is the delegation the relay materialises. On a closed relay like mine, materialize_nip_oa_owner is reached only after check_relay_membership has returned ViaOwner. I mention the qualifier because on an open relay the same column gets written by a backfill path that never makes a ViaOwner decision, so if your relay is open this column would prove less than it does here:

buzz=# select left(encode(u.pubkey,'hex'),12) as agent,
buzz-#        left(encode(u.agent_owner_pubkey,'hex'),12) as owner,
buzz-#        m.role as relay_role
buzz-#   from users u
buzz-#   left join relay_members m on m.pubkey = encode(u.pubkey,'hex')
buzz-#  where u.agent_owner_pubkey is not null
buzz-#  order by u.created_at;
    agent     |    owner     | relay_role
--------------+--------------+------------
 95d6d7c3ff84 | 067e67f51029 |
 a49b3d75f218 | 067e67f51029 |
 20989bf3ba55 | 067e67f51029 |
 5127718553e0 | 067e67f51029 |
 4f81d553bf5a | 067e67f51029 |
 8cddb5023d72 | 067e67f51029 |
 b17404be6a76 | 067e67f51029 |
 cdccd8a55f72 | 067e67f51029 | member
 1714cb82d8c3 | 067e67f51029 |
 b62197ce4ddf | 067e67f51029 |
 42dc2cd4e08d | 067e67f51029 |
(11 rows)

067e67f5… is the relay owner and is itself in relay_members, which is what the fallback wants. Ten of the eleven delegated agents have no row of their own. The eleventh has one only because I added it by hand while debugging, before I understood the fallback was already covering it. So on this deployment the mechanism looks like it is doing its job for the harness, which holds the attestation in its own process environment.

The CLI behaves differently, and what surprised me is that the relay never refuses it. It never hears from it. On the terminal path Hermes strips messaging credentials from every sandboxed child, and its passthrough allowlist refuses that class of variable rather than merely omitting it, from a skill declaration and from config.yaml alike, logging "refusing to register" at both call sites. The source attributes the guard to the bypass in GHSA-rhgp-j443-p4rf. Both names are on the list:

>>> from tools.env_passthrough import _is_hermes_provider_credential as p
>>> p("BUZZ_PRIVATE_KEY"), p("BUZZ_AUTH_TAG")
(True, True)

So the CLI runs with neither the key nor the attestation and exits locally, before any HTTP request. From my agent's own log, a tool call that tried to publish:

2026-08-24 14:36:23,293 WARNING agent.tool_executor: Tool terminal returned error (0.14s):
  {"output": "{\"error\":\"auth_error\",\"message\":\"auth error: BUZZ_PRIVATE_KEY is required
   (use --private-key or set env var)\",\"retryable\":false}", "exit_code": 3}

Reproducible outside the agent by stripping the same variables:

$ env -u BUZZ_PRIVATE_KEY -u BUZZ_AUTH_TAG buzz mem ls
{"error":"auth_error","message":"auth error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var)","retryable":false}
$ echo $?
3

That might matter for diagnosis: if replies never arrive and you go looking for a 403 on the relay, there may be nothing to find, because nothing was sent. Your own report has this line for LucasBot_Finance, which is why I wondered whether it belongs apart from the publish path rather than inside it:

Tool terminal error: auth_error: BUZZ_PRIVATE_KEY is required

There is a second error, though I doubt you would meet it by default. Buzz sets both BUZZ_PRIVATE_KEY and BUZZ_AUTH_TAG itself and Hermes strips both together, so an agent normally has neither. Only once the key arrives some other way does the missing attestation surface on its own:

$ env -u BUZZ_AUTH_TAG buzz mem ls        # key supplied by other means
{"error":"user_error","message":"owner pubkey required (set BUZZ_AUTH_TAG with a NIP-OA attestation or pass --owner)","retryable":false}

For the fallback to fire, three things have to line up, and two of them caught me out:

1. state.config.allow_nip_oa_auth must be on. BUZZ_ALLOW_NIP_OA_AUTH defaults to false (crates/buzz-relay/src/config.rs, with a unit test asserting the default), so on a stock closed relay it would never run even with a perfect attestation.
2. The owner named by the attestation has to be a relay member itself (is_relay_member(community, &owner_hex) before returning ViaOwner).
3. The attestation has to reach the request, and the transport decides how. On the HTTP bridge it is the x-auth-tag header; on the websocket it comes from the signed AUTH event's auth tag instead.

I worked around the CLI half locally with a launcher in front of it that supplies the identity and the attestation from a file inside the agent's own profile, and only when the calling process carries none, so the gateway path stays untouched. Happy to write that up separately if it would help, though it is a workaround for the seam rather than a fix for either side.

Environment: macOS 26.5.2 (arm64), Hermes Agent 2026.8.18, self-hosted relay ghcr.io/block/buzz:main, agents driven over ACP with the Hermes Agent harness.

[iroiro147]

@gianlucanatali Useful additions, and thank you for separating your own observations from claims about the reporter's setup — that distinction is doing real work in a thread with three different deployments in it.

On the footnote to the ViaOwner explanation: agreed, and the HERMES_PYTHON detail generalises past Hermes. Any agent whose modules need the interpreter it ships rather than the system one hits the same wall, and the reason it looks inconsistent is that the launcher's environment survives into a terminal tool call but not into a GUI-launched probe. That is the same shape as the #!/usr/bin/env node-under-nvm case @jyrialeksi confirmed on #4350, which suggests the general statement is about GUI launch context rather than about any one runtime.

Nothing needed from me on this thread that I can see — but if the ViaOwner note reads as wrong rather than incomplete anywhere, say so and I will correct it rather than leave it standing.

[pedrosimao]

I did run into the same limitation.
On the Buzz desktop app, it would be nice to have an option / field where we can choose the name of the hermes profile we are targeting. This would be an hermes specific setting and not be available for other agents like claude, or codex.