Skip to main content

​
What an execution surface is

Every automation rule answers the same question twice: what triggers it, and what runs when it fires. The second half is the execution surface, and there are three.
Worker run execution is paused in production builds. In packaged releases the rule editor and the Templates tab still display Worker run as an option so teams can see how they would wire it, but selecting Worker run is disabled with a “Coming soon” chip and the Save button is blocked. Dev and internal builds run worker run automations today. When you plan an automation that needs a worker run surface, use Chat or a built-in task as a stand-in until Workers ships.

​
Surface details

A lightweight chat thread created for the automation run.
  • Starts from a single prompt and optional seed context
  • Runs through the normal chat runtime with ADE-scoped tool access
  • Produces normal agent messages, tool events, and a transcript
  • Best when you want quick chat-like output and a readable record
Agent-session runs are recorded as automation-only chat threads visible in Automations → History.
A delegated worker run for work that needs a reviewable plan, multiple workers, or durable checkpoints.
  • Planner, approval gate, execution, and validation phases
  • Retry, intervention, and closeout handling
  • Worker lifecycle with lane affinity
  • Artifacts, step events, and the full intervention feed
Worker run outputs are visible in Workers — History rows for worker run-executed automation runs link directly into the worker run detail view.In packaged builds the option appears but is disabled until Workers ships.
A structured ADE-native task for short, deterministic work that doesn’t need a conversation.
  • No full chat or worker run thread
  • Strongly typed inputs and outputs
  • Useful for running test suites, predicting conflicts, and other maintenance sweeps
Built-in rules can now target a specific lane (or let ADE pick from the trigger context). The lane picker is the first control in the built-in action editor.

​
Building an automation rule

  1. Pick a time-based (schedule) or action-based (git, file, lane, webhook, Linear, manual) trigger.
  2. Pick an execution surface:
    • agent-session for a quick AI output
    • worker run for a complex or high-stakes workflow (dev builds only today)
    • built-in for a known ADE operation
  3. For built-in rules, pick the target lane or leave it on “Auto-select from the trigger or primary lane.”
  4. Set a tool palette and context policy.
  5. Configure guardrails and budget mode from Settings defaults.
  6. Add verification behavior and output routing.
Agent-session rules can still route their outputs to artifacts, PR comments, or Linear updates through the output routing options on the rule.

​
Example rules

  • PR reviewer — trigger git.pr_opened, execution agent-session, output an automation thread plus an optional PR comment.
  • Nightly test sweep — trigger schedule (0 8 * * 1-5), execution built-in (run-tests) targeted at the primary lane. No tokens, just a test report artifact.
  • Cache cleanup — trigger github-webhook, execution built-in, internal usage summary with a status event.
  • Release triage — trigger linear.issue_created, execution worker run (dev builds) or a multi-step agent-session as a fallback while Worker run is gated.