Integration guide
Connecting AI agents to WeCom, DingTalk and Feishu
If your team, your Chinese subsidiary or your suppliers work in WeCom, DingTalk or Feishu, that is where the agent should appear — not in a separate window somebody has to remember to open. All three are built-in channels in Olano. What differs is how each one connects, what it needs, and whether the agent should speak in a group.
The short answer: WeCom (Tencent's enterprise WeChat), DingTalk (Alibaba's) and Feishu (ByteDance's, sold internationally as Lark) are built-in Olano channels, added in the console through a guided, typed form with help on every field. They connect differently. WeCom goes through the platform's AI-bot callback and needs a bot ID and secret. DingTalk uses stream mode — it needs the app's client ID and secret and no public callback URL. Feishu needs an app ID, app secret and verification token, in either long-connection or webhook mode. One agent can sit on all three at once, with every person's conversation history isolated from every other's.
Platform details checked on 26 September 2026 against each vendor's documentation; confirm current requirements before setup.
Three channels, three mechanisms
| WeCom | DingTalk | Feishu / Lark | |
|---|---|---|---|
| Connection | AI-bot callback (encrypted) | Stream mode, real-time | Long connection (WebSocket) or webhook |
| Credentials | Bot ID, secret | Client ID, client secret | App ID, app secret, verification token |
| Public endpoint needed | Yes (callback) | No | Webhook mode yes; long connection no |
| Direct-message policy | Open / allowlist / disabled | Sender allowlist is a hard gate | Per the app's visibility scope |
| Group behaviour | Open / allowlist / disabled | All / mentions only / none | Mention-triggered, with interactive cards |
WeCom: the AI-bot callback
Olano uses WeCom's AI-bot integration: create the bot in the WeCom admin console, take its bot ID and secret, and enter them in the channel form. Callbacks arrive encrypted; Olano handles decryption and verification.
Two switches are worth deciding before launch: the direct-message policy and the group policy, each of which can be open, allowlist or disabled. Allowlisted DMs with groups disabled is the safest starting point — let a few colleagues use it, then widen.
DingTalk: stream mode, no public endpoint
DingTalk is the easiest of the three to deploy. Olano connects outward to DingTalk's stream service to receive messages, so no callback URL has to be exposed — which matters for an internal deployment, or a team that does not want to provision a domain and certificate. All it needs is the DingTalk app's client ID and client secret. Replies go out as Markdown.
Groups have two independent switches: respond (all messages / mentions only / never) and listen (off / all / mentions). Separating them is deliberate — an agent can listen to a whole group to build context but speak only when addressed. The sender allowlist is a hard gate: listed people get through, everyone else is ignored rather than merely filtered.
One platform limitation to know: DingTalk's own group webhooks may deliver only @-mentions. Stream mode is not affected.
Feishu / Lark: long connection or webhook, with cards
Feishu needs the app's ID, secret and verification token — the token is a second check that an event really came from Feishu. Choose long connection (no public endpoint) or webhook (public endpoint required).
Feishu's distinctive feature is interactive message cards: the agent can send a card with buttons, and a click triggers an action — approve or reject, directly in Feishu. Olano de-duplicates and rate-limits card actions, so a double-click does not execute twice.
What the three share, which is the part that matters
- Every person's history is isolated. One bot serves the whole company; A's conversations, preferences and reminders never surface in B's replies. This is enforced at the channel layer, not requested in a prompt.
- The approval boundary applies regardless of channel. Sending, paying, publishing and deleting wait for a person whichever door the request came through — being @-mentioned in a group with "send that email" is not the same as sending it.
- Every action is logged with the channel and the person who triggered it.
- Channel and model are independent choices. Run these channels on Qwen, or on anything else.
Which to connect
Usually not a feature question: connect whatever the team already lives in. Plenty of companies use all three, in which case connect all three — one agent, three doors, one memory.
For a Western company the practical cases are a Chinese subsidiary or team that works in one of these, suppliers or partners who do, or an internal agent that has to be reachable by staff in both Slack and DingTalk. For a Chinese company running operations abroad it is the other half of the picture — one deployment on WeCom for the home team and on WhatsApp for overseas customers, which is the shape described in Chinese companies expanding to Southeast Asia.
Three decisions before launch
- Allowlist first, widen later. All three offer some form of it; use it.
- In groups, default to mentions only. A bot that volunteers in a group is the fastest way to get it removed from one.
- Name the person who reviews the log weekly. Without one the agent degrades quietly and nobody knows.
The full channel reference is in channels and connectors.
Related reading
Channels and connectors
The reference for every channel, including these three.
Chinese companies in Southeast Asia
WeCom at home, WhatsApp abroad, one deployment.
Running Qwen on Olano
The model half: assigning Qwen models per role.
Multi-agent vs single agent
Which agent should be in which group, and why.
FAQ
Does Olano support WeCom, DingTalk and Feishu?
All three are built-in channels added through a guided form in the console. WeCom connects through the platform's AI-bot callback and needs a bot ID and secret; DingTalk uses stream mode and needs the app's client ID and secret; Feishu needs an app ID, app secret and verification token, in long-connection or webhook mode.
Does DingTalk need a public server?
No. Olano connects outward to DingTalk's stream service, so no callback URL, domain or certificate has to be exposed — which makes DingTalk the easiest of the three to deploy.
Will the agent talk out of turn in group chats?
Only if you let it. DingTalk has separate respond (all / mentions only / never) and listen (off / all / mentions) switches, so an agent can build context from a whole group while speaking only when addressed; WeCom's group policy can be open, allowlist or disabled; Feishu is mention-triggered. Mentions-only is the sensible launch default.
If one bot serves the whole company, do people's conversations mix?
No. Each person's history, preferences and reminders are isolated at the channel layer, so nothing from one person's conversation appears in another's replies. It is enforced by the system, not requested in a prompt.
If someone @-mentions the agent in a group and tells it to send an email, does it send?
No. Actions that send, pay, publish or delete meet the approval boundary whichever channel the request came from. In Feishu the approval itself can be done with a button on an interactive card.
One agent, three doors, one memory
WeCom, DingTalk and Feishu out of the box, every person's history isolated, every outbound action behind approval — the agent goes where the team already works.