The pipeline is what turns a single prompt into a reviewed, tested, merged change. Here's what happens at each of its 9 steps, and how to recover if one of them gets stuck.

The Pipeline

The 9 steps

1. Branch / worktree — AITM creates a new git branch and an isolated worktree so this task's changes can't collide with any other task running in parallel.
2. Architect — an AI session reads your prompt and the relevant code, then designs an implementation plan: which files change, and how.
3. Code — the same AI session that wrote the plan implements it, so there's no context lost translating a plan into code.
4. Review — a fresh AI session reviews the diff and returns a verdict. If it's LGTM ("looks good to me"), the Fix step is skipped entirely.
5. Fix — if Review found issues, this step applies the requested changes. Only runs when needed.
6. Test / E2E — unit tests and end-to-end tests run in parallel, against an isolated instance of your app spun up on its own port, so testing this task never interferes with your normal dev instance.
7. Snapshot — (optional, off by default) captures screenshots of the UI after testing, for a visual record.
8. Docs — documentation and behavioral contracts affected by the change are updated to stay in sync with the code.
9. Merge — the finished branch is merged into dev. If a conflict comes up, AI resolves it automatically where it safely can.

What runs in parallel

Test and E2E run simultaneously once Fix completes, roughly halving total pipeline time. Snapshot waits for both to finish, and Docs always runs last.

Watchdog

A background watchdog monitors every running step. If a step goes stuck or its AI process becomes an unresponsive "zombie", the watchdog detects it and automatically retries that step — up to 3 times — before flagging it for your attention.

The merge queue

Merges into dev are serialized one at a time by a merge queue, so two tasks finishing at once can never race each other. On a genuine conflict, AI-assisted resolution is attempted first; only conflicts it can't safely resolve are flagged for your manual attention.

Agents: what actually runs each step

Every AI-driven pipeline step (Architect, Code, Review, Fix, and a few others) is executed by an agent — an AI console session running headless, exactly the way an interactive AI CLI session would, but launched automatically and given that step's own instructions and the task's isolated worktree as its working directory. There's no separate execution engine for agents; it's the same kind of session you'd get running an AI coding assistant from a terminal yourself, just triggered by the pipeline instead of by you typing a command.

It helps to keep the two concepts distinct: the pipeline is the orchestrated 9-step state machine — it decides step order, retries failed steps via the watchdog, and serializes merges through the merge queue. An agent is the individual AI session the pipeline launches to actually do one step's work; each step gets its own fresh agent session with only that step's context. You can configure which AI provider and model each step's agent uses independently — see Settings for per-step provider/model configuration.

Resume from step

If a pipeline does stop (say, you paused it, or a step needed manual input), you don't have to restart from scratch. Resume it from the exact step it left off at, and it continues forward from there.

Reading task results

Once a task finishes, its result view shows the full write-up, files changed, per-step verdicts, and cost breakdown — see Reading Results & Archive for the full breakdown of verdicts, failures, and the Archive.