Radim: an AI coworker in Slack that understands company docs and live data

How do you give people fast access to two kinds of company knowledge without turning every question into a ticket for engineering? At UlovDomov, we built Radim: an internal Slack coworker that can answer from documentation and live operational data.

It runs on self-hosted n8n. A colleague sends Radim a direct message or mentions it in a channel; the agent retrieves internal documentation, can ask a read-only database questions in natural language, and responds in the Slack thread with sources and admin links. The point is not a generic chat bot. The point is to remove repetitive context-switching between sales, support, finance, and developers.

One entry point, reusable tools

Slack Events can target one URL, so every event first reaches a router workflow. The router filters bot and system messages, chooses the appropriate context, and dispatches the request to the L2 agent. The agent does not own monolithic integrations: knowledge_base and database are independent n8n sub-workflows. That makes each skill reusable from another bot or automation later.

Two operational lessons matter more than the diagram. First, a bot must never respond to itself: Slack message changes can have nested event payloads that bypass a naive bot_id filter. Second, context is a cost and quality budget. A direct message outside a thread starts clean; thread history is included only when the person explicitly continues the conversation there.

The agent is constrained by design

The core is an n8n AI Agent node. The primary model is Gemini 3.5 Flash in an EU region; GPT‑5.6 Terra on Azure EU is a cross-provider fallback. The model can call tools in iterations, but it has hard operational rules: calculations belong in the database; database and documentation calls have ceilings; it must plan and batch calls; it cannot promise work it will do later; and every known entity becomes a real production-admin link rather than an invented URL.

A Retry Gate sits before Slack delivery. It detects an empty response, raw JSON, or a plan instead of a result, retries the agent at most twice, and then returns a clear fallback message. Users should never receive silence or an implementation dump.

Knowledge base: documentation that stays current

The knowledge_base skill is RAG over Qdrant. It retrieves the relevant documentation chunks together with their source. The valuable part is the ingestion pipeline: Markdown documentation, Confluence synchronisation, project guides, and selected Slack threads all enter the same collection.

Project documentation is deliberately maintained in two forms: a user_guide explains the feature in business language, while a developer_guide explains its implementation. The agent can bridge a question such as “why did the payment not appear?” to the product process, then to the technical context needed for a safe data query. A valuable Slack discussion can also be turned into a structured Markdown document and committed to the repository, so knowledge does not disappear into scrollback.

Database skill: natural language to safe data

The database skill is a separate small pipeline. The main agent sends a Czech question and receives data only; SQL remains inside the skill. A cheaper specialised model generates SQL from a cached schema, then code—not the prompt—enforces the safety boundaries.

Three safeguards are non-negotiable: a replica created for this purpose only; SELECT-only sanitisation; and a mandatory LIMIT. An unrestricted SELECT once returned hundreds of thousands of rows and exhausted n8n memory. A forced result cap protects the runtime while leaving aggregation queries unaffected.

Reliability is an architecture, not a checkbox

The production failure worth sharing was a fallback policy that existed in the gateway but was never called by the workflow. A policy does nothing if a request calls the primary model directly. The original fallback was also another Gemini model on the same Vertex infrastructure, so it would have failed with the primary. The correction is explicit policy routing, a cross-provider fallback, retry validation, a human-readable failure message, and an error workflow with an internal debug log.

EU data handling and cost discipline

The system handles real names, emails, and contracts, so inference is restricted to EU regions through an AI gateway; the data layer remains a private database replica, Qdrant instance, and Git repository. Only the necessary prompt reaches an EU inference endpoint. This is an implementation pattern, not a legal conclusion: every company still needs its own DPA, provider review, access controls, and DPIA where applicable.

In real operation, simple questions cost roughly CZK 1–1.5, mixed documentation-plus-database questions CZK 2–3.5, and hard data analysis CZK 4–6. Prompt caching for the large database schema and a cheap specialised SQL model keep those costs down. A hard monthly cap prevents surprises.

What I would copy first

Start with guardrails rather than model cleverness: call limits, iteration ceilings, SELECT-only enforcement, mandatory row caps, timeouts, and logs. Improve the system prompt from real conversations, not generic benchmark examples. Keep the cheap model on the isolated task it does well; use the stronger model for orchestration. And invest in documentation: every useful document reduces future agent wandering, latency, and spend.

The useful outcome is not “AI that talks to Slack.” It is a trusted operational entry point where people already work, combining documented process knowledge with live data under clear technical and organisational controls.