Channels
Put agents where work already happens, from WhatsApp to webhooks.
A channel connects an external entry point to an agent. The channel is not the agent; it is the path work takes to reach it. Set them up in Console → Channels.
What you can connect
| Channel | Typical use |
|---|---|
| Field teams, lightweight mobile interaction | |
| Slack, Microsoft Teams, Discord | Team workflows where chat already lives |
| Telegram | Direct messaging deployments |
| Send work in, get results back, no new UI | |
| Public forms | External intake, optionally invite-gated |
| Webhooks | System events that should trigger agent work |
| GitHub | Developer events routed to an agent |
| Schedules | Recurring runs, covered in Scheduled work |
Binding a channel
Each channel binds to one agent in the workspace. Messaging channels need platform credentials (a bot token, a webhook registration, or a business account, depending on the platform). Forms can be public or restricted to holders of invite links. Webhook channels define their own authentication for callers.
Once bound, inbound traffic becomes conversations with the agent, or tasks when the channel feeds a Case.
Input mapping
External payloads rarely match what an agent needs. Part of channel setup is mapping the incoming shape (webhook body fields, form fields, message attachments) onto the agent's or Case's inputs, so the work arrives clean. This is typical FDE setup work: do it once, and the channel fits the workflow instead of the payload.
Design advice
- Meet users where they are. A WhatsApp channel that field staff actually use beats a beautiful surface they never open.
- Keep entry points few. One clear way to ask, per audience. A coordinator agent can route behind a single entry point when multiple specialists exist.
- Watch channel traffic after launch. Channel sessions appear in observability like any other run, including failures. Silent breakage on a channel users depend on is the failure mode to design against.