Summary

When Slack's "Agents & Assistants" feature is enabled, bot DM messages arrive with thread_ts (assistant thread context). The first agent response correctly replies within the same thread. However, when a subagent completes and the main agent relays the result, the thread_ts is lost — causing the result to appear as a new top-level message or new assistant thread instead of a reply in the original conversation thread.

This breaks conversation continuity in orchestrator patterns where a main agent delegates to specialist sub-agents and reports results back to the user.

Root Cause Analysis

Three compounding issues:

1. replyToMode: "first" consumes thread_ts on first reply

createReplyReferencePlanner in src/auto-reply/reply/reply-reference.ts marks hasReplied=true after the delegation acknowledgment. Subsequent responses (subagent results) receive undefined from nextThreadTs() because isSingleUseReplyToMode("first") returns true and hasReplied is already set.

Even with replyToMode: "all", the subagent result is processed as a new turn with a fresh replyPlan that has no incomingThreadTs.

2. removeThreadFromDeliveryContext strips stored threadId

In the session store (src/sessions/store.ts), when a subagent result updates the session without an explicit threadId in the delivery context, removeThreadFromDeliveryContext() deletes the previously stored thread context:

// store.ts - session update logic
const merged = mergeDeliveryContext(
  mergedInput,
  explicitThreadValue == null
    ? removeThreadFromDeliveryContext(deliveryContextFromSession(existing))  // ← strips threadId
    : deliveryContextFromSession(existing)
);

3. Subagent result turns lack original thread_ts

When a subagent completes, the gateway processes the result as a new agent turn. The new createSlackReplyDeliveryPlan receives no incomingThreadTs (since it's an internal event, not a Slack inbound message), so nextThreadTs() returns undefined.

Workaround

We implemented a globalThis cache that preserves the DM thread_ts across turns:

On inbound (provider): cache thread_ts for DM channels

if (incomingThreadTs && isSlackDirectMessageChannel(message.channel)) {
    globalThis.__openclaw_dm_thread_cache = globalThis.__openclaw_dm_thread_cache || {};
    globalThis.__openclaw_dm_thread_cache[message.channel] = incomingThreadTs;
}

On outbound (send): restore cached thread_ts when missing for DM channels

if (!params.threadTs && params.channelId?.startsWith("D") && globalThis.__openclaw_dm_thread_cache?.[params.channelId]) {
    params = { ...params, threadTs: globalThis.__openclaw_dm_thread_cache[params.channelId] };
}

Additionally, removeThreadFromDeliveryContext call was bypassed to preserve stored threadId in session context.

Proposed Proper Fix

1. Persist thread_ts in session metadata so subagent result turns can access the originating thread context
2. Pass originating thread_ts through the subagent spawn/result pipeline so the relay response inherits the parent turn's thread context
3. Remove or condition removeThreadFromDeliveryContext to not strip threadId when the session already has a valid thread context from a previous turn

Reproduction

1. Enable "Agents & Assistants" in Slack App settings
2. Configure an orchestrator agent (main) with sub-agents (e.g., specialist workers)
3. Send a DM to the bot requesting a task that requires subagent delegation (e.g., "Ask Lee to summarize recent bugs")
4. Expected: Main agent's delegation acknowledgment AND final result report both appear in the same assistant thread
5. Actual: Delegation acknowledgment appears in the thread, but the subagent result appears as a new top-level message

Environment

• OpenClaw: v2026.4.8 (also affects v2026.4.5, v2026.4.7)
• Platform: macOS (local gateway mode)
• Slack: Socket Mode with Agents & Assistants enabled
• Agent pattern: Multi-agent orchestration with sessions_spawn