Channels
Why a run behaves the same whether it starts in the web app, in Slack, or from a schedule. One durable command lane, one door.
A run does not care where it came from. The web app, Slack, and scheduled automations all submit work through the same durable command lane, so every channel inherits the same reliability, threading, and rendering.
One command lane
A channel accepts input
A message, a mention, or a schedule firing produces a command with an idempotency key.
The lane is shared
That command enters the exact same durable lane the web composer uses. There is no per-channel run engine.
Results flow back to the channel
Answers and artifacts return to the originating channel: Slack through the durable outbox, the web app over the thread event stream. Approvals are resolved in the web app today.
Why this matters
Because ingress is a single door, adding a new channel is mostly a matter of translating that channel’s messages into commands and delivering results back. A new channel gets durable commands, threaded replies, and restart survival for free, with no bespoke run UI.
Reliable by construction
A new channel reuses the durable command lane and the thread stream, so it is reliable without reimplementing orchestration.
Slack today
Slack is the first fully built channel: mention-to-run, threaded replies, inbound attachments, and results back in the thread.
Email digests
An env-gated email connector delivers run results outbound. When enabled, it
attaches to every spawned run and, on completion, sends a single digest email
with the run’s steps and the assistant’s output. CONNECTOR_EMAIL_NOTIFY=all
mails every completion and failed mails only failures; recipients come from a
fixed comma-separated allowlist, and a dry-run mode logs the fully rendered
payload instead of sending. Any partial or inconsistent configuration disables
the connector with a warning rather than half-sending. Email is delivery-only
today: it does not start runs.