> ## Documentation Index
> Fetch the complete documentation index at: https://ade-ac1c6011-ade-im-seeing-error-messag-eright-58df792e.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Execution surfaces

> Pick between an automation-only agent session, a Worker run, or a built-in task for each automation rule.

## 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.

| Surface         | Best for                                                               | Cost                   |
| --------------- | ---------------------------------------------------------------------- | ---------------------- |
| `agent-session` | Lightweight checks, short summaries, a single deterministic output     | One short agent thread |
| `worker run`    | Multi-step code changes, long workflows that need reviewable plans     | A delegated worker run |
| `built-in`      | Deterministic ADE operations — tests, conflict prediction, status sync | No agent; no tokens    |

<Note>
  **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.
</Note>

***

## Surface details

<AccordionGroup>
  <Accordion title="agent-session" icon="message-circle">
    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**.
  </Accordion>

  <Accordion title="worker run" icon="bullseye">
    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.
  </Accordion>

  <Accordion title="built-in" icon="gear">
    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.
  </Accordion>
</AccordionGroup>

***

## 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.