Slack
Slack as a first-class, bidirectional channel. Mention to run, threaded replies, inbound attachments, repo binding from links, and results back in the thread.
Slack is a first-class channel, not a notifier. A run can begin, continue, and finish entirely from Slack, and it enters the same durable command lane as the web UI.
Starting and continuing a run
Mention or DM to start
An @mention or a direct message starts a run.
Reply to continue
Replies thread under the run, with multi-turn continuity, reusing the thread’s history and sandbox.
Attachments ride the run
Inbound file attachments are attached to the run and render on the user’s turn in the web timeline.
Repository binding from links
GitHub links in a Slack message bind the run’s repositories, validated against the same allowlist the web composer enforces. The channel does not get a weaker security posture than the web app; it shares the allowlist.
Results back in the thread
Answers and artifacts flow back to the Slack thread:
- A Slack-started run posts a Block Kit run card with title and status, model, and owner or repository, plus an “Open in UseAgent” button.
- The card updates in place as the run moves from queued to running to completed, throttled, with a plain-text chunked fallback so the answer is never lost.
- Approvals are resolved in the web app today; in-thread Block Kit approvals are deliberately deferred.
Scoped bring-up
A per-channel ingress allowlist scopes where Slack can start runs, so a workspace can enable UseAgent in one channel before opening it more widely.