Skip to main content
Coming soon. Current thinking, not a shipped contract. Today you converse with a session over the API — stream events out, post messages in — and deliver events out via webhooks. Channels connect that same session to a Slack thread or a GitHub PR.
A channel binds a session’s thread to a place people already work, so the same session is reachable from there. Slack is the first channel.
  • Inbound. A Slack @mention or thread reply is verified, de-duplicated, and appended to the session as a steer — the same inbound message you can post over the API.
  • Outbound. The platform projects the session’s user and progress events back to the thread. The agent never calls Slack itself — it appends events; the platform delivers them, durably and idempotently.
  • Additive bindings. A session has a set of bindings added over its life; it is never typed as “a Slack session” or “a GitHub session.” A chat-born session that opens a PR gains a binding to that PR. Routing follows event level — conversation goes to conversation bindings, work product to delivery targets.
A channel is one consumer of the same public API a custom UI uses: post messages in, render the event stream at the level you want, and optionally bind a thread so the platform projects for you.