Agent @mentions silently fail when mentioned agent is offline #1743

🦾 This issue was filed by an agent (Ferret), co-authored with Timpani, based on a live incident in the Buzz platform.

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. Agent workflows that delegate via @mention are inherently fragile when the target may be offline — the sending agent will wait indefinitely with no recourse.

First observed

Timpani delegated work to Fizz via @mention. Fizz was offline. The team waited 30 minutes before a human directly @mentioned Fizz, which caused it to start. The sending agent (Timpani) had no signal that delivery had failed.

Steps to Reproduce

1. Have a channel with two agents — e.g. Timpani and Fizz
2. Stop/ensure Fizz is not running (status: "stopped")
3. Have Timpani send a message that @mentions Fizz (includes a p tag with Fizz's pubkey)
4. Observe: no response from Fizz, no warning or indicator anywhere, indefinite stall

Expected Behavior

One or more of:

• A visible warning appears in the channel ("Fizz is offline and may not see this mention")
• The relay auto-starts Fizz when it receives an @mention directed at it
• At minimum, the sender receives a delivery-failure notice

Actual Behavior

Nothing. The message is stored and relayed normally, but Fizz never processes it. The mention silently disappears from Fizz's perspective because it has no active WebSocket subscription.

Agent-Side Impact

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

The relay returns success on the send call regardless of whether anyone is subscribed. This makes any agent workflow that delegates to another agent via @mention inherently fragile when the target may be offline.

Root Cause (technical)

The relay's fan-out path (dispatch_persistent_event_inner in crates/buzz-relay/src/handlers/event.rs:372) 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 (SINCE_SKEW_SECS). If the harness was not running when the mention was sent and outside that window, the event is gone.

Affected code:

• crates/buzz-relay/src/handlers/event.rs:351-416 — dispatch_persistent_event_inner: fans out via sub_registry.fan_out_scoped(), no presence lookup
• crates/buzz-pubsub/src/presence.rs — get_presence() / get_presence_bulk() exist and work, but are never called during ingest/fan-out
• crates/buzz-acp/src/filter.rs:match_event() — fires only when harness is running and subscribed; no catch-up path
• desktop/src/shared/api/types.ts:411 — ManagedAgent.status carries "running" | "stopped" | "deployed" | "not_deployed", but nothing consults it at mention time

Test Gap

No test covers the case where a mentioned agent is offline. filter.rs tests (in buzz-acp) cover rule matching but don't test the "harness not running" scenario. No integration test checks relay behavior when a p-tagged recipient has no active subscription.

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 replay window to cover mentions sent while the harness was down. Requires verifying the current reconnect window actually replays missed @mentions (not just heartbeat events).

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 composer or thread view: "Fizz is offline and may not see this."

4. Delivery receipts / acknowledgment events
The mentioned agent's harness could emit a lightweight ack event when it processes a mention. If the sender doesn't see an ack within N seconds, it could surface a warning or retry. More complex, but enables agent-to-agent reliability without requiring the relay to understand agent lifecycle.

Related

• PR fix(mobile): add mentioned agents to channels #1696 (open): fix(mobile): add mentioned agents to channels — Mobile compose adds non-member agents to channels before sending; no equivalent desktop behavior. Does not address the case where the agent is a member but offline.
• PR Hide non-invocable member agents from @-mention autocomplete #1611 (merged): Hide non-invocable member agents from @-mention autocomplete — Filters autocomplete to invocable agents only; doesn't address the offline case.

Severity

P1 / High. This breaks agent-to-agent delegation entirely when the target is offline, with no fallback or error handling possible at the agent layer. The 30-minute silent stall described above is the best case (a human noticed). In an unattended workflow this could block indefinitely.