Summary
When Agent A @mentions Agent B and B is offline (stopped/not running), the mention is silently lost. No warning is shown to A, to the channel, or to any human observer. B never wakes up or catches the missed mention.
From the sending agent's perspective, this is a silent black hole. The agent has no way to:
- Check if the target is online before mentioning
- Detect that the mention was not delivered after sending
- Set a timeout or retry — there is no delivery receipt or acknowledgment protocol
This means any agent workflow that delegates to another agent via @mention is inherently fragile when the target may be offline. The sending agent will wait indefinitely with no recourse.
Steps to Reproduce
- Have a channel with two agents — e.g. "Alice" and "Bob"
- Stop/ensure Bob is not running
- Have Alice send a message that @mentions Bob (includes a
p tag with Bob's pubkey)
- Observe: no response from Bob, no warning or indicator anywhere
- Wait indefinitely — nothing ever happens
Expected Behavior
Either:
- A visible warning appears in the channel ("Bob is offline and may not see this mention"), OR
- The relay auto-starts Bob when it receives an @mention directed at it, OR
- At minimum, the sender receives a delivery-failure notice
Actual Behavior
Nothing. The message is stored and relayed normally but Bob never processes it. The mention silently disappears from Bob's perspective because it has no active WebSocket subscription.
Root Cause (technical)
The relay's fan-out path (dispatch_persistent_event_inner in crates/buzz-relay/src/handlers/event.rs:351-416) delivers events only to active WebSocket subscribers. When an agent is offline, it has no subscriber, so the event is never delivered to its harness.
The presence infrastructure already exists and works correctly (crates/buzz-pubsub/src/presence.rs — get_presence() / get_presence_bulk()), but it is never consulted during event dispatch. The ACP harness (buzz-acp) has no mechanism to catch up on missed @mentions after a restart beyond a small reconnect time window.
From the sending agent's side: there is no presence/status API available to check whether a target is online before sending. The relay accepts the message, returns success, and the sender cannot distinguish "delivered to a live subscriber" from "stored but nobody's listening."
Proposed Fix Directions
Four non-exclusive options, roughly ordered by reliability:
1. Relay-side notice (most reliable)
When the relay stores a message with a p tag whose recipient agent has no active WS subscription (or has no presence key in Redis), emit a system notice back into the channel — e.g. a new ephemeral event kind ("agent_mention_undelivered"). Works regardless of client type.
2. ACP harness startup catch-up
When buzz-acp reconnects, extend the since-filter to replay missed @mentions, not just recent events. Requires verifying the current reconnect window actually covers mentions sent while the harness was down.
3. Desktop UX inline warning (most visible)
When the desktop detects a message @mentioning a managed agent whose status is not "running", show an inline warning in the message or thread view: "Bob is offline and may not see this."
4. Delivery receipts / acknowledgment events
The mentioned agent's harness emits a lightweight ack event when it processes a mention. If the sender doesn't see an ack within N seconds, it surfaces a warning or retries. More complex but enables agent-to-agent reliability without requiring the relay to understand agent lifecycle.
Severity
P1 / High — breaks agent-to-agent delegation entirely when the target is offline, with no fallback or error handling possible at the agent layer. In an unattended workflow this could block indefinitely.
Related
Context
First observed in production: Agent A delegated work to Agent B; B was offline; the team waited 30 minutes before a human directly mentioned B, which caused it to start. No error, no warning, no timeout — complete silent failure.
Summary
When Agent A @mentions Agent B and B is offline (stopped/not running), the mention is silently lost. No warning is shown to A, to the channel, or to any human observer. B never wakes up or catches the missed mention.
From the sending agent's perspective, this is a silent black hole. The agent has no way to:
This means any agent workflow that delegates to another agent via @mention is inherently fragile when the target may be offline. The sending agent will wait indefinitely with no recourse.
Steps to Reproduce
ptag with Bob's pubkey)Expected Behavior
Either:
Actual Behavior
Nothing. The message is stored and relayed normally but Bob never processes it. The mention silently disappears from Bob's perspective because it has no active WebSocket subscription.
Root Cause (technical)
The relay's fan-out path (
dispatch_persistent_event_innerincrates/buzz-relay/src/handlers/event.rs:351-416) delivers events only to active WebSocket subscribers. When an agent is offline, it has no subscriber, so the event is never delivered to its harness.The presence infrastructure already exists and works correctly (
crates/buzz-pubsub/src/presence.rs—get_presence()/get_presence_bulk()), but it is never consulted during event dispatch. The ACP harness (buzz-acp) has no mechanism to catch up on missed @mentions after a restart beyond a small reconnect time window.From the sending agent's side: there is no presence/status API available to check whether a target is online before sending. The relay accepts the message, returns success, and the sender cannot distinguish "delivered to a live subscriber" from "stored but nobody's listening."
Proposed Fix Directions
Four non-exclusive options, roughly ordered by reliability:
1. Relay-side notice (most reliable)
When the relay stores a message with a
ptag whose recipient agent has no active WS subscription (or has no presence key in Redis), emit a system notice back into the channel — e.g. a new ephemeral event kind ("agent_mention_undelivered"). Works regardless of client type.2. ACP harness startup catch-up
When
buzz-acpreconnects, extend thesince-filter to replay missed @mentions, not just recent events. Requires verifying the current reconnect window actually covers mentions sent while the harness was down.3. Desktop UX inline warning (most visible)
When the desktop detects a message @mentioning a managed agent whose
statusis not"running", show an inline warning in the message or thread view: "Bob is offline and may not see this."4. Delivery receipts / acknowledgment events
The mentioned agent's harness emits a lightweight ack event when it processes a mention. If the sender doesn't see an ack within N seconds, it surfaces a warning or retries. More complex but enables agent-to-agent reliability without requiring the relay to understand agent lifecycle.
Severity
P1 / High — breaks agent-to-agent delegation entirely when the target is offline, with no fallback or error handling possible at the agent layer. In an unattended workflow this could block indefinitely.
Related
Context
First observed in production: Agent A delegated work to Agent B; B was offline; the team waited 30 minutes before a human directly mentioned B, which caused it to start. No error, no warning, no timeout — complete silent failure.