feat: Slack adapter — bring agent-broker to Slack workspaces

[chaodu-agent]

Summary

Add a Slack adapter to agent-broker, allowing teams to interact with ACP-compatible agents (Kiro CLI, Claude Code, Codex, Gemini) directly from Slack channels and threads.

Motivation

• agent-broker currently supports Discord only (via serenity), with a Telegram adapter proposed in feat: Telegram adapter — session lifecycle, memory compaction & crash recovery #86
• Many engineering teams use Slack as their primary communication tool
• Supporting Slack would significantly expand the user base and enable enterprise adoption

Proposed Architecture

┌──────────────┐  Slack Events API  ┌──────────────┐  ACP stdio    ┌──────────────┐
│   Slack      │◄──────────────────►│ agent-broker │──────────────►│  coding CLI  │
│   User       │                    │  (Rust)      │◄── JSON-RPC ──│  (acp mode)  │
└──────────────┘                    └──────────────┘               └──────────────┘

Adapter Abstraction

To support multiple platforms cleanly, agent-broker should introduce a ChatAdapter trait:

#[async_trait]
trait ChatAdapter {
    async fn start(&self, pool: Arc<SessionPool>) -> Result<()>;
    async fn send_message(&self, channel: &str, content: &str) -> Result<()>;
    async fn edit_message(&self, channel: &str, msg_id: &str, content: &str) -> Result<()>;
    async fn create_thread(&self, channel: &str, title: &str) -> Result<String>;
    async fn add_reaction(&self, channel: &str, msg_id: &str, emoji: &str) -> Result<()>;
}

Discord, Telegram (#86), and Slack would each implement this trait. The session pool and ACP layer remain unchanged.

Slack-Specific Design

Feature	Slack Implementation
Trigger	@mention in allowed channels
Threading	Slack native threads (reply_broadcast optional)
Streaming	Edit message in thread every ~1.5s (same as Discord)
Reactions	Slack emoji reactions for status (👀→🤔→🔥→✅)
Auth	Slack Bot Token + App-Level Token (Socket Mode)
Channel allowlist	Slack channel IDs in allowed_channels

Config Example

[slack]
bot_token = "${SLACK_BOT_TOKEN}"
app_token = "${SLACK_APP_TOKEN}"       # for Socket Mode
allowed_channels = ["C1234567890"]

[agent]
command = "kiro-cli"
args = ["acp", "--trust-all-tools"]
working_dir = "/home/agent"

Connection Mode Options

1. Socket Mode (recommended) — no public URL needed, works behind firewalls, similar to Discord Gateway WebSocket
2. Events API + HTTP — requires a public endpoint, more complex but supports higher scale

Socket Mode is the natural fit since it mirrors how the Discord adapter works (persistent WebSocket connection).

Implementation Steps

1. Abstract ChatAdapter trait from current Discord implementation
2. Refactor Discord handler to implement the trait
3. Implement Slack adapter using slack-morphism or similar Rust Slack SDK
4. Add config section for Slack ([slack] block)
5. Select adapter at startup based on which config section is present
6. Add Dockerfile variant and Helm values for Slack deployment

Slack Bot Permissions (Scopes)

• app_mentions:read — detect @mentions
• chat:write — send messages
• channels:history — read channel messages
• reactions:write — add emoji reactions
• channels:read — list channels for validation

Related

• feat: Telegram adapter — session lifecycle, memory compaction & crash recovery #86 — Telegram adapter (same multi-platform direction)
• [Doc] Add docs/github-webhook-integration.md - GitHub Webhook to Discord Agent Trigger Pattern #83 — GitHub webhook integration (external event sources)
• [Security] Empty allowed_channels should not default to allowing all channels #91 — Empty allowed_channels security (applies to Slack adapter too)

[chaodu-agent]

Hi @chaodu-agent,

Good proposal — Slack is a natural next platform for openab. The ChatAdapter trait abstraction is the right approach.

This should be coordinated with PR #94 (multi-platform adapter RFC) and #86 (Telegram adapter) to ensure a consistent adapter interface across all platforms. We'd like to discuss the overall multi-platform architecture with the team first before committing to individual platform implementations.

Community inputs welcome.

[dogzzdogzz]

I've submitted a PR implementing the Slack adapter: #259

What's included

• ChatAdapter trait + AdapterRouter — platform-agnostic abstraction extracted from discord.rs, with shared session routing, streaming, reaction logic
• SlackAdapter using Socket Mode (WebSocket, no public URL needed) with auto-reconnect
• DiscordAdapter — refactored existing Discord to implement the same trait (no behavior change)
• Shared media.rs — image resize/compress and STT transcription shared across adapters
• Multi-adapter support — Discord + Slack can run simultaneously in one process, sharing a single SessionPool with namespaced session keys (discord:xxx, slack:xxx)
• Thread follow-ups without re-mention (parity with Discord)
• Slack user name resolution via users.info API
• File attachments — images and audio processed through the same pipeline as Discord

Slack setup

1. Create Slack app → enable Socket Mode → generate App-Level Token (xapp-...)
2. Subscribe to bot events: app_mention, message.channels, message.groups
3. Bot scopes: app_mentions:read, chat:write, channels:history, groups:history, channels:read, groups:read, reactions:write, files:read
4. Add [slack] section to config.toml
5. Invite bot to channel, @mention to start

Re: method A vs B discussion

This implementation supports both — config with only [slack] runs Slack-only (method A), config with both [discord] and [slack] runs simultaneously (method B). The technical concerns raised about method B (locking, blocking, connection timeouts) are addressed:

• Each adapter runs in an independent tokio task — no cross-platform blocking
• SessionPool uses RwLock with platform-prefixed keys — microsecond-level lock contention
• Each adapter manages its own WebSocket connection independently

Feedback welcome!