The Slack AI Bot treats public/private channel threads differently from top-level channel traffic.
The public Slack AI Bot landing page is available at /slack-ai-bot. It explains the Tools-controlled installation flow and shows the supplied screenshots for installation setup, delivery diagnostics, workspace configuration, threaded replies and private image-aware conversations.
Installation still requires a signed-in Tools account plus approved Slack Bot access before OAuth can start. The public landing page does not bypass that entitlement.
Public support is available at /slack-ai-bot/support without requiring a Tools or third-party account. Users can contact support@tornevall.net or use /contact. Support requests are expected to receive a response within 2 business days.
Every Slack message that Tools accepts for processing gets an :eyes: reaction before AI processing starts. This applies to direct mentions, DMs, configured spontaneous channel messages, and channel-thread follow-ups. The reaction is best-effort: a Slack reaction failure does not prevent the message from continuing through the reply pipeline.
A user does not need to repeat @Tools for every message after Tools has joined a public/private channel thread. Slack must deliver message.channels and message.groups events for this to work, so both are part of the required Event Subscriptions shown on /slack-bot and in the canonical manifest.
Receiving these events does not enable unsolicited top-level channel replies. Top-level messages still require a direct mention or the existing opt-in spontaneous-channel configuration.
A thread message without a new mention is only eligible for a reply when Tools has already participated in that thread. The queued job reads bounded thread context and confirms prior bot participation before asking the AI for a decision.
When several people are talking in the same thread, the AI returns one structured decision containing both respond and the proposed response. It should answer direct follow-up questions, clarification requests, or messages that clearly continue the assistant's contribution. Human-to-human side conversations, unrelated tangents, and acknowledgements that need no answer are ignored.
The decision and response happen in one AI request so a thread follow-up does not require a separate relevance call followed by a second generation call. Replies preserve the original thread_ts.
Explicit image commands such as Create a random image are routed to Tools image generation rather than ordinary conversational text.
If bounded Slack context contains a recent Assistant message that explicitly commits to creating or uploading labelled image files and the matching labelled image descriptions are still available, a direct execution or delivery demand can recover that committed image set even after the earlier compact selection such as A+B+C has fallen out of the bounded context. A newer short image-upload commitment may refer back only to the nearest matching labelled image descriptions. Generic A/B/C lists, non-image file promises and unrelated labelled choices do not qualify and still block unsafe fallback.
Recovered image work uses the same owner authorization, image policy, batch bounds and real Slack file upload path as an ordinary explicit image request. The conversational text model is bypassed once this deterministic route matches, and delivery is successful only after Slack confirms the uploaded file ids.
If OpenAI returns credit_balance_exhausted, insufficient_quota, or the equivalent insufficient-quota error type/message, Tools writes a clear provider-failure message into the originating Slack conversation/thread. The existing critical OpenAI provider diagnostics, audit trail, email/SMS notification path, and #toolsapi reporting remain separate from that user-visible Slack message.
Other decision-only failures in unsolicited/spontaneous or thread-relevance evaluation remain non-intrusive and do not create a generic Slack error reply.