RFC: [slack].streaming toggle to disable live streaming (send-once mode)

[dogzzdogzz]

Proposal

Problem

The Slack adapter always streams replies live — native streaming
(chat.startStream + assistant.threads.setStatus) when assistant_mode is on,
or a post+edit placeholder otherwise. This is great UX for a single bot, but in
multi-agent threads (several openab bots, or openab alongside other Slack bots in
one channel) it has a sharp edge.

Consider a thread with two bots:

1. user → bot A
2. bot A → bot B (bot A's reply @-mentions bot B)
3. bot B → bot A

At step 2, no other bot has posted in the thread yet, so bot A still treats it
as a single-bot thread and streams its reply via post+edit. Each edit emits a
message_changed event → bot B's app_mention re-fires once per edit, so bot B
responds to intermediate/partial states instead of bot A's single final message.

The existing other_bot_present gate only disables streaming after another bot
has posted — it cannot help on the kickoff message that first mentions bot B. There
is no way for an operator to deterministically opt a deployment into send-once
behaviour.

[gateway] already exposes a streaming switch (defaults false). Slack has no
equivalent.

Proposed shape

Add one optional boolean to [slack], default true (preserves current behaviour):

[slack]
streaming = true     # default — live streaming, as today
# streaming = false  # always post a single final message (send-once)

When streaming = false:

• No native streaming (no chat.startStream / streamed assistant.threads.setStatus).
• No post+edit placeholder.
• The adapter posts exactly one final chat.postMessage per turn.
• Independent of assistant_mode — the assistant status API (reaction / set-status)
  is unaffected; only the message streaming path is gated.

Mirrors [gateway].streaming in concept; the default deliberately differs (true
for Slack to preserve the current streaming UX, vs false for gateway).

Key behaviour

• Gating points: use_streaming() and uses_native_streaming() both AND-in the new flag.
• assistant_mode status / reactions are unaffected by the switch.
• Default true → zero behaviour change for existing deployments.

Open questions

1. Naming: streaming (mirrors gateway) vs something more explicit like
   live_streaming / send_once?
2. Scope: Slack-only for now, or land the same toggle on Discord for symmetry?
   (Discord has no post+edit streaming, so the multi-agent concern is Slack-specific.)
3. Default: keep true (current behaviour) — confirming that's the preferred default.

I have a working implementation + tests for the Slack side and am happy to open a
PR if the shape looks good.

---

Update (2026-06-18)

Beyond the streaming toggle, PR #1115 also introduces send-once narration trimming — only the final answer block (text after the last tool call) is delivered, dropping inter-tool narration. Per maintainer discussion this is controlled by a dedicated narration_display flag (default false), decoupled from streaming, and implemented in the shared adapter layer so it applies to any send-once turn (not just Slack). Supersedes the per-backend filters in #1030 / #1032.

[github-actions]

⚠️ This issue is missing the following required information and will not be processed until completed:

• Use Case

Please edit this issue to fill in the missing fields. Thank you!

Tip: Use headings like ## Description or ### Description — common synonyms (e.g. ## Problem, ## Reproduction, ## Motivation) are also accepted.

[CHC-Agent]

Issue at a Glance

  User → Bot A → Bot B (multi-agent thread)
    │       │
    │       ├─ post+edit streaming (no other bot posted yet)
    │       │       │
    │       │       ├─ edit₁ → message_changed → Bot B fires app_mention
    │       │       ├─ edit₂ → message_changed → Bot B fires app_mention (again!)
    │       │       └─ editₙ → ...
    │       │
    │       └─ WITH [slack].streaming = false:
    │               └─ single chat.postMessage → Bot B fires once ✓

Hi @dogzzdogzz,

This RFC proposes a [slack].streaming toggle (default true) to let operators opt into send-once mode, preventing the message_changed re-fire storm that breaks multi-agent threads. The design mirrors [gateway].streaming in concept.

Related:

• bug(slack): app_mention re-fires for every edit state → duplicate agent turns (phantom turns) #1103 by @dogzzdogzz — CLOSED (debounce app_mention edit re-fires)
• bug(slack): streaming not disabled in multi-bot threads — wrong cache key in handle_message #556 by @antigenius0910 — CLOSED (streaming not disabled in multi-bot threads)
• bug(discord): streamed responses post empty MESSAGE_CREATE then MESSAGE_UPDATE patches — receiver bots in multi-bot threads silently miss them #990 by @brettchien — OPEN (Discord variant of the same multi-bot streaming issue)
• PR feat(slack): add [slack].streaming toggle (send-once mode) #1115 by @dogzzdogzz — OPEN (implementation of this RFC)
• PR feat(discord,slack): per-thread streaming based on multibot detection #535 by @chaodu-agent — MERGED (per-thread streaming based on multibot detection)

PR #1115 is already open with the implementation. Maintainer review welcome.