Chat integrations (channels)

How Multica connects agents to chat platforms — one channel engine, per-platform adapters for Lark (飞书) and Slack — covering the inbound pipeline, sessions, and authorization.

A channel connects a Multica agent to a chat platform so your team can work with it where they already talk. Today there are two channels — Lark (飞书) and Slack — and both run on the same engine: a platform-neutral core plus a thin per-platform adapter. Adding a platform is "implement the adapter," not "rebuild the pipeline."

An installation is the unit that ties it together: one bot bound to one (workspace, agent). Inbound messages are routed to an installation, then through a shared pipeline; the agent's reply is sent back to the same chat.

Architecture

Rendering diagram…

The inbound pipeline (generic)

Every inbound message — Lark or Slack — runs through the same ordered steps in the engine Router. A platform adapter only supplies the per-platform pieces (the ResolverSet); the policy lives in the engine.

Route to installation — map the event to a channel_installation (→ workspace + agent). Lark routes by app_id; Slack routes by the app id carried on the event.
Addressing filter — in a group/channel, only messages that @-mention the bot continue; idle group chatter is dropped (not read).
Dedup — a two-phase (installation, message_id) claim guarantees exactly-once processing, even across server replicas.
Identity + authorization — resolve the sender's platform user id to a Multica user (the account binding), then re-check workspace membership. Unbound senders get a "link your account" prompt; non-members are dropped.
Session — find or create a chat session for this conversation and append the message (see Sessions).
Trigger — enqueue an agent task; a daemon runs the agent and the reply is sent back into the chat.

Sessions and context

The agent's context is the chat-session transcript — the messages that have been ingested into that session over time. This transcript model is generic (shared by every channel). What differs per platform is the session-isolation key the adapter composes:

Platform	Isolation key	Effect
Lark / 飞书	the chat id	One session per chat/group — consecutive turns in the same chat accumulate into one transcript (multi-turn memory).
Slack	DM: the channel; channel: `channel + thread root`	Each DM is one session; each @bot thread is its own session, so two threads in one channel don't mix.

In a group, only messages that @-mention the bot are ingested. Neither channel reads the channel's other (un-@'d) messages or scrollback today, so the agent won't see messages it wasn't addressed in. Fetching surrounding history as context is a planned enhancement.

Authorization

Two independent gates protect a bot in a shared group — both enforced in the engine for every message, identically for Lark and Slack:

Account binding (authentication) — the sender's platform user id must be linked to a Multica user. The first time someone messages the bot they get a one-time link to bind their identity to their own Multica account; until then no agent runs.
Workspace membership (authorization) — the bound Multica user must be a member of the installation's workspace, re-checked on every message. Non-members are silently dropped.

So adding a bot to a public channel is safe: only workspace members who have bound their identity can drive the agent, and each sender is checked independently. See the per-platform pages for the user-facing prompts.

The two channels

Lark (飞书) — scan to install. A workspace admin binds an agent by scanning a QR with the Lark app; no developer console steps. One Bot per agent. See Lark Bot integration.

Slack — bring your own app. A workspace admin creates a Slack app, installs it to their Slack workspace, and pastes its bot token + app-level token into Multica. Each agent gets its own Slack app, so several agents can each have a distinct bot in one Slack workspace. See Slack Bot integration for the manifest and step-by-step setup.

Self-host

Each channel is off until you set its at-rest encryption key (the key encrypts each bot's tokens before they touch the database):

MULTICA_LARK_SECRET_KEY=<base64-encoded 32-byte key>
MULTICA_SLACK_SECRET_KEY=<base64-encoded 32-byte key>

On Multica Cloud both are already configured. See Environment variables for the full reference.

Lark Bot integration — scan-to-install, DM / @-mention / /issue
Slack Bot integration — bring-your-own-app setup (manifest + tokens), per-agent bots
Agents · Chat · Tasks