Execution surfaces

Choose between automation-only agent sessions, Missions, and built-in tasks for each automation rule.

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.

agent-session

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.

mission

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.

built-in-task

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:

Surface	Best for
agent-session	lightweight checks, short summaries, deterministic text outputs
mission	multi-step code changes, PR/open/merge flows, long-running workflows
built-in-task	one-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