Skip to main content

Channels

Use this page when the base CLI path already works and you need to choose the right delivery surface story before diving into commands or config fields. The base CLI path still comes first. A user should be able to succeed with ask or chat before enabling service channels. If you want the exact per-surface setup contract instead of the conceptual surface map, go directly to Channel Guides. Keep Channel Recipes for representative rollout paths, smoke tests, and multi-channel sequencing. If you already know the provider and channel together, skip the narrower recipe pass and go to Common Setups plus the dedicated playbook that matches the rollout shape. If you specifically need to choose between gateway run and multi-channel-serve, continue to Gateway And Supervision.

Already Know The Rollout Shape?

If the provider and channel are already obvious, skip this concept page and go straight to the matching playbook.
If you already know you want…Go here
Volcengine plus Feishu or LarkVolcengine Plus Feishu Or Lark
Volcengine plus WeComWeCom Rollout
BytePlus Coding plus TelegramBytePlus Coding Plus Telegram
a local model plus outbound deliveryLocal Model Plus Outbound Delivery
several runtime-backed channels on one hostGateway Rollout

Fast Path By Situation

If you need…Start with…Why
Feishu or Lark should own a live team-chat runtimeFeishu/Larkit is the shipped runtime family with webhook or websocket ownership
Telegram is enough for the live reply loopTelegramit is the smallest runtime-backed setup surface
Matrix should own a self-hosted or federated room runtimeMatrixhomeserver and room trust boundaries stay explicit
WhatsApp should own a Cloud API reply loopWhatsAppdirect sends and the webhook reply loop are both shipped
WeCom should own the official enterprise AIBot laneWeComit aligns with the shipped long-connection contract
outbound notifications without a reply loopChannel Guides and Channel Setupoutbound-only surfaces stay visible without being overclaimed as runtimes
one host supervising several runtime-backed channelsGateway And Supervisionowner commands, selectors, and rollout order live there

Reading Rule

  • Use this page to choose the delivery-surface lane.
  • Use Channel Guides when one surface is already decided and you need the exact built-in contract.
  • Use Channel Recipes when you need commands, smoke tests, or concrete config.
  • Use Common Setups when provider and channel choice belong together.
  • Use Gateway And Supervision when the real question is ownership, selectors, or long-lived supervision.

Choose The Right Surface Story

LayerWhat it meansCurrent examples
Base assistant looplocal operator-first pathonboard, ask, chat, doctor
Gateway owner contractdaemon-owned runtime control for longer-lived surfacesgateway run, gateway status, gateway stop
Runtime-backed service channelsshipped reply-loop runtimesFeishu / Lark, Telegram, Matrix, WhatsApp, WeCom
Config-backed outbound surfacesshipped direct-send surfaces without a full reply-loop runtimeDiscord, Slack, LINE, DingTalk, Webhook, Email, Teams, Google Chat, Signal, Twitch, and similar outbound integrations
Catalog or planned surfacesinventory or future direction onlynot presented as if a reply loop already ships

Gateway And Runtime Ownership

  • gateway run, gateway status, and gateway stop are the current explicit owner contract for longer-lived delivery surfaces.
  • multi-channel-serve is the compatibility wrapper that supervises the shipped runtime-backed service-channel subset.
  • Loong does not flatten gateway ownership, reply-loop runtimes, and outbound-only sends into one vague “channel support” story.
  • Use Gateway And Supervision when you need the command-by-command ownership model, selector syntax, and rollout order in one place.

Runtime-Backed Service Channels

These are the shipped reply-loop runtimes today.
SurfaceTransport shapePrimary commands
Feishu / Larkwebhook or websocketloong feishu-send, loong feishu-serve
TelegramBot API pollingloong telegram-send, loong telegram-serve
MatrixClient-Server sync looploong matrix-send, loong matrix-serve
WhatsAppCloud API plus verified webhook serviceloong whatsapp-send, loong whatsapp-serve
WeComofficial AIBot long connectionloong wecom-send, loong wecom-serve

Outbound Surface Families

These surfaces ship direct sends, config validation, and inventory metadata without claiming a full reply-loop runtime. This page keeps the concept layer short on purpose; the fuller field-level inventory remains in Channel Setup.
Surface familyCurrent examplesTypical command shape
workplace chat sinksSlack, Discord, Microsoft Teams, Google Chat, Mattermost, Nextcloud Talk, Synology Chatloong <surface>-send
messaging and bridge targetsLINE, DingTalk, Signal, IRC, iMessage / BlueBubbles, Nostr, Tlonloong <surface>-send
direct delivery and alerting lanesWebhook, Email, Twitchloong <surface>-send

Public Documentation Rule

Loong tries to keep the public channel story truthful:
  • the gateway contract is documented as the runtime owner contract
  • shipped runtime-backed surfaces are documented as shipped
  • outbound-only surfaces are documented as outbound-only
  • catalog entries are not overclaimed as runtime support

Typical Progression

  1. Get the local assistant path healthy first.
  2. Add one shipped service channel if you need inbound or reply-loop automation.
  3. Use outbound-only surfaces when you need governed direct sends without pretending they are full runtime surfaces.
  4. Reach for multi-channel-serve only when you want multiple shipped service channels attached to the same CLI host.

Where To Go Next

  • Continue to Channel Guides for the full shipped channel matrix.
  • Continue to Channel Recipes for representative runtime-backed and outbound rollout examples.
  • Continue to Channel Setup for the practical public setup guide.
  • Continue to Gateway And Supervision for the longer-lived owner contract and channel-account selection rules.
  • For the broader public runtime contract, continue to Use Loong.
  • The full field-level source spec still lives in the repository’s public Channel Setup markdown.