Workflow `@mentions` silently fail to notify when two channel members share a display name — no `p` tag, no warning, no log line

[juddkussrow]

Summary

When a channel contains two members with the same display name, a workflow's
send_message containing @Name resolves to nothing: the posted event carries no
p tag for the intended agent, so the agent is never notified and never wakes.

The message still posts and looks completely correct in the channel. There is
no error, no warning at any point, and nothing in the harness log — the agent
simply never responds.

I understand ambiguous @Name being treated as presentation-only is intended
(buzz messages send --help documents it). The problem is that nothing surfaces
it, and the Desktop UI permits the situation that triggers it.

Reproduction

1. Create an agent named Probe, add it to a channel, start it.
2. Ensure a second member with display name Probe is in the same channel —
   in my case a stale identity from an earlier agent, which the UI listed happily
   as a second Probe · agent. (With the built-in agents you get this for free:
   sign out and back in once, and there are two of each.)
3. Create a workflow that posts @Probe <something> on a message_posted
   trigger.
4. Fire the trigger.

Result: the workflow posts. The agent does nothing — no reaction, no turn, no
log entry. Verified over 24s, 64s, and again after a full application restart.

Then remove the duplicate member and repeat step 4 — the agent responds within
9 seconds.

(The agent's respond_to was set to anyone throughout both halves of this test,
via the managed-agents.json workaround for #2501 — a workflow posts under its own
pubkey, so that setting is separately required. It was not the variable here: it
was identical before and after, and only the duplicate member changed.)

The difference is visible only in the event tags

Same workflow, same text, same channel — before and after removing the duplicate:

# two members named "Probe"
WORKFLOW  p=['3cd8a94f…']                 @Probe PROBE-3-PAYLOAD …    ← owner only; agent never notified

# one member named "Probe"
WORKFLOW  p=['3cd8a94f…', '8d241e8e…']    @Probe PROBE-3-PAYLOAD …    ← agent tagged; wakes in 9s

The only way to tell the two apart is to query the relay and inspect the p tags.
Nothing in the Desktop UI, the channel view, or the harness log distinguishes
them.

Why this is worth guarding

This is the sole mechanism by which a workflow can reach an agent — workflows
cannot invoke agents directly (per ARCHITECTURE.md, that bridge exists only in
buzz-acp), so an @mention is the only route. A silently-dropped mention means
the workflow appears to run correctly while doing nothing at all.

It is also not something the user has to do wrong. Buzz produces this state on
its own: each sign-out/sign-in cycle re-provisions the built-in agents with new
keypairs while leaving the previous ones in the channel. After three cycles one of
my channels held nine bot members under three display names — so @Bumble there
now notifies nobody, silently. Filed separately as a companion issue; that one is
the cause, this one is why it's invisible.

Diagnosing it took several hours and required eliminating agent state, channel
membership, authentication, and permissions (#2501) first, because none of those
produce a distinguishable symptom either.

Suggested fixes, cheapest first

1. Log it. One WARN from the workflow engine — @Name ambiguous in channel X, N matches, no notification sent — would make this a two-minute diagnosis.
2. Warn at workflow save. The channel is known at creation time; an @Name
   in a step's text that matches 0 or ≥2 members could be flagged in the editor.
3. Warn on duplicate display names when adding a member/agent to a channel.
4. Consider allowing a workflow step to target a pubkey explicitly, the way
   buzz messages send --mention <pubkey> already does. That would make
   workflow → agent routing robust regardless of naming.

Point 4 would be the real fix for automation: names are a human affordance, and
a workflow shouldn't depend on them being unique.

Environment: Buzz Desktop v0.5.3, macOS, hosted community, Claude Code harness.
Happy to provide the full before/after event dumps.

[juddkussrow]

Companion issue now filed as #4815 — that's the mechanism that produces the duplicate display names this issue fails silently on. Buzz re-provisions the built-in agents with new keypairs on every sign-in, so the ambiguous state arises without any user error.