# Bug: a non-owner channel member cannot mention an agent — no autocomplete, and a typed mention is never delivered

**Reported by:** MC (self-hosted Buzz)
**Date observed:** 2026-08-16
**Severity:** High for multi-user communities — agents are effectively unusable by anyone except their owner.

## Summary

In a channel containing an owner, a second human member, and an agent, the **agent can mention
the second human successfully**, but the **second human cannot mention the agent**:

- the agent's name never appears in the mention autocomplete for that user, and
- a manually typed mention posts as an ordinary message and never reaches the agent —
regardless of capitalisation.

The message appears completely normal in the channel. There is no error, no warning, and no
visible indication that the mention was not delivered. The agent simply never responds, which
reads to a user as "the agent is ignoring me."

## Environment

- Buzz Desktop + self-hosted relay (`ghcr.io/block/buzz:main`)
- Windows 11
- Participants: owner (`MC`), non-owner member (`Xavier`), Desktop-managed agent (`Socrates`)
- Agent config at time of test, read from the agent's own harness log:
`respond_to=allowlist(2)` — the allowlist contains Xavier's pubkey and one other — and
`subscribe=Mentions`

## Steps to reproduce

1. Create a channel with the owner, a second human member, and a managed agent.
2. Add the second human's pubkey to the agent's inbound allowlist. Confirm the agent boots
with `respond_to=allowlist(N)` including that pubkey.
3. As the **agent**, mention the second human. → works.
4. As the **second human**, try to mention the agent.

## Observed

| direction | result |
|---|---|
| agent → non-owner human | **works** — agent reported "signed event confirms Xavier's pubkey was included" |
| non-owner human → agent | **fails** |

For the failing direction, all three of the following were observed:

1. Typing `@` does **not** offer the agent in the suggestion list. It never appears.
2. Manually typing `@socrates` (lowercase) — message posts, no reply.
3. Manually typing `@Socrates` (exact display name, correct case) — message posts, no reply.

The agent confirmed independently, when prompted by the owner, that the second human **is** in
the channel member list: *"Xavier is in this channel. I confirmed the current member list,
which includes Xavier, MC, and me."* So this is not a membership problem.

## Expected

The agent should appear in the mention autocomplete for any channel member, and a mention
typed by any member should be delivered to it.

## Mechanism — inference, not yet verified

Mentions are delivered by a pubkey tag on the event, not by the message text. The agent runs
`subscribe=Mentions`, so it only wakes for events carrying its key. The most likely explanation
is that the client, when composing as a non-owner, **does not attach the mention tag** for an
agent member — so from the relay's point of view nobody was mentioned, and the agent is never
notified.

**This is reasoning, not evidence.** It can be confirmed in one step by inspecting the raw
event for the failing message and checking whether it carries a `p` tag for the agent's pubkey.
If the tag is absent, the fault is client-side composition. If the tag is present, the fault is
downstream in delivery or in the agent's inbound gate.

## Impact

- Agents are unusable by any community member other than their owner, even when explicitly
allowlisted. The allowlist feature cannot be exercised by the people it is meant to permit.
- The failure is **silent**. The message posts normally, so a user has no way to tell the
mention did not register, and will reasonably conclude the agent is broken or ignoring them.
- Owner-side testing will not reproduce it, because owner mentions work — which makes this easy
to miss.

## Suggested fix

Populate the mention autocomplete with agent members for all channel members, not only the
owner, and attach the mention tag on send regardless of who is composing. Failing that, surface
a visible warning when a typed `@name` does not resolve to a member, rather than silently
posting it as plain text.

## Related

Filed separately: Desktop's `respond_to` change saving to the definition record but never
propagating to the runtime record. That bug is distinct — it was fixed by hand before this test,
and the agent in this report was verified booting with the correct allowlist.

Start by inspecting the raw event for a failing non-owner message and check whether it contains a p tag for the agent's pubkey. Then trace the Desktop mention autocomplete and send paths, comparing owner and non-owner composition; done means the agent appears for every channel member and typed mentions are delivered.

Written by the indexing model from the issue text.