ZetrixwebWhy the "upload everything to a chatbot" approach stalls
The first internal AI assistant most companies build is a document upload into a chat interface: export the wiki, dump it into a vector store, point Claude at it. It works well in the demo and degrades immediately in production, because the underlying documents kept changing the moment the export finished. Six weeks later, the assistant confidently cites a pricing page or an org chart that's no longer accurate - and nothing in the system tells anyone that happened.
The fix isn't a better vector store. It's connecting Claude directly to the live systems - through MCP (Model Context Protocol) - so a query against "what's our current refund policy" actually reads the current wiki page, not a snapshot from whenever someone last ran an export.
What a first useful connection actually looks like
Documentation / wiki
Confluence, Notion, or an internal docs site - usually the highest-value first connection since it's already the source of truth people are supposed to check but often don't.
Team communication
Slack or Teams - not for real-time chat, but for finding the decision buried in a thread from three months ago that never made it into a formal doc.
Business systems
CRM, ticketing, or project trackers - live records that change daily and where a stale answer isn't just unhelpful, it's actively misleading.
Trying to figure out which of your internal systems is worth connecting first? Talk to us about scoping a knowledge assistant against your actual usage patterns.
Connect one system well before adding the next
The instinct on a first build is to connect everything at once - Slack, the wiki, the CRM, the ticketing system - so the assistant feels comprehensive from day one. In practice this produces a broad, shallow tool that's mediocre at everything, because permission boundaries, data freshness requirements, and query patterns differ meaningfully by system. The teams that get real adoption connect one high-value source, prove the assistant answers real employee questions correctly against it, and only then add the next connection - each one still tested against real questions, not just a demo script.
Permissions are the part that actually takes engineering time
The MCP connection itself is often the easy part. What takes real design work is making sure the assistant only surfaces what the requesting employee is actually allowed to see - not a blanket service account with broader access than any individual user has. An assistant that accidentally answers a junior employee's question using a document scoped to leadership isn't a minor bug; it's a trust-destroying incident that can end the whole initiative. Scope access to mirror the requesting user's own permissions, not the service account's maximum reach, and treat that scoping as core engineering work, not an afterthought before launch.
What "done" looks like for a first rollout
| Stage | What it looks like |
|---|---|
| Week 1-2 | One system connected (usually docs/wiki), permission-scoped, tested against 20-30 real employee questions |
| Week 3-4 | Measured accuracy on that first source; fix the failure patterns before adding a second connection |
| Month 2+ | Add the second source (often Slack or the CRM) only once the first is genuinely trusted internally |
| Ongoing | Track which questions the assistant gets wrong or can't answer - that list is your actual roadmap, not a fixed feature list |
Key takeaways
- A one-time document export goes stale immediately; MCP connections keep the assistant reading live systems instead of a snapshot.
- Connect one high-value system, prove it works against real employee questions, then add the next - not all sources at once.
- Permission scoping to the requesting user's actual access - not a broad service account - is the engineering work that actually determines whether people trust the assistant.
- Track what the assistant gets wrong as your real roadmap, not a predetermined feature list.