Reproduction
A scheduled workflow in a channel contains a normal agent mention:
steps:
- action: send_message
text: "@OMP perform the scheduled check"
The channel member is the agent named OMP, but its Nostr user profile has display_name: "OMP-Mac" (the platform-created runtime/profile label). The workflow is accepted and the relay posts the kind:9 message, but it contains no p tag for the agent:
- text contains
@OMP
- event contains
buzz:workflow=true
- event contains the channel
h tag
- event is relay-signed
- event has no
p=<OMP pubkey>
ACP agent wake is p-tag gated, so the agent never receives the workflow task and no result is produced. This reproduced on a hosted channel on 2026-08-09.
Root cause
crates/buzz-relay/src/workflow_sink.rs::resolve_mention_pubkeys resolves workflow text against users.display_name only. It has no awareness of the agent's configured/canonical name. Interactive client mention composition resolves an agent selection into a pubkey, but workflow YAML stores only free text and re-parses it later, so @OMP and OMP-Mac drift apart.
This is related to #2686 (workflow sink has a divergent mention parser), but is a distinct identity-resolution failure: even plain @Name text at a valid boundary fails when the configured agent name differs from its profile display name.
Expected behavior
A workflow addressed to the channel agent's canonical name should emit the same p tag as an interactive mention and wake that agent, regardless of a runtime/profile display-name suffix.
Suggested direction
Use one canonical mention-resolution service for both interactive composition and workflow execution. For workflow text, resolve exact channel-scoped aliases from both:
- the user display name; and
- the agent's configured/canonical name.
Keep the current fail-closed behavior for ambiguous aliases: if an alias maps to multiple pubkeys, emit no p tag and return a visible workflow validation/error result instead of silently posting an unwakeable task. Add regression coverage for agent name != profile display_name, including OMP / OMP-Mac.
Reproduction
A scheduled workflow in a channel contains a normal agent mention:
The channel member is the agent named
OMP, but its Nostr user profile hasdisplay_name: "OMP-Mac"(the platform-created runtime/profile label). The workflow is accepted and the relay posts the kind:9 message, but it contains noptag for the agent:@OMPbuzz:workflow=truehtagp=<OMP pubkey>ACP agent wake is
p-tag gated, so the agent never receives the workflow task and no result is produced. This reproduced on a hosted channel on 2026-08-09.Root cause
crates/buzz-relay/src/workflow_sink.rs::resolve_mention_pubkeysresolves workflow text againstusers.display_nameonly. It has no awareness of the agent's configured/canonical name. Interactive client mention composition resolves an agent selection into a pubkey, but workflow YAML stores only free text and re-parses it later, so@OMPandOMP-Macdrift apart.This is related to #2686 (workflow sink has a divergent mention parser), but is a distinct identity-resolution failure: even plain
@Nametext at a valid boundary fails when the configured agent name differs from its profile display name.Expected behavior
A workflow addressed to the channel agent's canonical name should emit the same
ptag as an interactive mention and wake that agent, regardless of a runtime/profile display-name suffix.Suggested direction
Use one canonical mention-resolution service for both interactive composition and workflow execution. For workflow text, resolve exact channel-scoped aliases from both:
Keep the current fail-closed behavior for ambiguous aliases: if an alias maps to multiple pubkeys, emit no
ptag and return a visible workflow validation/error result instead of silently posting an unwakeable task. Add regression coverage foragent name != profile display_name, includingOMP/OMP-Mac.