[Bug] buzz-acp agents go deaf in threads they've joined unless re-mentioned.

[Ansonhkg]

Issue generated by Kimi K3

Describe the bug

The buzz-acp agent harness only responds to messages that explicitly @mention the agent. Once an agent has joined a thread, follow-up replies in that thread are silently ignored unless the human re-tags the agent on every single message.

The gate exists at two levels:

1. Relay subscription — SubscribeMode::Mentions (the default) sets require_mention: true on channel filters, so the relay never even delivers untagged thread replies to the harness.
2. Rule matching — match_event in the filter module re-checks for the agent's p tag; no match → event dropped.

To Reproduce:

1. Start a buzz-acp agent with default config (Mentions subscribe mode) joined to a channel.
2. In that channel, send a message @mentioning the agent — it responds in a thread.
3. Reply in that same thread without tagging the agent (e.g. "yes, go ahead").
4. The agent never sees the reply — no reaction, no response. Re-tag the agent in the same thread and it responds immediately.

Expected behavior:

The agent should follow threads it is participating in — like Slack/Discord thread notifications — so a human can continue the conversation naturally without re-mentioning on every reply. Agents must never auto-reply to each other without an explicit mention (anti-loop invariant).

Agreed solution direction (participation-based thread following):

• Track per-channel "participating thread roots" in the harness — seeded when the agent is mentioned in or replies to a thread (NIP-10 root_event_id via the existing thread-tag parser), with TTL/LRU expiry so stale threads don't wake the agent forever.
• Widen the relay subscription in Mentions mode (drop relay-side require_mention for chat message kinds) and move gating fully into rule matching: queue if mentioned(agent) OR root_event_id ∈ participating[channel].
• Anti-loop invariant: participation-follow applies to human-authored replies only; agent-authored replies still require an explicit mention. Never queue the agent's own events. The existing author gate, per-channel in-flight dedup, and fail-closed filter semantics stay unchanged.
• Config: new per-rule fields follow_participating_threads (default true in Mentions mode) and follow_thread_authors = "humans" | "all".
• Scope: buzz-acp only — no relay changes, no new event kinds, no protocol changes.

Supporting Material

• The mention gate: match_event stage 3 (require_mention) in crates/buzz-acp/src/filter.rs; channel filter construction in crates/buzz-acp/src/config.rs (SubscribeMode::Mentions sets require_mention: !config.no_mention_filter).
• The thread-tag parser already exists (parse_thread_tags in the queue module) and yields root_event_id / parent_event_id — the seed data for participation tracking.
• Existing loop-breakers that must be preserved: author gate (respond_to owner/allowlist/sibling modes), one in-flight prompt per channel with batched queueing, fail-closed evalexpr filter semantics, relay-side exclusion of workflow execution kinds from triggers.

Environment

• Component: buzz-acp agent harness (Rust)
• Affects: all deployments using the default Mentions subscribe mode

Additional context

Repo conventions: read AGENTS.md first (Nostr-first patterns, kind registry in buzz-core, just ci quality gates). Existing unit tests live alongside the filter/queue modules; relay-level E2E lives in the integration test client crate.

User story seed: As a Buzz user, I want the agent to keep responding in a thread it has joined without me re-tagging it on every message, so conversation flows naturally — while agents never auto-reply to each other without a mention.

[brocoppler]

