Your OpenClaw Slack Agent Should Be the First Person New Hires Talk To

We hired two engineers in February. The first one spent their first week asking questions in Slack: where's the staging environment, how do we deploy, what's our incident process, who owns the payments service. Normal stuff. Each question took 5-30 minutes to get answered, depending on who was online and whether they knew the answer.

The second engineer started a week later. By then we'd pointed our OpenClaw agent at the internal wiki and a few key Slack channels. Same questions, but now directed at the agent. Average response time: 12 seconds. And the answers included links to the actual docs, which meant the new hire could go deeper on their own.

That second engineer shipped their first PR three days earlier than the first one. Not because they were better. Because they spent less time waiting.

The Problem With Tribal Knowledge

Every engineering team has the same disease. Information lives in three places: documentation (outdated), people's heads (unavailable), and Slack history (unsearchable). A new hire has to somehow triangulate between all three to figure out how things work.

The standard fix is better documentation. Write it all down. Keep it updated. This has been the advice since approximately 1970 and it has never worked for more than about six weeks at any company I've been at. People write docs during onboarding pushes, then stop updating them the moment the new hire is settled.

The agent-based approach sidesteps this. Instead of keeping docs perfectly current, you point the agent at everything you have (wiki, Notion, Confluence, GitHub READMEs, pinned Slack messages) and let it synthesize answers from whatever's available. Outdated docs become less dangerous because the agent can cross-reference them against recent Slack discussions and code changes.

What the Onboarding Agent Actually Does

The setup is one MCP server with two tools, plus some system prompt work.

Knowledge base tool. Connects to your documentation platform (Notion, Confluence, whatever). One tool: search_docs — takes a natural language query, searches across all indexed pages, returns the top 5 relevant sections with links. If you're using Notion, their API makes this straightforward. For Confluence, you'll want to pre-index into a vector store because Confluence's search API is... not great.

Slack history tool. Connects to your workspace's message archive. One tool: search_slack — takes a query, searches across specified channels (typically #engineering, #ops, #general, and any team-specific channels), returns relevant messages with thread context. This is where Slack's Real-Time Search API helps, though you'll hit the rate limits we talked about in a previous article if you're not careful.

The system prompt tells the agent: "You are the engineering team's knowledge assistant. When someone asks a question, search the documentation first. If the docs don't have a clear answer, search Slack history for relevant discussions. Cite your sources — link to the doc page or Slack message. If you genuinely can't find the answer, say so and suggest who might know (based on who authored relevant docs or participated in relevant threads)."

That last bit — suggesting who to ask — turned out to be the killer feature. New hires don't just get answers; they learn who the experts are on each topic. "I couldn't find docs on our rate limiting strategy, but @sarah discussed it extensively in #architecture on Feb 12th" is more useful than "I don't know."

The Index Problem

The naive approach is real-time search: agent gets a question, searches docs and Slack live, returns results. This works but it's slow (2-5 seconds per search across two sources) and expensive if you're hitting APIs on every query.

What works better: pre-index everything into a vector store. We use a simple setup — a nightly job that crawls the wiki, extracts text from each page, chunks it, embeds it, and stores the vectors in a local SQLite database with the sqlite-vss extension. Same for Slack: the Events API streams messages into the database continuously, and a batch job embeds them every hour.

When the agent gets a question, it searches the local vector store instead of calling external APIs. Response time dropped from 3-4 seconds to under 500ms. The index stays reasonably fresh because Slack messages stream in real time and wiki pages update nightly.

Total infrastructure: one SQLite file, one embedding model (we use a small local one — no API calls), one cron job. It's not a production vector database. It doesn't need to be. We're searching maybe 50,000 documents, not 50 million.

What Breaks (and How to Fix It)

Stale documentation. The agent confidently answers with information from a doc that was last updated 18 months ago. The fix: include the last-modified date in the search results. The agent's system prompt says "If a document hasn't been updated in more than 6 months, note this in your response." Users learn to treat old docs with appropriate scepticism.

Conflicting sources. The wiki says one thing, a Slack thread from last week says another. This happens constantly because Slack discussions often represent decisions that haven't been written up yet. The fix: the system prompt tells the agent to prefer more recent Slack discussions over older documentation when they conflict, but to flag the conflict. "The wiki says X, but @dave mentioned in #engineering on March 2nd that the team switched to Y." This is actually better than what a human would do — most people would just give you one answer without mentioning the contradiction.

Permission boundaries. Not everything in the wiki should be accessible to everyone. Some teams have sensitive docs (compensation, legal, HR). The fix: scope the index by channel or role. The agent serving #engineering doesn't search HR docs. The agent serving #people-ops doesn't search code documentation. This mapping exists in your MCP server configuration, not in the system prompt.

The "I'll just ask the agent" trap. Some people stop thinking and start treating the agent as an oracle. "What should I name this variable?" is not a knowledge base question. The fix: the system prompt includes "Decline questions about opinions, preferences, or decisions that require human judgment. You can provide relevant context (past decisions, team conventions, style guides) but don't make the decision."

The Surprising Second-Order Effect

After a month with the onboarding agent, something unexpected happened. It wasn't just new hires using it. Senior engineers started asking it questions too.

Not because they didn't know the answers. Because finding the answer was faster through the agent than through their own memory. "What's the environment variable for the staging database?" is something they've looked up a dozen times. The agent returns it in 2 seconds with a link to the config doc. Faster than grepping through config files or scrolling through their browser history.

Usage data after 60 days: new hires accounted for 35% of queries, but the remaining 65% came from people who'd been on the team for months or years. The agent had become the team's memory, not just a training tool.

Our average queries per day stabilised around 40-50, with spikes to 80+ when someone new joins. At roughly $0.02 per query (embedding lookup + one LLM call for the response), that's about $1/day. The ROI against saved engineer time isn't even close.

What SlackClaw Does Here

SlackClaw includes knowledge base integration as a core feature. Connect your documentation platforms, configure which channels get which knowledge scopes, and the platform handles the indexing, embedding, and retrieval pipeline. No vector store setup, no cron jobs, no embedding model selection.

The platform also tracks which questions the agent can't answer — these show up in a dashboard as documentation gaps. If the agent says "I don't have information about X" five times in a week, that's a signal that X needs to be documented. It turns the agent into a documentation audit tool.

For teams building their own, the MCP server + SQLite + local embeddings approach works well enough for teams under 100 people. Beyond that, you'll want a proper vector database and more sophisticated indexing, which is where a managed platform saves real engineering time.

Start With One Channel

If you're going to try this, don't index everything at once. Start with one channel — probably #engineering or your main team channel. Index just the pinned messages, the wiki pages linked from that channel's topic, and the last 30 days of messages.

Point the agent at that index and let your team use it for a week. You'll quickly learn what questions people actually ask, what documentation is missing, and whether the response quality is good enough to expand.

The agent that knows everything about one domain is far more useful than the one that knows a little about everything. Scope it tight, prove it works, then expand.

---

Helen Mireille is chief of staff at an early-stage tech startup. She writes about the point where AI agents stop being demos and start being infrastructure.