Skip to main content

Documentation Index

Fetch the complete documentation index at: https://ade-app.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
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.
SurfaceBest forCost
agent-sessionLightweight checks, short summaries, a single deterministic outputOne short agent thread
missionMulti-step code changes, long workflows that need reviewable plansA full mission run
built-inDeterministic ADE operations — tests, conflict prediction, status syncNo agent; no tokens
Mission execution is paused in production builds. In packaged releases the rule editor and the Templates tab still display Mission as an option so teams can see how they would wire it, but selecting Mission is disabled with a “Coming soon” chip and the Save button is blocked. Dev and internal builds run mission automations today. When you plan an automation that needs a mission surface, use Chat or a built-in task as a stand-in until Missions 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 full mission 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
Mission outputs are visible in Missions — History rows for mission-executed automation runs link directly into the mission detail view.In packaged builds the option appears but is disabled until Missions ships.
A structured ADE-native task for short, deterministic work that doesn’t need a conversation.
  • No full chat or mission 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
    • mission 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 memory 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 mission (dev builds) or a multi-step agent-session as a fallback while Mission is gated.