Workers in Missions
Each worker spawned by a mission is ephemeral — it exists only for the duration of its assigned tasks and is cleaned up when the mission completes or is canceled. Every worker receives:- A dedicated lane (its own git worktree and terminal session)
- A tool palette scoped to the mission’s permission config
- A budget allocation drawn from the mission’s total budget cap
- A context window seeded from the Mission Pack
Context Compaction
When a worker’s context window reaches 70% capacity, ADE automatically compacts it: older messages are summarized and compressed, while key decisions, file paths, and current task state are preserved in full. This prevents context overflow mid-task without losing work.Worker Recovery
If a worker crashes or loses connection mid-task, ADE attempts recovery from the worker’s last known state. Recoverable crashes (network blips, transient errors) are retried automatically. If recovery fails, the worker’s task is markedfailed and an intervention is raised.
Approval Gates and Interventions
Beyond the initial plan approval, missions support mid-execution approval gates for decisions that require your input.**Screenshot: Intervention dialog — show an open intervention card in the Plan tab with the question text, worker context, and the response input field with Accept/Redirect/Skip options.
- Pauses the relevant worker (other workers continue unaffected)
- Surfaces the intervention in the Plan tab activity feed as a highlighted card
- Sends a notification if ADE is backgrounded
Intervention types
approval_required — user sign-off needed
approval_required — user sign-off needed
The worker encountered a decision point requiring explicit authorization. Common triggers: destructive operations (deleting files, force-pushing), operations outside the worker’s configured permission scope, or explicit
pause_and_ask calls from within a custom tool.budget_limit_reached — spending cap hit
budget_limit_reached — spending cap hit
The mission is approaching or has reached its configured budget cap. You can approve additional budget, reduce scope, or stop the mission and accept partial results.
phase_approval — phase boundary gate
phase_approval — phase boundary gate
A phase was configured to require approval before advancing. Review the phase output and decide whether to proceed to the next phase.
failed_step — worker needs direction
failed_step — worker needs direction
A worker’s step failed and automatic retry was not successful. You can provide new instructions, tell the worker to skip the step, or cancel the mission.
orchestrator_escalation — orchestrator surfacing a question
orchestrator_escalation — orchestrator surfacing a question
The orchestrator has a question it cannot answer from context. Respond in the mission chat or via the intervention card.
Error classification
All mission errors are classified into three categories:| Classification | Behavior |
|---|---|
recoverable | Worker retries automatically with exponential backoff; no user action needed |
user_action_needed | Intervention raised; mission pauses the affected worker and waits for your response |
fatal | Mission stops immediately; a full error report is generated and attached as an artifact |