The Automations tab is rolling out. In production builds it currently shows a “Soon” badge while the surface lands — the rule engine and run history described here are how it works once enabled.
Anatomy of a rule
Trigger
What starts the rule — a cron schedule, an action event, or an inbound webhook.
Execution surface
Either an
agent-session (a scoped AI chat) or built-in (deterministic ADE actions).Guardrails
Confidence threshold, duration cap, human review, and path/lane allowlists.
Output
Where results go — a comment, a follow-up lane or task, a draft PR, or evidence only.
Triggers
A rule fires from one of three broad classes of trigger.- Time-based
- Action events
- Webhooks & Linear
A 5-field cron schedule (minute, hour, day-of-month, month, day-of-week). Seconds aren’t supported. The editor previews the next fire time.
Linear triggers here are context only. The CTO owns Linear issue intake and routing — automations react to Linear events for their own work but never duplicate that pipeline. See Linear.
Execution surfaces
Choosing the surface is the key decision — it sets how much orchestration a rule carries.agent-session
A scoped AI chat thread with the rule’s prompt and allowed tools. Best for reviews, audits, and short summaries. Appears in run history as a thread.
built-in
A sequence of deterministic ADE actions — create a lane, run a command, run tests, predict conflicts, or dispatch an allowlisted ADE action. No AI in the loop; sandboxed to the target lane’s worktree.
Guardrails
Automations publish effects — comments, PRs, Linear updates, webhooks. Guardrails decide whether a run is allowed to publish, or whether it parks in a review queue first.| Guardrail | What it does |
|---|---|
| Confidence threshold | A run below the threshold (baseline ~0.65) lands in review instead of publishing. |
| Duration cap | Runs that exceed maxDurationMin (baseline 10 min) are cancelled. |
| Require human | Force human review regardless of confidence. |
| Verify before publish | The run must pass a verification step — or a reviewer’s approval — before external effects apply. |
| Path / lane allowlists | Built-in shell and file actions are sandboxed to specific lane worktrees or subpaths. |
security and release-risk start higher than quick.
Runs that need a human land in a queue with statuses like pending review, verification required, and completed clean. The dashboard shows a severity summary so you can triage without opening every run.
Secrets and scope
Env-ref secrets only
Webhook secrets and access tokens must be
${env:VAR_NAME} references — raw secret values are rejected and resolved at run time.Sandboxed actions
Built-in shell actions stay inside the allowed workdirs; paths that escape the lane worktree or project root are rejected.
Authoring a rule
You can write a rule from a free-text brief — a planner turns the brief into a draft rule (triggers plus actions) that you review before saving — or build it directly in the rule editor by picking a trigger, an execution surface, and guardrails. Templates seed a new draft to start from.CTO overview
The persistent operator that owns Linear intake and worker delegation.
Linear
Why Linear routing lives with the CTO, not automations.