Skip to main content

​
Execution surfaces for Automations

An Automation execution is always one of three surfaces:
  • agent-session: persistent chat thread for a single automation run
  • mission: full multi-step mission runtime with workers, gates, and artifacts
  • built-in-task: ADE-native synchronous job without a full mission lifecycle
Each surface is selected per automation so you can match the right cost and visibility model.
A lightweight, single-thread session created for the automation run.
  • Starts from a single prompt and optional system context
  • Runs through the normal chat runtime with ADE-scoped tool access
  • Produces normal agent messages and tool events
  • Best when you need direct, low-latency automation output
Agent-session runs are recorded as automation-only chat threads. These threads are visible from Automations → History.
A full mission runtime for work that needs validation gates, parallel workers, or durable workflow history.
  • Planner and phase logic
  • Retry and intervention handling
  • Worker lifecycle and lane-affinity tracking
  • Artifacts, step events, and intervention feed
Mission outputs and status are visible in Missions, which is the canonical place to monitor multi-step execution.
A structured ADE-native task for short, deterministic work that does not require agent memory.
  • No full mission thread
  • Useful for refreshes, status checks, and prebuilt operations
  • Strongly typed inputs/outputs
  • Consistent with other background ADE tasks
This keeps small tasks fast and predictable while still respecting the same guardrails.

​
Choosing a surface

Pick the surface based on required control and operational cost:
SurfaceBest for
agent-sessionlightweight checks, short summaries, deterministic text outputs
missionmulti-step code changes, PR/open/merge flows, long-running workflows
built-in-taskone-off built-in operations and maintenance checks
Use agent-session when you want quick chat-like automation output, mission when execution needs reliability and intervention support, and built-in-task when you are just invoking a known ADE operation.

​
Building automation rules

When creating a rule:
  1. Pick a time-based or action-based trigger.
  2. Pick one execution surface for the initial run:
    • agent-session for quick AI outputs
    • mission for complex or risky workflows
    • built-in-task for internal operations
  3. Set a tool palette and memory policy.
  4. Configure guardrails and budget mode in Settings defaults.
  5. Add verification behavior and output routing.
If you use agent-session, you can still attach outputs to artifacts, PR notes, or Linear updates through output routing options.

​
Example flows

  • PR reviewer
    • Trigger: git.pr_opened
    • Execution: agent-session
    • Output: Automation thread in history + optional PR comment
  • Nightly test sweep
    • Trigger: schedule (0 8 * * 1-5)
    • Execution: mission
    • Output: Mission artifacts + validation findings
  • Cache cleanup
    • Trigger: github.webhook
    • Execution: built-in-task
    • Output: Internal usage and history marker with a status event