Buzz/Hermes integration appears split across two failure phases: identity handoff regression (#5497) and reply publication failure (#4923)

**Suggested labels:** `bug`, `agents`, `buzz-acp`, `identity`, `relay`, `gateway`, `ui`, `investigation`

## Summary

I am reporting what appears to be a Buzz-side failure cluster affecting Hermes gateway integration.

I am not claiming final proof of one root mechanism. I am raising a serious failure pattern that the evidence strongly suggests likely caused or materially contributed to the outcome and warrants prompt investigation.

The practical result was that agents could appear alive in Buzz, receive chat, and sometimes complete local turns, while still failing to behave as reliable Hermes-integrated community participants.

## Intended setup

The intended target was always:
- Hermes native gateway mode
- Buzz used only as a shared workspace/platform surface
- not Buzz-managed ACP as the desired runtime

That distinction matters because some related Buzz issues appear ACP-specific and should be treated here as analogous or supporting evidence unless directly tied to the native gateway path.

## Two-phase pattern I observed

### Phase 1: reply transport / config / publication failure
- Early generated agents **did show the one-time key popup**.
- So the identity was at least surfaced to me at that stage.
- But those same agents still could not reply correctly.
- I directly observed agents receive chat, visibly "think" in the lower pane, formulate responses, surface errors, and in multiple runs state that they could not reply because the Buzz CLI was not configured.
- My strongest recollection is that reply delivery depended in practice on Buzz CLI availability, permissions, or related agent/channel configuration, and that this path/config could never be found or made to work correctly.

### Phase 2: identity surfacing / bootstrap / membership failure
- Later, the one-time private-key popup **stopped appearing** entirely.
- After that, failures worsened into membership/bootstrap/recognition problems:
- Hermes gateway setup membership failures
- the hosted community/relay not recognizing the agent
- agent/community state seemingly hidden on the hosted `buzz.xyz` side

These phases may overlap, but the chronology matters and should not be flattened into one bug.

## Why I think this is likely Buzz-side or Buzz-first

### 1. `#5497` appears consequential, not cosmetic

`#5497` reports that new agent private keys no longer appear during creation:

I do not treat this as merely a UI annoyance. It appears likely to sit on the critical path for Hermes-side identity reuse. If the key is not surfaced when needed, the user may lose the practical ability to carry that identity forward into Hermes gateway membership/setup. That does not by itself prove the full downstream chain, but if true it is potentially determinative and highly consequential.

### 2. `#4923` matches the "turn completes but no reply publishes" pattern

`#4923` reports that `buzz-acp` can complete a turn and stream output while never publishing the reply back to the channel:

That same issue was reportedly reproduced on non-Hermes ACP runtimes as well, which suggests this class of failure is not unique to Hermes.

### 3. Adjacent issues support the reply/publication and config theory
#2698 — silent reply drop when publication depends on buzz messages send
#5262 — managed agents may be unable to run the Buzz CLI at all under permission handling
#2717 — per-community env/config edits may land on the wrong instance or be unreachable from the UI
#3888 — membership / first-publish race on closed relays

These do not prove one single code path here. They do, however, strongly support the idea that identity surfacing, membership, CLI access, and reply publication are all active failure surfaces in the same area I was interacting with.

## Important observed distinction

There were moments when the system appeared close to working, but those states were misleading.

In testing, agents could seem active while actually behaving like Buzz-managed ACP agents that had absorbed Hermes-like personality or profile traits. From the user side, this was not a valid fallback. It was a degraded or "zombie" state because the agents did not retain the normal Hermes runtime, memory, skills, or learning behavior I was actually trying to preserve.

## Hosted relay limitation

The affected community/relay was hosted on `buzz.xyz`, which meant I could not directly inspect or repair relay-side membership state, force reconciliation, or verify hidden server-side records. That made it much harder to determine whether the issue was fully client-side, relay-side, or both.

## Why I am filing this

My role here is not to adjudicate root cause with finality, but to identify and document a serious failure pattern that likely caused or materially contributed to the outcome. The evidence is strong enough to warrant prompt investigation by those with the technical access and authority to confirm, isolate, and repair the underlying defects.

## What seems most useful for maintainers to verify

1. Whether `#5497` is only a UI regression, or whether user-visible key export/reuse failure is breaking a critical identity handoff for Hermes gateway setup.
2. Whether the Buzz CLI/config/publication path is the practical reason replies can be formulated locally but still fail to publish.
3. Whether hosted `buzz.xyz` communities expose enough status to confirm that a newly created agent identity is actually recognized as a community member.
4. Whether per-community config/env targeting is preventing fixes like Buzz CLI path injection from landing on the intended agent instance.
5. Whether the system can fall into an ACP-visible but Hermes-degraded "zombie" state that looks almost correct while actually replacing the intended gateway behavior.

## Author attestation

I am reporting this from direct operator experience across repeated retries, multiple environments, and review of the linked upstream issues and product documentation.

I have tried to separate:
- user-visible symptoms,
- runtime-visible behavior,
- verified upstream evidence,
- and hypothesis.

I am **not** claiming one confirmed root cause. I am documenting a reproducible-seeming cluster of integration failures that, taken together, strand the agent in an apparently alive but not fully operational state.

— Craig Christianson
craigwchristianson@gmail.com

No source file or test is named. Start by reproducing the native Hermes gateway setup across the two reported phases, then compare the evidence in linked issues #5497 and #4923 with the CLI/config, identity, membership, and reply-publication paths. Done means maintainers can isolate the responsible failure surface and define a focused fix.

Written by the indexing model from the issue text.