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.

Ephemeral workers

Each worker spawned by a mission is ephemeral. It exists only for its assigned tasks, runs inside a lane’s worktree, carries a scoped tool palette, has its own budget allocation, and is cleaned up when the mission ends. Workers inherit three things from the mission:
  • The lane they are assigned to (files, ports, environment)
  • The provider and permission mode (Claude / Codex / OpenCode) chosen at mission creation
  • The Mission Pack snapshot at the current phase boundary, used to seed their context

Context management

Workers run against the provider’s native context window. When usage approaches the compaction threshold, ADE compacts older messages into a summary and preserves current task state, decisions, and file paths verbatim. This avoids mid-task context overflow without losing what was already done.

Recovery

If a worker crashes or drops its connection, ADE tries to resume from its last known state. Transient errors (rate limits, network blips) retry automatically. If resume fails, the worker’s step is marked failed and an intervention is raised.

Interventions

Beyond the approval gate, missions pause mid-run for decisions that need a human. When an intervention fires, ADE pauses the affected worker (other workers keep going), surfaces the intervention in the Plan tab, and notifies you if ADE is backgrounded.
The worker hit a decision that needs explicit sign-off. Typical triggers: destructive operations, steps outside the configured permission scope, or explicit pauses from a custom tool.
The mission is near or at its cap. You can approve more budget, reduce scope, or stop cleanly and accept partial results.
A phase boundary is configured to require approval. Review the phase output and decide whether to advance.
A step failed and automatic retry did not succeed. Provide new instructions, skip the step, or cancel the mission.
The orchestrator has a question it cannot answer from context. Respond in the mission chat or in the intervention card.

Error classification

Every mission error falls into one of three buckets:
ClassificationBehavior
RecoverableWorker retries with backoff; no human action
User action neededIntervention raised; affected worker waits
FatalMission stops; full error report attached as an artifact
This keeps transient noise from stalling a run and ensures genuinely blocking errors reach you quickly instead of quietly failing.