Table of Contents
[Click to Install our bot to your Slack]
The bot sits in Slack. You @mention it with a question about Deepgram — anything from “how do I set up speech-to-text in Node?” to “why is my request returning a 400?” — and it goes off, searches through our documentation, and comes back with a proper answer. Not a link dump. An actual considered response with context.
It can also handle attachments. Drop an audio file in the thread and it’ll transcribe it using Deepgram’s speech-to-text API. Send a screenshot of an error and it’ll analyse the image and help you debug. It’s genuinely useful in ways that surprised even us.
The tools it has access to:
- Doc search — semantic retrieval across all of Deepgram’s documentation
- Audio transcription — drag and drop audio or video files, get a transcript back
- Image analysis — screenshots, error messages, architecture diagrams
- Service status — checks for any ongoing incidents at Deepgram
- Request lookup — paste a request ID and the bot will pull up the details from your project
That last one is the one that really changes things. A customer can paste a request ID from their logs, and the bot will look it up against their linked Deepgram project and tell them exactly what happened. No more “can you send me your request ID so I can look it up on my end.”
The self-service bit
This is the part I’m most pleased with. We didn’t want to manage installations. We didn’t want a spreadsheet of workspace IDs. We wanted customers to be able to install the bot themselves, authenticate with their Deepgram account, and start using it — all without anyone from our team being involved.
The flow: click “Add to Slack”, accept the permissions, log in to Deepgram, pick your project, done. One continuous flow — no separate setup page, no configuration. The bot links your Slack workspace to your Deepgram project and it’s ready to go.
How the AI loop works
Under the hood, the bot uses Anthropic’s Claude as an orchestrator. This isn’t a simple “send question, get answer” setup. It’s an agentic loop where Claude decides which tools to call based on the question.
A typical interaction looks something like:
- User asks “why is my STT request failing?”
- Claude decides it needs more context — calls the doc search tool
- Gets back relevant documentation about common error codes
- Claude decides that’s not quite enough — maybe it should check service status
- Checks for incidents — all clear
- Puts it all together and responds with a diagnosis and solution
The loop runs up to 10 iterations, and the bot updates Slack’s native status indicator as it goes — “is searching docs…”, “is checking service status…” — so the user knows something’s happening. When the response lands, tool calls are listed as context blocks underneath so you can see exactly what the bot did to arrive at its answer.
The Slack experience
We spent a fair bit of time getting the Slack UX right. Some things that matter:
Thread participation. You @mention the bot once to start a conversation. After that, it automatically participates in the thread — no need to keep tagging it. If someone @mentions a human in the thread, the bot stays out of the way.
Edit and delete handling. If you edit your message while the bot is still thinking, it aborts the in-flight request and re-processes with the updated text. Delete your message? It aborts and cleans up. This sounds minor but it makes the bot feel responsive rather than stupid.
Native thinking indicator. Instead of posting a “Thinking…” message and then deleting it (which looks janky), we use Slack’s native status API. You see “Deepgram Devs is searching docs…” in the thread, and it auto-clears when the response arrives.
Long responses don’t collapse. Slack has this annoying habit of collapsing long messages behind a “read more” fold. We split responses across multiple Block Kit sections, each under the collapse threshold, so the full answer is always visible. Tool call details and metadata sit in context blocks underneath — they never contribute to the fold.
What’s next
We’re continuing to iterate on this. The feedback buttons let users tell us when a response was helpful or not, which helps us tune the prompt and understand where the docs have gaps. We’re also looking at expanding the tool set — the model-context-protocol pattern makes it straightforward to add new capabilities without touching the core loop.
If you’re a Deepgram customer and want to try it, the bot is available for installation in your Slack workspace. If you’re building something similar for your own product — honestly, the architecture is simpler than you’d think. An LLM orchestrator with tool definitions, a few API integrations, and Slack’s Bolt framework gets you surprisingly far.