Project Autopilot
Software engineering work, on a plan you approved
Give Autopilot a goal and a repository. It drafts a plan, shows you the plan, and only then starts work — phase by phase, opening one pull request per phase, with your test suite as the gate. You review the plan before any code is written, and you review a PR before any code lands.
Download AWO See how a run works
Included in Pro. Off by default — nothing runs until you connect a coding agent yourself.
The problem with pointing an agent at a repository
Ask a coding agent for something large and you get one enormous diff, an optimistic claim that it is finished, and no way to tell which part to trust.
You cannot see the plan
The decomposition happens inside a prompt. If it decided to do the wrong four things, you discover that at the end, in the diff.
"Done" is a claim, not a fact
Most harnesses decide a task is complete by looking for words like "finished" in the model's own output. The model is grading its own work.
The context grows until it degrades
A single long-running conversation carries every previous step. Quality falls as the transcript grows, and an interruption loses everything.
How an Autopilot run works
Four stages, and you are in control at the two that matter — before the plan is accepted, and before any code lands.
You give it a goal
Plain language, against a repository you connect. Five presets cover the common shapes: fix a bug, add a feature, build a new project, keep the repo green, write or expand tests.
It drafts a plan — and you edit it
The goal is decomposed into phases with dependencies between them. You can add, edit, delete, reorder, split and merge phases before anything runs. A draft that does not validate is shown to you, never silently executed.
It works the plan, phase by phase
It picks the next phase whose dependencies are all done, runs that phase's cycles, gates on your tests, and opens one pull request. Then the next.
You review pull requests
One per phase, each a reviewable size, each already past a review cycle and your test suite. Nothing is pushed to your default branch.
The five cycles that do the work
A phase is not one prompt. It is a composition of cycles that run in order, each with its own model, prompt and iteration cap — and two of them are physically incapable of writing code.
Researcher read-only
Reports what already exists, what is missing, and which files the work will touch. It is told not to claim anything it cannot verify from what it was given.
Planner read-only
Sharpens the phase's intent and its acceptance criteria before anybody builds against them.
Builder
Writes the change and opens the pull request. The only cycle that produces one.
Reviewer gate
Reviews the diff. A failed gate means no pull request — the phase does not proceed on a review it did not pass.
Tester gate
Runs your suite. Failing tests send the work back to the builder, up to a limit you set.
Researcher and planner are read-only by definition. Not by configuration — a config cannot flip them to writable. They investigate and produce text, and the code path that writes files is not available to them.
The defaults work out of the box. If you want something else, a project can reorder them, attach more, or author its own — a security review cycle before the reviewer, a lint gate after the builder.
What "done" means here
This is the part most agent harnesses get wrong, and the reason Autopilot can be left running.
Completion is a fact about state
A run is complete when every phase in the plan is marked done with a landed pull request. It is a predicate over saved state — never a search for the word "complete" in something a model wrote about itself.
Each cycle starts fresh
The engine keeps a small durable record per phase, not a growing transcript. Quality does not decay across a long run, and an interruption resumes from state rather than starting again.
Truncation always says so
Wherever text is cut to fit a limit, it is marked. A shortened plan that looked complete would mislead you and the next model equally.
It cannot start on its own
Autopilot is the most powerful thing AWO does, so it is the most locked down.
Off by default
There is no default coding agent, no auto-construction and no environment-variable fallback. Until you supply one yourself, a project runs no cycles at all.
Pull requests, not pushes
Work lands on a branch and opens a PR. Your default branch is never written to, and every change goes through the review you already have.
An ephemeral workspace
Cycles run against a clone in a workspace that is created for the run, with timeouts, output caps and an audit trail — not against your working copy.
Scoped credentials
Repository access uses a scoped token for the run rather than your own credentials sitting in the environment.
The same engine as everything else
Autopilot is not a separate product bolted on. A phase plan is a graph — phases are nodes, dependencies are edges — and it is executed by the engine that runs every other AWO workflow.
That is why "pick the next phase whose dependencies are done" works at all, and why a phase can loop back from a failed test to the builder with a hard ceiling on attempts. Those are the same primitives the node types give you on a canvas. If you understand one, you understand the other.
Questions about Autopilot
Which coding agent does it use?
Yours. AWO does not ship one and will not pick one for you — you connect the agent you already trust, and it runs inside AWO's workspace with AWO's caps and audit trail around it. That is also why Autopilot does nothing until you have done that.
Can it push straight to my main branch?
No. The builder opens a pull request; there is no code path that writes to your default branch. Git writes are a separate permission from filesystem access, and both are off until you enable them.
What if the plan it drafts is wrong?
You fix it before anything runs — add, edit, delete, reorder, split or merge phases. That is the whole point of showing you the plan rather than acting on it. A draft that fails validation surfaces its problem for you instead of executing.
What stops it looping forever and running up a bill?
Every cycle has an iteration cap, and the test-to-builder loop is bounded by attempts, wall-clock time and spend. A run that cannot pass its gate stops and says so rather than trying indefinitely.
Can I stop a run once it has started?
Yes, including immediately after starting it — a cancel sent while the project is still loading is honoured rather than mistaken for a leftover signal from a previous run. State is saved after every step, so stopping is clean.
Is this how AWO itself is built?
The cycle model generalises the builder-and-reviewer loops used to build AWO, which is where the design came from — a long-running harness of exactly this shape, productised. The changelog is the honest record of how that has gone, defects included.
Do I need Pro?
Yes — Autopilot is a paid feature, at $12 a month. Everything else on the features page is in the free tier, so you can judge the engine before paying for the thing built on it.
Start with a workflow, then hand it the repo
Download free and build something small first. Autopilot makes far more sense once you have watched the engine run a graph you drew yourself.