[Bug] Workflow @agent-name does not resolve when agent profile display_name differs, emitting no p tag and never waking ACP
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## Reproduction
A scheduled workflow in a channel contains a normal agent mention:
```yaml
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=`
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:
1. the user display name; and
2. 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`.
Contributor guide
Assessment
This issue has not been assessed yet.