Skip to main content

Messaging Gateway

Messaging channels connect external chat platforms — Telegram, Slack, Email, Feishu, and more — to your resident Anyy. Once a channel is configured, you talk to Anyy from the apps you already use, and it replies in the same conversation.

A channel is an adapter for one platform. It owns the platform-specific work — authentication, receiving messages (by polling, webhook, or a long-lived socket), downloading media, applying access policy, and formatting replies — and translates everything into a neutral, platform-independent message shape that the rest of the runtime understands. Because of this split, the agent loop, sessions, memory, tools, and approvals never need to know which platform a message came from.

Channels require the resident gateway

Channels are delivered by the resident gateway — the long-running Anyy process. They are not available in one-shot CLI invocations. Start the gateway first (see Running as a Resident Service), then configure channels.

Platform Comparison​

The platform list below is the authoritative setup catalog. Implemented channels have a working runtime adapter and a dedicated setup page. Planned channels appear in the setup catalog (so you can see them in the wizard and in doctor output) but do not register a runtime adapter yet.

Channels are grouped only for readability; all implemented channels share the same routing, policy, and session model.

PlatformChannel nameStatusSetup guide
TelegramtelegramImplementedTelegram
DiscorddiscordImplementedDiscord
SlackslackImplementedSlack
WhatsAppwhatsappImplementedWhatsApp
Facebook MessengerfacebookImplementedFacebook

China platforms​

PlatformChannel nameStatusSetup guide
DingTalkdingtalkImplementedDingTalk
Feishu / LarkfeishuImplementedFeishu
Weixin / WeChatweixinImplementedWeixin
QQ BotqqbotImplementedQQ Bot

Other transports​

PlatformChannel nameStatusSetup guide
Email (IMAP/SMTP)emailImplementedEmail
SMS (Twilio)smsImplementedSMS
IRCircImplementedIRC
LINElineImplementedLINE

Planned​

These entries are listed in the setup catalog but have no runtime adapter yet. They have no setup page until their adapter ships.

PlatformChannel nameStatus
YuanbaoyuanbaoPlanned
Google Chatgoogle_chatPlanned

For the full set of configuration fields each channel accepts — credentials, access policy, threading, and media — see the Channels Reference.

Architecture​

Every channel sits between an external platform and the resident runtime. Inbound messages flow into the runtime; outbound replies flow back to the platform conversation they came from.

platform event or poll result
  -> channel adapter parses the platform payload
  -> channel adapter applies access policy and de-duplicates
  -> channel adapter stages any media
  -> neutral inbound message (ChannelInbound)
  -> channel runtime resolves identity + channel binding
  -> gateway session turn (or command dispatch)
  -> gateway emits a result event
  -> channel manager resolves the delivery route
  -> neutral outbound message (ChannelOutbound)
  -> channel adapter formats and sends the platform reply

Inbound. Each adapter normalizes a platform event into a neutral inbound message carrying channel-neutral routing keys: the channel name, account id, external peer id, optional thread id, sender id, and peer kind (dm, group, channel, or thread). The runtime resolves the sender's identity and channel binding from these keys, then drives a gateway session turn — or dispatches a command if the message is one. Gateway, sessions, and tools stay platform-neutral: they never branch on Telegram topics, Slack threads, or Discord channels.

Outbound. When the gateway produces a reply (or an approval prompt, a clarification, or a background-job notification), the channel manager resolves a delivery route and hands the adapter a neutral outbound message. The adapter formats it for the platform and sends it. Delivery resolution chooses where a reply goes:

  • origin — reply in the conversation the message came from (the default for trusted channel messages).
  • gateway — deliver to the local gateway surface rather than a channel.
  • current_user_default — the configured default binding for a named channel (requires delivery.channel).
  • none — suppress channel delivery.

The route is keyed by the stored channel binding, so a reply always returns to the originating channel, account, peer, and thread — even for asynchronous deliveries like a finished background job. Routes that point at a binding that has been removed or disabled are reported as stale rather than misdelivered.

