Feishu · WeCom · DingTalk · WhatsApp — one account system, one knowledge base, one audit trail
When we integrated AI for a client last year — Feishu, WeCom, DingTalk, WhatsApp all at once — IT started by connecting each platform separately. Three months later the problems surfaced: offboarding a departing employee meant closing accounts in four different admin consoles; "what did the AI reply yesterday?" got the answer "no idea, that was the WeCom AI"; and the worst one — a sales director asked about a contract clause via WeCom and the AI returned an outdated answer, because the knowledge base was updated on the Feishu copy only.
That experience taught me: an AI assistant spread across multi-IM platforms, if it's only connected and not unified, creates more pitfalls than it solves.
This is the most basic requirement and the easiest to get wrong. Many so-called "unified AI assistant" products just pin three chat windows onto one page while accounts stay separate. That's not unification, it's reskinning.
What actually works: Mule user → IM accounts (1:N). When an employee leaves, you close one Mule account and the AI on every IM platform dies instantly. Sounds simple, but it means dealing with each platform's open-capability constraints one by one.
Many "unified knowledge base" plans are actually a backup mechanism — each AI queries its own copy, plus a sync job. This causes knowledge drift: the answer you get from the Feishu AI differs from the WeCom AI, and eventually nobody trusts either.
We ended up having all AIs query the same Qdrant vector store — a single source of truth. That's demanding architecturally: a single-tenant Qdrant can't survive high concurrency, so you need sharding. But the payoff is that one knowledge update propagates to every platform instantly.
This one was forced by compliance. The client was in finance and asked a very direct question: "The AI calls our database — we gave it the password. So who takes the blame when something goes wrong?"
We chose a design with credential vaulting — the AI never stores passwords; it fetches them on demand, fully logged. It looks like over-engineering until something goes wrong, and then it saves you.
Honestly, this architecture isn't textbook-elegant. A few corners were cut:
First, WhatsApp integration went through a Baileys bridge. The official WhatsApp Cloud API application process was too slow for the client. The cost: the WhatsApp line isn't rock-solid and occasionally needs a Bridge restart.
Second, WeCom runs in smart-bot mode. The upside: no public callback URL needed, easy deployment. The downside: without configuring dm_policy, it accepts DMs from anyone by default — we missed that at first and had a production embarrassment: a client's bot was chatting up every stranger who DM'd it within an hour.
Third, Teams Webhook requires a public HTTPS endpoint. Non-negotiable, so we ended up with an Nginx reverse proxy. The problem: when the proxy dies, Teams users have no idea — they keep sending messages and get nothing back.
After two-plus years, the biggest lesson is: "unified" is not a state, it's an ongoing investment.
Many clients buy an AI assistant and think the job is done. Six months later: "nobody's using the AI anymore." Look closer — no one added Skills, the knowledge base stopped updating, nobody watches token usage. That's not a product problem; it's an organizational problem.
So if you're evaluating vendors, I'd suggest asking these two questions:
We've run this stack for two-plus years, and there's no silver bullet. The pain points of multi-IM unified management will always exist — only the degree changes.
If you're doing something similar, happy to compare notes on the pitfalls we hit.
Specific technical details — let's discuss in the comments or by email: how Qdrant sharding works, how to predict token usage, how to design Skill templates. Any of these could be its own article; today we stop here.