How Autopilot Works

An autonomous development orchestrator that keeps humans in the loop at every decision point.

The Three Roles

D

Director

Human Strategist

Sets the vision, reviews proposals, approves plans, and makes all strategic decisions. Interacts via Telegram on mobile — always in control, never blocked.

P

Planner

AI Advisor

Responds to the Director in real-time. Proposes projects, generates slide decks, learns preferences silently. Never acts without approval.

E

Executor

AI Builder

Builds only what has been validated. Executes plans step-by-step using Claude Code, reports progress, and asks for decisions when needed.

Core Principle

Nothing gets built without a reviewed slide deck.

Every project starts as a proposal. The Planner creates an interactive slide deck that the Director reviews on their phone. Only after explicit approval does work begin. This ensures intentionality — no wasted effort, no surprises.

The Workflow

The three roles interact in a continuous loop. The Director sets direction, the Planner translates intent into concrete proposals, and the Executor implements approved plans.

graph TD D["Director
(Human)"] -->|"sends message or command"| P["Planner
(AI Advisor)"] P -->|"proposes actions
with slide decks"| D D -->|"approves plan"| E["Executor
(AI Builder)"] E -->|"reports progress
or asks decision"| D D -->|"answers decision"| E E -->|"project complete"| P P -->|"suggests next project"| D style D fill:#e8f5e9,stroke:#2d7d46,color:#1a1a1a style P fill:#e3f2fd,stroke:#1565c0,color:#1a1a1a style E fill:#fff3e0,stroke:#e65100,color:#1a1a1a

Project Lifecycle

Every project follows a strict state machine. Transitions are validated — no shortcuts, no skipping steps.

stateDiagram-v2 [*] --> Pending: Proposed Pending --> Backlog: Director validates Pending --> Rejected: Director rejects Backlog --> Planning: Plan requested Backlog --> OnHold: Director pauses Backlog --> Rejected: Director rejects Planning --> PlanReview: Plan generated Planning --> Backlog: Reset PlanReview --> Executing: Director approves plan PlanReview --> Planning: Needs revision PlanReview --> Backlog: Reset Executing --> Completed: All steps done Executing --> OnHold: Director pauses OnHold --> Backlog: Director resumes OnHold --> Executing: Director resumes state Pending { direction LR [*] --> ReviewDeck: Proposal deck created ReviewDeck --> [*]: Director reviews on phone } state PlanReview { direction LR [*] --> ReviewPlan: Plan deck created ReviewPlan --> [*]: Director reviews steps }
pending Proposal submitted, awaiting Director review of the slide deck.
backlog Approved proposal, queued for planning when prioritized.
planning Executor is generating the detailed execution plan and step deck.
plan-review Plan ready, Director reviews the step-by-step deck before approving.
executing Plan approved, Executor is building step-by-step.
completed All steps done. Planner is consulted on what to do next.
on-hold Paused by Director. Can be resumed to backlog or execution.
rejected Director rejected the proposal.

How Execution Works

The Executor runs in a timed loop during work hours. Each cycle follows this sequence:

flowchart TD A["Executor Cycle Starts"] --> B{"Paused?"} B -->|Yes| Z["Skip cycle"] B -->|No| C{"Within work hours?"} C -->|No| Z C -->|Yes| D{"Daily report due?"} D -->|Yes| E["Generate & send report"] D -->|No| F{"Projects in 'planning'?"} F -->|Yes| G["Generate execution plan
Create slide deck
Move to plan-review"] F -->|No| H{"Projects in 'executing'?"} H -->|No| Z H -->|Yes| I{"Pending decisions?"} I -->|Yes| Z["Wait for Director"] I -->|No| J{"Cooldown elapsed?"} J -->|No| Z J -->|Yes| K["Execute next step
via Claude Code"] K --> L{"Step result?"} L -->|Completed| M["Record progress
Send update
Check if plan complete"] L -->|Decision needed| N["Post question to Telegram
Block until answered"] style A fill:#e8f5e9,stroke:#2d7d46,color:#1a1a1a style K fill:#fff3e0,stroke:#e65100,color:#1a1a1a style Z fill:#f5f5f5,stroke:#9e9e9e,color:#1a1a1a
Check interval: Every 5 minutes
Step cooldown: 30 minutes between executions
Work hours: 8:00 - 22:00
Timeout: 30 minutes per Claude Code invocation

The Decision Flow

When the Executor encounters a choice that requires human judgement, it pauses and asks the Director via Telegram.

sequenceDiagram participant E as Executor participant T as Telegram participant D as Director E->>T: "Should we use PostgreSQL or Supabase?"
[Option 1] [Option 2] T->>D: Push notification with inline buttons Note over E: Execution blocked.
No further steps until answered. D->>T: Taps "Supabase" T->>E: Decision resolved E->>E: Resume step with decision context E->>T: "Step 3/8 complete: Set up Supabase..." T->>D: Progress update

Directors can respond by tapping inline buttons or replying with free text. Decisions have a 48-hour timeout — if unanswered, the system moves on with a default.

Learning System

The Planner silently learns from every conversation. When the Director expresses a preference or sets a boundary, the Planner can extract it as a guideline — a persistent rule that shapes all future behaviour.

process

Rules about how work should flow. Example: "Nothing gets built without a reviewed slide deck."

preference

Director tastes and inclinations. Example: "Prefer Supabase over self-hosted PostgreSQL."

decision

Recorded choices for consistency. Example: "Brand: Clean Harvest — chosen 2026-04-05."

Guidelines accumulate over time, forming an institutional memory that makes the system increasingly aligned with the Director's intent.

Data Architecture

All state lives in flat JSON files on disk. No database, no external service. The file system is the source of truth.

graph LR subgraph "data/" A["programs/
qrop.json"] --- B["projects/qrop/
*.json"] B --- C["plans/qrop/
*.json"] A --- D["decisions/
qrop.json"] A --- E["progress/
qrop.json"] A --- F["conversations/
qrop.json"] end A -->|"mission, vision,
guidelines"| G["Planner Context"] B -->|"states, lifecycle"| G C -->|"steps, progress"| H["Executor Context"] D -->|"pending questions"| H E -->|"audit trail"| I["Daily Reports"] F -->|"message history"| G style A fill:#e8f5e9,stroke:#2d7d46,color:#1a1a1a style B fill:#e3f2fd,stroke:#1565c0,color:#1a1a1a style C fill:#fff3e0,stroke:#e65100,color:#1a1a1a

This design means the entire system can be inspected, debugged, or recovered by reading plain JSON files. No migrations, no schema versions — just data.