Quick Setup​

Configure channels with the interactive wizard, then verify them:

# Interactive: pick a platform and fill in credentials
anyy setup channels

# Or configure one platform directly
anyy setup channels telegram --secret token=... --account-id personal-bot --write-config

# Verify a configured channel without contacting the platform
anyy channels doctor telegram

anyy setup channels walks the same catalog shown above. For the guided end-to-end flow, see the Setup Wizard; for per-platform credential steps, open that platform's setup guide from the matrix.

Secrets (tokens, app secrets, webhook secrets) are stored as references in the secrets system, never inline in config, logs, or diagnostics.

Gateway Commands​

The anyy channels command group operates configured channels on the running gateway:

# Static diagnostics for one channel (config, secret refs, webhook posture, live-smoke readiness)
anyy channels doctor CHANNEL

# Re-read channel configuration on the resident gateway without a full restart
anyy channels reload

channels doctor runs offline: it inspects configured channel blocks, required fields, and secret-ref resolvability without starting adapters, registering webhooks, or calling platform APIs. channels reload applies configuration changes to the live gateway.

Chat Commands​

Inside a channel conversation, a message that begins with a registered command (for example /help) is dispatched as a command instead of starting a normal session turn. The set of available commands depends on the surfaces enabled for that channel. Ordinary messages are routed to the agent as a session turn. Which commands a given platform exposes is documented on that platform's setup page.

Session Management​

Session persistence​

Each channel conversation is bound to an Anyy session through its channel binding (channel + account + peer + thread). Follow-up messages in the same conversation continue the same session, so context and history carry across turns. The binding is what lets an asynchronous reply find its way back to the right conversation later.

Reset policies​

A conversation can be returned to a clean state so the next message starts fresh instead of continuing prior context. How a reset is triggered and what it clears depends on the channel's configuration; see the per-platform setup pages and the Channels Reference for the exact fields.

Security​

Pairing​

Before an unknown sender can reach the agent, a channel can require pairing — an explicit step that authorizes that sender's identity for the channel. Until paired, messages from unrecognized senders are rejected by policy rather than silently processed, and the drop is recorded (in redacted form) so you can see why a channel looks quiet.

Admins and users​

Access is governed by per-channel policy that shares a common vocabulary across all platforms:

  • Direct-message policy: open, allowlist, pairing, or disabled.
  • Group policy: disabled, mention, allowlist, open, or pairing.
  • Allowlists for senders and for groups/channels, plus a require-mention option for group surfaces.

Channel policy controls who may talk to the agent; it does not grant authority over risky actions. State-changing, root-capable, or otherwise sensitive operations remain governed by Anyy's approval, ChangePlan, rollback, and audit semantics regardless of which channel a request arrives on.

Tool Progress Notifications​

While the agent works on a turn, channels can surface intermediate status — for example tool progress or a "still working" acknowledgement — back into the conversation, subject to each platform's capabilities (some platforms support typing indicators, others only text). Approval prompts and clarification requests are delivered through the same outbound path as normal replies.

Background Sessions​

Work that outlives a single turn — background jobs and scheduled (cron) deliveries — produces results asynchronously. When such a result is ready, the channel manager resolves the stored delivery route and posts the outcome back to the originating conversation, so you receive the answer in the same channel even after the original turn has ended.

Service Management​

Channels run only inside the resident gateway process. Operating them means operating that service: start it to bring channels online, keep it running for channels to receive and deliver messages, and use anyy channels reload to apply configuration changes. See Running as a Resident Service for installing and supervising the gateway.

Operating Multiple Platforms​

You can enable several channels at once. They share one runtime, one session model, and one policy vocabulary, while each adapter keeps its platform-specific transport (polling, webhook, or socket) to itself. A single Anyy can, for example, take Telegram direct messages, watch an IMAP mailbox, and answer in a Slack thread — all routed through the same gateway and the same identity/binding model.

Next Steps​