OpenAB: A Rust Broker That Puts an ACP Coding Agent Inside Your Chat

One ACP boundary, however many chat platforms you attach

OpenAB describes itself as a lightweight, secure, cloud-native ACP harness that bridges Discord, Slack and any Agent Client Protocol compatible coding CLI over stdio JSON-RPC. The architecture is the interesting part and the diagram makes it explicit. Platform adapters converge on the same dispatcher and session pool, then cross a single ACP stdio boundary to the selected agent runtime. The listed runtimes include Kiro CLI, Claude Code, Codex, Gemini, OpenCode, MiMo-Code, Kimi Code, Copilot CLI, Grok Build, Devin, Antigravity, Pi, an AWS AgentCore backed option, and a slot for a custom ACP agent. Because the boundary is fixed, swapping the agent is a configuration change rather than a rewrite, and adding a chat platform does not change how the agent is driven.

Threads as the unit of conversation, not channels

The interaction model is worth stating precisely because it differs from a plain chat bot. An @mention trigger starts a conversation: you mention the bot in an allowed channel. After that, thread-based multi-turn takes over, with threads auto-created so follow-ups need no further mention. That design keeps a channel readable, since each side discussion lands in its own thread instead of interleaving with the main channel traffic. Underneath, a session pool keeps one CLI process per thread with an auto-managed lifecycle, so a long conversation holds its agent process and a finished one releases it. There is also a directive for choosing which message to reply to, written as `[[reply_to:id]]`, which matters in multi-bot channels where a reply needs to be unambiguous. Multi-agent collaboration is supported through bot-to-bot messaging, documented separately.

Feedback while the agent is still thinking

Several features exist purely to make the wait legible. Edit-streaming live-updates the Discord message every 1.5 seconds as tokens arrive, so the channel shows progress instead of nothing. Emoji status reactions run through a small sequence as the agent moves from thinking to working to done. The protocol itself is JSON-RPC over stdio, and the feature list says it carries tool call, thinking and permission auto-reply support, so a request for permission does not stall the conversation waiting for someone to notice a prompt. Image and file sending works from chat, with separate documentation for each. Voice messages are transcribed automatically through Groq, OpenAI or a local Whisper server, which is the cheapest way to add spoken input to a text-only agent. Slash commands are built in, and scheduled messages let configuration driven cron jobs prompt the agent on a schedule.

Six more chat platforms through the gateway binary

Discord and Slack are the core adapters, and the default feature set compiles both in. Telegram, LINE, Feishu/Lark, Google Chat, WeCom and Microsoft Teams are reachable through gateway adapters, and there are two ways to run them. They can be compiled into a unified binary, or deployed as the standalone Custom Gateway in `crates/openab-gateway/`. The project is explicit that running them standalone or embedding them in a unified build does not change the ACP boundary, which is the architectural promise you would want to keep. One detail that looks trivial and is not: the platform-edge labels distinguish inbound delivery from outbound replies, with `webhook/API` used for the webhook platforms and `WS/webhook` for Feishu/Lark. Anyone reading the diagram should note that the transport is not uniform across platforms.

Building the binary from the Rust workspace

The project is a Cargo workspace with four crates, `openab-core`, `openab-gateway`, `openab-mcp` and `openab-cp`, plus a package named `openab` at version 0.10.0 on edition 2021, with `openab-agent` and `crates/platform-schema` excluded from the workspace. The Docker build makes the layering visible. A builder stage compiles the workspace in release mode, and the runtime stage is a slim Debian image.

FROM rust:1-bookworm AS builder
WORKDIR /build
COPY Cargo.toml Cargo.lock ./

The feature selection is where the deployment choices live, and they are declared in the package manifest.

default = ["discord", "slack", "secrets-aws", "agentcore", "config-s3", "pre-seed", "filestore"]
unified = ["telegram", "line", "feishu", "googlechat", "wecom", "teams", "acp", "lineworks"]

So the default build covers Discord and Slack only, and the unified feature compiles every gateway adapter into one binary. The runtime image is deliberately small.

FROM debian:trixie-slim
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates curl procps ripgrep tini unzip && rm -rf /var/lib/apt/lists/*

The repository also carries per-agent Dockerfiles, including ones for Claude, Codex, Copilot, Cursor, Devin, Gemini, Grok, Kimi, OpenCode and Antigravity, plus a `Dockerfile.unified`, a `Dockerfile.gateway` and a `Dockerfile.agentcore`.

What Discord asks you to enable before anything works

The Quick Start starts with prerequisites rather than a command, and they are in the Discord Developer Portal. Two privileged gateway intents have to be enabled under Bot: the Message Content Intent and the Server Members Intent. Under OAuth2 in the URL Generator, the bot permissions needed are Send Messages, Embed Links and Attach Files, plus Read Message History and Add Reactions. The Server Members Intent is the one people miss, and it is required for member-specific behaviour such as presence. The documentation points to a separate Discord guide for a step-by-step walkthrough of the bot creation itself. A configuration file drives the rest, with `config.toml.example` at the repository root, and the manifest shows an MCP facade that is enabled by a `[mcp]` section in that file.

Deployment, auth persistence and a preview control plane

The project is Kubernetes-ready, with a Dockerfile, k8s manifests and a persistent volume claim used for auth persistence, and there is a `charts/` directory for Helm packaging. Lifecycle hooks run custom scripts at startup and shutdown, named `pre_boot` and `pre_shutdown`, and the stated uses are bootstrapping, S3 sync and state backup. A Tailscale integration joins a private tailnet from an unprivileged container through those same hooks, so you do not need a custom image for it. Optional core features cover secrets from AWS, S3-backed configuration, pre-seeding and a filestore. The agent control plane is marked as a preview: a standalone `openab-cp` service for direct agent-to-agent delegation over WebSocket, with identity-bound registration and control-plane authoritative policy, and the documentation is candid that the runtime client and facade land in follow-up releases. Treat that piece as a preview rather than a dependency.

Beta releases, an MIT licence and what to verify first

The release naming tells you where the project is. The most recent artifacts are `oabctl-pre-beta` dated 2026-10-03, `openab-0.10.0-beta.5` dated 2026-09-26 and `openab-0.10.0-beta.4` dated 2026-09-08, and the repository is not archived with the last push on 2026-10-17, so work is moving quickly but nothing is labelled stable. That is the main caveat for anyone putting this in front of a team. The licence is MIT, which is permissive enough for internal deployment and modification without the copyleft obligations that would apply to a hosted service, and the repository also ships an AWESOME.md, a DESIGN.md and a RELEASING.md alongside the contribution guide. Before you rely on it, read the Discord prerequisites and get a single agent runtime answering a mention in one channel, then add platforms.

Editorial conclusion

OpenAB fits a team that wants its coding agent reachable from Discord or Slack, with a thread per conversation and a pluggable runtime, and that can host the broker itself. It is the wrong choice if you need a stable release contract, since the published artifacts are still pre-release and beta, or if you want a desktop experience rather than a chat one. Before adopting it, read the Discord developer portal prerequisites and enable the Message Content and Server Members intents, because the broker cannot start a conversation without them.

Frequently asked questions

Official sources

1. License: MIT
2. openabdev/openab on GitHub
3. Project website
4. README
5. Releases