Features

Automations & channels

An automation runs an agent when something happens instead of when someone asks. A channel lets people reach the same agent from Slack or Teams. Both go through the one execution path, so an agent gains no new powers — and loses no governance — by being triggered rather than chatted with.

Anatomy of an automation

Part	What it decides
Trigger	When it fires — a schedule, an inbound call, a change it watches for.
Agent	Which agent runs, and at which version.
Input template	The prompt, with placeholders filled from the trigger payload.
Delivery	Where the result goes — inbox, email, a channel DM, or an outbound webhook.

Triggers

Cron — on a schedule

A cron expression plus an IANA timezone. Next-run times are computed in the target zone, so "9am America/New_York" stays 9am across daylight-saving changes. The app ships a schedule builder for the common cases, so you don't have to hand-write the expression.

0 9 * * 1-5     America/New_York     # weekdays at 9am local

Webhook — when something calls in

Each automation gets an unguessable endpoint token.
Optionally verify an HMAC signature header — a bad signature returns 401 and creates no run.
Per-token rate limiting sheds bursts with 429, never a server error.
The payload is available to the prompt as {{payload.*}}.
The call is synchronous in the useful sense: it returns 202 with the run id, so the caller can follow along.

Watch — when a page or feed changes

Polls a URL on an interval (five minutes or slower). It uses conditional requests where the server supports them, and detects change by content hash or by a JSON path you nominate. The first poll only establishes the baseline, so you don't get a spurious "everything changed" on day one.

Email-in — when mail arrives

A per-automation address turns an inbound message into a run, with {{email.*}} available to the prompt and attachments stored as documents. Off unless the deployment enables it.

Wake-up — when an agent asks for one

A one-shot future trigger an agent schedules for itself with schedule_followup ("check whether the vendor replied on Thursday"). It fires exactly once and is bounded by the wakeup policy caps. Users see wake-ups in the automations list, badged as such, and can cancel them like anything else.

How dispatch stays honest

Property	How
Exactly once per slot	Due automations are claimed before they fire, against a ledger keyed by the scheduled time. A restart replaying the same slot cannot double-fire.
No thundering herd	Due work is claimed with row-level locking and skipped if already held, and per-user concurrency is bounded.
Backoff on failure	Retries back off exponentially from 30 seconds, capped at ten minutes.
Auto-pause	After ten consecutive failures the automation pauses itself and notifies its owner, instead of failing forever in silence.
Deprovision cascade	When a user is removed, their automations are disabled and the due sweep skips them.

Delivery

Target	Notes
Inbox	An in-product notification. Always available; the default.
Email	Via configured SMTP.
Channel DM	A Slack or Teams direct message, using the linked workspace.
Outbound webhook	HMAC-signed, so the receiver can verify it came from your deployment.

Automations are managed under Automate: create, edit in place, pause and resume, and inspect the run history for each one.

Channels: Slack and Teams

A channel connects an external workspace to your organization. Once linked, people talk to agents where they already work — and every message still creates a normal run with normal governance.

How a message becomes a run

Verify
The request signature is checked, with a replay window. An invalid signature is rejected outright, with no side effects.
Map the person
The external account is mapped to a platform user by verified email. If there is no match, the platform asks them to sign in — it never silently creates an account, because doing so would invent an identity to run under.
Pick the agent
The workspace's default agent, or a sticky per-thread choice made with /agent <slug>.
Run and stream
The thread maps to a conversation, and the answer streams back as progressive message edits rather than a wall of fragments.

What works in-channel

Mentions and DMs both start or continue a thread-scoped conversation.
Approvals render as interactive cards. Approving from Slack resolves the same state transition as the web inbox — and a double-click is rejected rather than executing twice.
Connect prompts appear inline when a connector needs consent.
Clarifying questions (ask_user) park the run; the reply in-thread resumes it.

The channel is a surface, not a bypass Ring visibility, policies, DLP, approvals, budgets, and audit apply identically to a Slack message and a web chat. There is no "channel mode" with looser rules.

Notifications

The inbox is the common destination for everything that needs a person: approvals awaiting a decision, automation results, skill proposals, budget alerts, quality-drift alerts, and automation auto-pause notices. Approvals and proposals are actioned directly from there.