Channels: one agent app on the widget, Slack, webhooks and your backend

A channel is where a conversation turn enters and where the answer leaves. The chat surface (the widget, the builder's test session, the end-user API) enters through Chat (in) directly. Other channels are adapter nodes: an input node such as Slack (in) or Webhook (in) sits before Chat (in) and turns the channel's payload into a turn; an output node such as Slack (out) or Webhook (out) hangs off Chat (out) and delivers the finished answer.

Chat (in) stays the one place for context and the input safety rules, so they apply to every channel, and Chat (out) screens every answer the same way. Several output nodes can hang off Chat (out). Each delivery is its own step in the run trace with a named error when it fails, and a failed delivery never undoes another delivery or the answer itself.

Create your own Slack app from the manifest on the Integrations page, so the bot carries your name and icon, and connect the workspace by pasting its bot token and signing secret. Put Slack (in) before Chat (in) and Slack (out) after Chat (out), pick the workspace on both, and publish.

Anyone in the workspace can then DM the bot or mention it in a channel. A DM is one ongoing conversation per person; a mention is answered in that message's thread, formatted for Slack. Every Slack thread is a conversation in AgentRow, so it appears in the Inbox and the support hand-off works over Slack. Slack's request signature is checked over the raw body, repeated events are ignored, and the bot never answers itself.

Webhook (in) lets another system start a run by POSTing signed JSON to the app's receiver. The signature is verified before the body is parsed, a repeated event id answers 'duplicate' and starts nothing, and the node's paths pick the input, the thread key and the identity out of the payload. Every request is recorded with its outcome, and the Credentials tab shows the receiver URL, a signing example and the latest events.

Webhook (out) posts every finished answer as signed JSON to a URL of yours, or to the callback URL a server run supplied. You verify the signature with the integration's secret, shown once when you create it. Webhook tools remain for the other direction: an agent that decides to trigger your system in the middle of a conversation.

Your backend starts a run with the app secret: a text or structured input, an optional thread key that keeps one thread across steps, sync mode to wait for the answer or async with a callback delivered by Webhook (out), an idempotency key so retries never run twice, and an identity token or auth context when a person is behind the task. No node is needed; server runs enter through Chat (in) like any other turn.

Every refusal is named, the Credentials tab shows ready-made curl calls, and the run's trace records the channel, the caller and the thread key on the Chat (in) step.

WhatsApp and Telegram as channels of the same app, the team's Inbox replies delivered back into Slack, Gmail, and a Shopify app that installs the assistant on a storefront. Each arrives as a node on the same graph, with the same trace.