Summary

Harden the Agent-to-Agent handoff lifecycle by replacing fragile string-based REPLY_SKIP logic with structured tool
parameters and ensuring thread context (Reply-Chains/Topics) is preserved during the automatic "Announce" turn.

Problem to solve

Current "Autonomous Mesh" workflows (using sessions_send + REPLY_SKIP + announce) suffer from two critical failure modes:

1. Atomicity Fragility vs Conversational Chatter: While OpenClaw correctly ignores blocks, the requirement
   for REPLY_SKIP to be the entire conversational response is extremely fragile. Many LLMs naturally include status
   confirmations or emojis (e.g., "🎯 Result received", "Success", "Delegation complete") before or after the keyword.
   Any leading or trailing text causes the gateway to treat the response as a standard message, delivering "REPLY_SKIP"
   to the user or the sub agent and killing the internal "Announce" loop entirely.
2. Thread Context Loss: In Telegram DMs where threads are simulated via reply-chains (using message_id), the automatic
   Agent-to-agent announce step. turn is treated as a fresh internal turn. It loses the reply_to_message_id metadata,
   resulting in synthesized reports being delivered to the "All Messages" chat base instead of the active thread.

Proposed solution

1. Structured sessions_send Callbacks: Add an optional action parameter to the sessions_send tool.
   • action: "skip": Directly triggers the internal "Announce" loop on the requester session without requiring the
     agent to output a magic string. This bypasses the fragility of conversational acknowledgments.
2. Context Inheritance: Ensure the Agent-to-agent announce step turn automatically inherits the channel, target, and
   message_thread_id (or reply_to_message_id) of the session that originally called sessions_spawn.
3. Explicit Routing Overrides: Allow sessions_send to accept announceTarget and announceThreadId parameters to give
   agents (or the system) definitive control over where the final synthesis is delivered.

Alternatives considered

• Prompt Engineering: Instructing agents to use REPLY_SKIP atomically is inconsistent across models and frequently fails
  as models naturally attempt to be "helpful" by confirming data receipt.
• Manual Tool Invocation: Forcing agents to use the message tool for final delivery (workaround) works but is verbose,
  requires the agent to parse its own session key for metadata, and duplicates logic already intended for the "Announce"
  step.

Impact

• Affected: All users leveraging autonomous sub-agent orchestration, tested on Telegram but may be beneficial for other platforms that uses topics / threads.
• Severity: Medium-High (Blocks consistent "Silent" sub-agent execution).
• Frequency: High (Occurs in every handoff lifecycle where a thread or conversational model is involved).
• Consequence: Broken routing loops, "All Messages" chat pollution, and failed automated syntheses.

Evidence/examples

Observed log during context loss:

1 2026-03-03T19:18:44.161Z info [agent:nested] session=agent:main:main:thread:XXXXX:16782 channel=webchat ✅ K0RE-2
Handoff — SUCCESS
2 // Gateway missed the thread ID and defaulted to webchat/base chat because the turn originated internally.

1 Agent: 🎯 Result received. REPLY_SKIP
2 // Gateway fails to detect SKIP due to leading status text and emoji.

Additional information

This improvement would directly support the goals of the multi-agent/sub-agent workflow discussed in related issues
(e.g., #27445). Preserving backward compatibility for the legacy REPLY_SKIP string is recommended while prioritizing the
structured action parameter.