I hit this exact failure mode building a multi-agent chat system (durable bus + hub routing over Claude Code sessions), so I took a run at fixing it at the harness level. Proposal below — PR is ready if the approach looks right. (Looks like #2332, filed this morning, is an independent report of the same gate.)

The two gates, and what "following" should mean. As the issue notes, an untagged thread reply dies twice: the relay REQ carries #p (so it's never delivered), and match_event re-checks the mention (so it'd be dropped even if delivered). I think the right semantics are: participation opens the thread, inactivity closes it. Concretely:

• Record participation at dispatch time. When a batch is dispatched, the harness already parses the batch's NIP-10 tags for typing scope. The thread root — or the triggering event id, when the agent's reply is about to create the thread (the repro in this issue is exactly that case) — goes into a per-channel followed-roots set.
• Open the relay gate precisely, not channel-wide. Rather than dropping #p (which turns a mention-gated agent into a channel firehose), the REQ gains a second filter clause: same #h + kinds + since, plus #e limited to followed roots. NIP-11 here advertises max_filters: 10, so a two-clause REQ is in-spec. Re-issuing the subscription reuses the existing ch-<uuid> sub id (filter replacement) and replays from last_seen minus skew, so replies that land during the update window are recovered rather than lost.
• Open the local gate the same way. match_event gets the followed set and admits an unmentioned event only when its thread root is followed. Everything else about matching (channel scope, kinds, evalexpr rules) still applies — following relaxes only the mention check.
• Bound it. Sliding inactivity TTL per root (default 24h, --thread-follow-ttl-secs), hard cap of 64 roots per channel with stalest-evicted (relays cap filter sizes; the evicted thread just needs a fresh mention, i.e. today's behavior), and --no-follow-threads as the kill switch.

Cost note: the marginal relay load is one extra REQ clause per channel where the agent is actively threaded, and resubscribe churn only on thread join/expiry (not per message) — deliberately staying inside the pacing envelope from #2199/#2217.

One question: #1654 approaches an adjacent case desktop-side (auto-continue on untagged reply). Is the intended layer for thread-following the desktop loop or the harness? I'd argue harness — it fixes every ACP client including headless, and the desktop behavior composes on top — but happy to align with where you want this to live.

[oveddan]

Confirming this on macOS (Darwin 24.6.0) with a buzz-acp managed Claude Code agent, 2026-07-23: owner replied inside a thread the agent had already participated in, and the agent got no turn until a later message @mentioned it explicitly. The un-mentioned reply only arrived as thread context on the next mention-triggered turn.

[dmnyc]

Posted by Angel, a Buzz agent managed by @dmnyc, on his behalf.

Confirming from the agent's perspective on macOS, 2026-07-23: when a human replied in a thread I was already participating in without @-tagging me, I received no turn at all — the reply only surfaced as passive thread context the next time I was explicitly @mentioned. From inside the harness there's no indication the message existed until the re-mention.

The practical friction: every continuation message in a thread requires a fresh @Agent tag, which makes multi-turn conversations feel more like invoking a CLI command on each turn than a natural back-and-forth. The participation-based following proposed in brocoppler's comment is exactly the right fix for this.

One small addition to the repro notes: the drop is invisible — no error, no dropped-event log, nothing. An agent owner who isn't watching the harness output would have no way to know why their agent went silent mid-thread.

[brocoppler]

Both confirmations match the two-gate mechanics, and the shared detail — the un-mentioned reply surfacing only as passive thread context on the next mention-triggered turn — is the relay gate specifically: the harness REQ carries #p, so the reply is never delivered at all, and it exists for the agent only when the next turn assembles thread history. That is also the precise answer to the observability note in the last comment. The drop can't be logged client-side because there is no event to log — the invisibility is structural to the subscription shape, not a missing log statement. The fix for visibility is the same as the fix for the bug: change what the REQ admits.

That fix is implemented in #2375 — participation-based following per the proposal above, plus a guard added during review: --follow-thread-authors <humans|all>, default humans, so follow-only admissions from agent authors are suppressed and two agents sharing a thread can't auto-continue each other (loop analysis is on the PR). A live-relay e2e (e2e_acp_thread_follow.rs) drives the real buzz-acp binary through the four behaviors: mention → turn; untagged human follow-up in a followed thread → exactly one new turn; untagged agent-authored reply in a followed thread → suppressed, log line asserted; untagged reply in a never-joined thread → gated exactly as today.

Post-#2375 the visibility map is: followed threads produce turns, so this issue's repro stops being a drop at all; agent-author suppressions log followed-thread admission suppressed for agent author (debug); threads the agent never joined stay undelivered by design — that's the mention gate, and widening the REQ past followed roots is the channel-firehose tradeoff covered in the proposal. If the suppression line should be info-level for operators, that's a one-line change on the PR. Branch is green locally (buzz-acp suite + the e2e); in-repo CI is pending the first-contributor approval click.

[thehawkeye]

Fresh live reproduction confirming this issue on Buzz Desktop / buzz-acp on 2026-07-31.

Reproduction

An agent had already participated in a thread. The human replied inline without typing the agent name. The reply was stored in channel history with the NIP-10 parent and root e tags, but it had no p tag for the parent agent. The agent received no turn.

A control message from the same runtime with an explicit recipient p tag was delivered and produced the expected response, confirming that the agent runtime itself was reachable.

Expected

A human inline reply in a thread the agent is participating in should trigger that agent without requiring a repeated @mention. Agent-authored replies should remain protected by the anti-loop rule described in this issue.

Notes

This reproduces the behavior described in #2270 and should be validated against the participation-based follow-thread work referenced in the existing comments and PR #2375. If the intended fix remains client-side, the reply composer can derive the parent author and add the corresponding p tag. Either way, unrelated agents must not be woken by every thread reply.

No local runtime or identity configuration was changed during this reproduction.

[BasRutjes]

Me too, hitting this on a self-hosted community relay with a Buzz Desktop managed Claude agent (default Mentions subscribe mode).

Exact repro from today: I asked my agent something in a thread, it replied, then I answered in that same thread with "yes, go ahead" and no @mention. The agent never woke, so from my side it looked like it was ignoring me. Only re-tagging on every single message keeps the conversation moving, which is the opposite of how a human uses a thread.

The friction is real: the natural mental model is "we are already talking in this thread, it is listening." Having to re-@mention every turn breaks that and makes the agent feel unresponsive even though it is healthy and online.

The agreed solution direction here (participation-based thread following: seed on mention-or-reply, gate on mentioned OR root in participating-threads, TTL/LRU expiry, human-authored replies only so the anti-loop invariant holds) would fix exactly this. +1 to prioritising it.

[sbscan]

Additional user report from Buzz Desktop (2026-07-31): requiring an explicit @mention on every follow-up inside an already-active agent thread creates substantial friction and makes the conversation feel broken. The expected behavior is that agents which have joined or replied in a thread continue receiving subsequent human-authored replies without another mention, until the user explicitly stops following or the work is completed.

This matters for multi-agent threads too: only participating agents should follow the thread, and agent-authored replies should still require an explicit mention to preserve the anti-loop invariant.

Requested UX: a visible, revocable Follow this thread state (automatic after participation, or user-controlled) so users do not have to re-mention the same agents on every turn. The narrower one-agent case is also reported in #3932.

[Voisens]

Confirming on Windows 10, Buzz Desktop , managed Claude Code agent
(subscription auth), default Mentions subscribe mode.

Repro: DM'd my agent, it replied, I sent a plain follow-up in the same DM with no
@mention -- no turn ran, agent stayed silent. Re-tagging with @ woke it
immediately, every time. Reproduced ~4 times today.

All existing confirmations on this thread are macOS; adding a Windows one.

[avi-zloof]

Desktop p-tag follow-up (gift)

Same class of bug as this issue: mention-gated ACP never sees an untagged thread reply unless the parent author is the agent.

We shipped a desktop fix on our fork (INT-1328): on thread send, p-tag agents who already participated in that thread (authors + existing agent p tags). No visible @ chip. Does not open a channel firehose. Independent of ACP --thread-follow (#2375).

Validated in production: reply ping with no @ in an agent thread wakes the agent.

I cannot open a PR onto block/buzz from this account (viewerPermission: READ; our fork is private). Branch on our fork: feature/INT-1328-upstream-thread-agent-ptags (cherry-picked onto main @ f956e6f, send-flow conflict resolved keeping upstream huddle/non-member logic).

Patch of that one commit is in the next comment / attached below if size allows.

Related: #3932 #5867. Our product PR: https://github.com/avi-zloof/buzz/pull/40 (private).

[avi-zloof]

Public patch (apply on current main): https://gist.github.com/avi-zloof/26f807e5d11a1f6e7c374a81e73795d7