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.