Automations and Autopilot

Automations brings goal-driven Autopilot and multi-step automation runs into one page. Use its Overview, Automations, Runs and Settings tabs to see what is active, what needs your decision and which rules govern it.

Prerequisites#

The assistant must be ready, required integrations must be connected, and the active workspace must permit the requested operation. Some settings need a manager/owner role. Provider charges and plan limits still apply to automated operations.

Start with a read-oriented goal on staging. For example:

Goal: Investigate the most recent failed staging deployment.
Done when: The report identifies the first build error, links the evidence,
and proposes one fix. Do not deploy or change configuration.

Start and inspect a run#

1. Open Overview, enter a goal and optional “Done when” criteria.
2. Start it and open its run record.
3. Read steps, decisions and status; review anything under Needs you.
4. Approve only the proposed action you understand, or deny/stop it.
5. Verify the final result against criteria and provider state.

Runs continue on the service after you leave the page. Status is one of “Running”, “Needs you”, “Succeeded”, “Failed” or “Stopped”. When a run shows succeeded, still check that it achieved the outcome you wanted.

Triggers and rules#

Use the Automations tab to configure supported triggers and multi-step missions. Enter a specific goal, criteria, trigger configuration and cooldown. Start with the trigger disabled, inspect its configuration, then test deliberately before enabling repeated runs. A cooldown reduces repeated execution but does not guarantee idempotency for every external action.

Settings exposes autonomy level, per-action overrides, verification/notification preferences and budgets. Review run/day and automatic-approval limits. Higher autonomy levels can permit more operations; risky actions may still wait or be refused. See Permissions.

Pause and stop#

Stop everything now pauses automation. Inspect live runs and any provider actions already submitted; pausing may not reverse that work. Resume everything allows future processing again. You can also stop an individual run from its detail card.

Before resuming after an incident, check credentials, scope and the last run result. Repeatedly restarting a failed write can duplicate changes. Check the target provider first.

API request shapes#

Paths below are relative to /api/v1 and require a user session/workspace context. A new run is POST /autopilot/runs:

{"goal":"Investigate the staging build failure without changes","criteria":"Report the first error and evidence"}

Read GET /autopilot, /autopilot/runs and /autopilot/runs/{run_id}. Supported decisions are POSTs to a run's /approve, /deny or /stop. Trigger creation uses /autopilot/triggers with fields including name, kind, goal, criteria, config, enabled and cooldown_minutes. Get valid trigger kinds/configuration from the UI instead of guessing them.

Troubleshooting and limits#

• Assistant not ready: follow its readiness message and check model/runtime availability.
• No provider connection: connect the intended workspace account before running.
• Waiting for a decision: open Needs you rather than submitting another identical goal.
• Budget reached: inspect limits and reset timing; do not evade them with extra keys.
• Failed or partial result: read its steps/error, verify effects already applied, then revise a bounded goal.

Related: Assistant, Incidents, Billing.