Operator Guide

Autopilot is a CLI-first async system. You submit work, workers execute, and the system notifies you when a run needs attention. You inspect the result, then approve, reject, or reply.

The operator loop

The cycle:

Create a task
Watch the inbox or notifications
Review summaries, artifacts, and durable previews
Decide — approve, reject, or reply with feedback
Repeat until the workflow reaches done

No Worker App required. The CLI exposes the full operator loop today.

Fast path

If you only remember a few commands, remember these:

autopilot tasks create --title "..." --type feature
autopilot inbox --watch
autopilot runs show <run-id>
autopilot tasks approve <task-id>
autopilot tasks reply <task-id> --message "..."

CLI reference

Tasks

# Create a task (--title and --type are required)
autopilot tasks create --title "..." --type feature

# List tasks (with optional filters)
autopilot tasks
autopilot tasks --status blocked
autopilot tasks --assigned dev

# Show task details
autopilot tasks show <task-id>

# Approve a blocked task
autopilot tasks approve <task-id>

# Reject with reason
autopilot tasks reject <task-id> --message "..."

# Reply with context (advances workflow with your feedback)
autopilot tasks reply <task-id> --message "..."

Inbox

The inbox is the current operator dashboard in terminal form. It shows:

blocked tasks waiting for approval
failed runs
recently completed runs with durable preview URLs

# Snapshot
autopilot inbox

# Live watch mode
autopilot inbox --watch

Runs

# List runs (with optional filters)
autopilot runs
autopilot runs --task <task-id>
autopilot runs --status failed

# Show run details (includes events and artifacts)
autopilot runs show <run-id>

# Continue a completed run with new instructions
autopilot runs continue <run-id> --message "..."

# Cancel a running or pending run
autopilot runs cancel <run-id>

autopilot runs show is the main review command. It exposes:

run status
compact event history
summary or error
artifacts
preview URLs when present

Previews

When a run produces previewable files, the orchestrator stores them durably and serves them itself.

Preview URLs look like:

http://<orchestrator-url>/api/previews/<run-id>/src/index.html

Important:

previews survive worker shutdown
previews are orchestrator-backed, not worker-hosted
opening them from another device still depends on having access to the orchestrator

Use them to review landing pages, generated docs, or other static outputs without checking out the worker branch manually.

Notifications

With a notification provider configured, Autopilot can send alerts for:

approval needed
task blocked
run failure
run completion

This is the main wake-up path when you are not watching the terminal.

See Providers and Handlers for the integration model.

Workflows

Workflows are authored YAML under .autopilot/workflows/. They define:

Steps — what happens
Routing — which step follows based on structured outputs
Approvals — where human sign-off is required
Outputs — the explicit fields a step produces

A minimal workflow:

id: default
name: Default Workflow
steps:
  - id: plan
    type: agent
    agent_id: dev
    instructions: "Plan the implementation for this task"

  - id: implement
    type: agent
    agent_id: dev
    instructions: "Implement according to the plan"

  - id: review
    type: human_approval
    on_approve: done
    on_reply: implement

  - id: done
    type: done

The engine handles progression automatically. When a step completes, it evaluates outputs and moves the task forward or blocks for operator input.

Deployment patterns

Local development

autopilot start

Good for development, testing, and proving the full workflow loop on one machine.

VPS orchestrator + local worker

# On VPS
autopilot server start

# On your machine
ORCHESTRATOR_URL=https://your-vps.example.com autopilot worker start

This is the most important practical setup right now:

the orchestrator runs on a durable host
workers can run on laptops or other machines
previews remain available after worker shutdown
the operator can keep working through CLI plus notifications

Multiple workers

Multiple workers can connect to the same orchestrator and claim runs independently.

Use this when:

different workers have access to different repos
different workers have different environments or credentials
you want one durable control plane with distributed execution nodes

On this page