Multica / Notifications and Integration

Chat integration (channels)

How Multica connects the agent to the chat platform - a unified channel engine, plus platform adapters for Feishu (Lark) and Slack - covering inbound pipelines, sessions and authorization.

View official source Docs index

Chat integration (channels) key concepts infographic

Overview

channel connects a Multica agent to the chat platform so teams can use it directly where they communicate daily. There are currently two channels - Lark (Feishu) and Slack - both running on the same engine: a platform-independent kernel, plus a thin layer of adapters for each platform. Adding a new platform is "implementing the adapter" rather than "rebuilding the pipeline".

Installation is the unit that ties it all together: a Bot bound to a (workspace, agent). Inbound messages are routed to an installation and passed through the shared pipeline; the agent's replies are sent back to the same chat.

Architecture

flowchart LR
  subgraph P["chat platform"]
    LK["Lark / Feishu"]
    SL["Slack"]
  end
  subgraph ENG["Channel Engine (Platform Independent)"]
    direction TB
    SUP["Supervisor<br/>One real-time connection per installation"]
    ROU["Routing pipeline:<br/>Routing → Deduplication → Authentication → Session → Trigger"]
  end
  LK -->|Long connection|SUP
  SL -->|Socket Mode| SUP
  SUP -->|Original event| ADP["Each platform adapter<br/>Conversion + ResolverSet"]
  ADP --> ROU
  ROU -->|Agent task| RUN["Daemon runs agent"]
  RUN -->|Reply| OUT["Outbound for each platform<br/>(bot token → platform API)"]
  OUT --> P

Inbound pipeline (general)

Every inbound message—whether from Lark or Slack—goes through the same set of ordered steps in the engine Router. Platform adapters only provide the parts specific to each platform (i.e. the ResolverSet); the strategy itself lives in the engine.

Route to Installation - Map events to a channel_installation (→ workspace + agent). Lark routes by app_id; Slack routes by the app id carried in the event.
Addressing Filter - In the group/channel, only messages with @ Bot will continue to go down; irrelevant group chats will be discarded (not read).
Deduplication - A two-stage (installation, message_id) claim mechanism guarantees exactly once processing, even across multiple server replicas.
Identity + Authorization - Parse the sender's platform user ID into a Multica user (i.e. [Account Binding](#Account Binding)), and then verify the workspace membership identity again. Unbound senders will receive a "Bind your account" prompt; non-members will be discarded.
Conversation - Find or create a chat conversation for this conversation and append the message to it (see [Conversation](#Conversation and Context)).
Trigger - Enqueue an agent Task; a Daemon Process runs the agent, and the reply will be sent back to the chat.

Conversation and context

The context of the agent is the conversation record of this chat session - that is, the messages that have been included in the conversation over time. This conversation recording model is universal (shared by every channel). What differs between platforms is the session isolation key spelled out by the adapter:

Platform	Isolation Key	Effects
Lark / Feishu	Chat id	One conversation per chat/group - consecutive rounds in the same chat will be accumulated into a conversation record (multi-round memory).
Slack	Private chat: channel; channel: `channel + thread root`	Each private chat is a conversation; Each @bot thread is its own conversation, so two threads in the same channel will not mix together.

In the group, only messages with @ Bot will be included. Currently, both channels will not read other (without @) messages or history scrolling records in the channel, so the agent cannot see messages that do not name it. Pulling in surrounding history as context is a planned enhancement.

Account binding

In shared groups, there are two independent levels protecting bots - both are enforced in the engine for every message, and Lark and Slack treat them equally:

Account Binding (Authentication) - The sender's platform user id must be associated with a Multica user. The first time someone sends a message to the bot, they are given a one-time link that binds their identity to their own Multica account; no agent will be running until then.
Workspace Membership (Authorization) - The bound Multica user must be a member of the workspace to which the installation belongs, and each message will be re-verified. Non-members are silently discarded.

So adding a Bot to a public channel is safe: only workspace members with bound identities can drive the agent, and each sender is independently verified. Please see the pages of each platform for user-oriented prompt copy.

two channels

**Lark (Feishu) - Scan the QR code to install. ** Workspace administrators can use Feishu App to scan a QR code to bind an agent; no background steps are required for developers. One agent and one Bot. See Lark Bot Integration.

**Slack - comes with the app. ** The workspace administrator creates a Slack app, installs it in his/her Slack workspace, and then pastes its bot token + app-level token into Multica. Each agent has its own Slack app, so multiple agents can each have an independent Bot in the same Slack workspace. See Slack Bot Integration for the manifest and step-by-step setup.

self-deployment

Each channel is closed until you set its static encryption key (this key will encrypt each bot's token before it is logged out):

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

Both are already configured on Multica Cloud. See Environment Variables for a complete reference.

Next step

Lark Bot Integration - Scan the QR code to install, private chat / @ mention / /issue
Slack Bot Integration - Comes with application settings (manifest + token), one Bot for each agent
Agents · Chat · Tasks