[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.