Helix Phases
Every Operator run proceeds through five phases. The boundaries are explicit in the event stream and visible in the workspace panel.
1. Recon
Helix gathers context before it plans. It may read files, list directory contents, run git status, inspect package manifests, or query APIs you have connected.
Recon is read-only. It never writes to the workspace or triggers deployments.
2. Plan
Once Helix understands the goal and the workspace, it produces a TaskList. Each task has:
- A clear description.
- A target tool or a broad objective.
- Completion criteria the controller can evaluate.
If the plan contains risky steps, Helix renders the ApprovalCard and waits for your response before execution.
3. Execute
Helix picks the first unblocked task and invokes the right tool. Tools can be:
- Sandbox tools — read, write, run commands, git operations.
- Build/test tools —
run_tests,run_linter,run_build,run_typecheck. - External tools — issue creation, MCP provider calls, web search.
Each tool result is an observation. The controller uses the observation to advance or fail the task.
4. Evaluate
After each observation, Helix evaluates whether the task is complete, whether it needs to retry, and whether the overall goal is still achievable.
- If a test fails, Helix reads the failure and decides how to fix it.
- If a command produces unexpected output, Helix may adjust the next step.
- If progress stalls, the stuck detector pauses the run and asks for help.
5. Synthesize
When the task list is complete, Helix calls helix_finish and produces a final message. The message includes:
- A summary of what was done.
- Key files changed.
- Test or build results.
- Anything that still needs human review.
Loop recovery
Helix does not hide failures. If a step cannot be completed, the run status becomes stuck or error and the workspace shows the tool output. You can resume with additional instructions or reject the plan and start over.