Summary

Allow binding an isolated/spawned agent session to a specific platform thread (Slack, Discord, etc.), so that:

• Messages posted in the thread are routed as input to the bound agent session
• Agent session output is delivered to the bound thread
• Any user (human, orchestrator, or another agent) can interact with the agent by posting in its thread

Motivation

Currently, sub-agents spawned via sessions_spawn or Temporal workflows communicate internally — output is relayed back through the orchestrator or sessions_send. There is no way to give a sub-agent a "presence" in a platform thread where humans and other agents can interact with it directly.

This creates a bottleneck: the orchestrator must relay all communication. It also means there is no real-time visibility into agent work from the chat platform.

Use case: Jira task channels

1. A Jira task is created → orchestrator creates a Slack channel (#aa-55-sentry)
2. For each phase (analysis, development, review), orchestrator creates a thread and spawns an agent bound to it
3. The agent posts its work directly in the thread
4. Humans can jump into any thread to course-correct, ask questions, or provide input
5. Other agents can post in the thread to communicate with the bound agent
6. Full visibility — everything is in Slack, searchable, real-time

Proposed design

Core: Thread-session registry

A binding map checked before default session-key routing:

{channelPlugin, channelId, threadId} → sessionKey

When a message arrives in a bound thread, route it to the bound session instead of the default agent::slack:channel:<id>:thread:<ts> key.

Spawn integration

Extend sessions_spawn (and/or Temporal workflow inputs) to accept a thread binding:

{
  "task": "Analyze the codebase",
  "agentId": "analyst",
  "threadBinding": {
    "channel": "slack",
    "channelId": "C07XXXXXX",
    "threadTs": "1707123456.789"
  }
}

Output delivery

When a bound session produces a response, deliver it to the bound thread (instead of or in addition to the spawn announcer). Could be configured per-binding:

{
  "delivery": "thread",       // output goes to thread only
  "delivery": "both",         // output goes to thread + announcer
  "delivery": "announcer"     // current behavior (default)
}

Lifecycle

• Binding is created on spawn and removed when the session ends
• Optional: auto-archive the thread on session completion
• Optional: unbind without ending session (detach)

Platform generality

This is not Slack-specific. The same pattern works for:

• Discord threads/forum posts
• Slack threads
• Feishu/Lark topic threads
• Any platform with threaded conversations

The registry should be channel-plugin-agnostic.

What this enables

• Multi-agent visibility: Watch agents work in real-time from your chat platform
• Human-in-the-loop: Jump into any agent thread to intervene
• Cross-agent communication: Agent A posts in Agent B thread → reaches B naturally
• Audit trail: Platform keeps full history, searchable
• Per-thread tools/config: Bind different tool permissions per thread/agent

Alternatives considered

• Agent polls thread via API: Wasteful, high latency, fragile
• Orchestrator relays all messages: Current approach, bottleneck, no direct interaction
• Webhook per thread: Overcomplicated, doesn't use existing session routing