PROJECT / 06 FEATURE ARTICLE

CodexAutopilot

TYPE AI OrchestrationSTATUS active

An autonomous orchestration layer for Codex that advances a sprint one reviewed task at a time, with explicit scope and stop boundaries.

01 Project overview

A thin orchestration layer

Codex Autopilot builds on Codex with ChatGPT, the task-level workflow where work is planned, executed through Codex, independently reviewed, and repaired or recovered within one task. Autopilot carries an approved sprint across bounded stages called Gates, deciding whether to advance or stop after each reviewed task.

The implementation is deliberately small: a policy and orchestration skill with no hosted application. Autopilot owns sprint-level continuation; the task layer owns each bounded task through execution, review, repair, and recovery.

02 Responsibility boundaries

Two layers, one task owner

  • Autopilot
  • Sprint Envelope
  • Bounded Gate selection
  • Continuation between completed Gates
  • Sprint stop decision
  • Task layer
  • Readiness
  • Planning
  • Execution
  • Independent review
  • Repairs within the task
  • Recovery state

The task layer owns the current bounded task through execution, review, repair, and recovery. Autopilot does not take over an executing Gate; it chooses what follows only after that Gate’s reviewed task is complete.

03 Engineering choice

Separate sprint orchestration from task execution

CHOSEN

A thin sprint-orchestration layer above reviewed tasks

NOT CHOSEN

A second task planning and execution protocol

The task layer already owns readiness, planning, execution, independent review, repair, and recovery. Duplicating those responsibilities would create competing responsibilities and state models.

Autopilot advances only between completed Gates.

04 Sprint sequence

One reviewed task per Gate

  1. 01

    Explicitly invoke Autopilot

    Ask to use Codex Autopilot for the sprint. Establish task-layer readiness before Gate 1.

  2. 02

    Define the Sprint Envelope

    Set the goal, allowed scope, constraints, success criteria, and exclusions or stop conditions.

  3. 03

    Select one bounded Gate

    Choose the next task within the approved envelope, using the sprint’s current progress.

  4. 04

    Run one reviewed task

    Each Gate contains one complete bounded task, including planning, execution, and independent review.

  5. 05

    Keep repairs inside that Gate

    Repairs remain part of the same task and Gate; they do not create a new Gate.

  6. 06

    Complete review before advancing

    Finish the current task’s review and any in-scope repairs before a later Gate can begin.

  7. 07

    Evaluate, advance, or stop

    Check the sprint criteria. Select the next in-scope Gate, finish when the goal is met, or stop at a required boundary.

05 Operating constraints

Autonomy with explicit boundaries

Autopilot requires an explicit invocation or a clear request to use it for a sprint. Ordinary requests such as “continue,” “finish this,” “do it,” or “automatic,” and Goal mode alone, do not authorize Autopilot.

Before Gate 1, task-layer readiness must be established. Existing task context and recovery state are reused where available; task setup and recovery remain task-layer responsibilities.

The Sprint Envelope bounds the goal, allowed scope, constraints, success criteria, and exclusions or stop conditions. Ordinary implementation bugs, test or build failures, and review-requested repairs can continue inside the approved Gate and envelope.

Autopilot stops when success criteria are met or progress requires a material product or architecture decision outside the envelope, meaningful scope expansion, approval for a destructive or irreversible action, or a security/privacy judgment. Credentials, login, CAPTCHA, 2FA, consent, task-level iteration or blocking limits, and genuine external dependencies also require a stop. Required human authorization remains binding.