Skip to Content
ConceptsLoop Mode

Loop Mode

Loop Mode is Navigator’s “run until done” capability. Instead of nudging the session forward with repeated “keep going” prompts, you hand off a task and let Navigator iterate until it’s genuinely complete.

When you’d want it

Loop Mode is built for autonomous work — overnight runs, unattended CI tasks, or any job where you’d rather not babysit each step. You trigger it explicitly:

"Run until done: add user authentication"
"Keep going until complete"
"Iterate until finished"

It’s the opposite posture from Task Mode, which auto-detects and runs a single pass. Loop Mode keeps cycling.

The phases and the status block

Each iteration moves through phases:

INIT → RESEARCH → IMPL → VERIFY → COMPLETE

After every iteration, Navigator emits a NAVIGATOR_STATUS block — a structured completion signal that makes the loop’s state legible:

NAVIGATOR_STATUS
==================================================
Phase: VERIFY
Iteration: 3/5
Progress: 75%

Completion Indicators:
  [x] Code committed
  [x] Tests passing
  [ ] Documentation updated
  [ ] Ticket closed

Exit Conditions:
  Heuristics: 2/4 (need 2+)
  EXIT_SIGNAL: false

State Hash: a7b3c9
Stagnation: 1/3
==================================================

The exit gate

The loop exits only when both conditions hold:

  1. Heuristics — completion indicators met (committed, tests passing, docs updated, ticket closed, marker created…).
  2. Exit signal — an explicit declaration that the task is actually done. Signals may be HTML-comment-wrapped, so you never see them in the output.

Why both? Indicators can look satisfied while real work remains — code committed and tests green, but the feature only half-built. Requiring the explicit signal alongside the heuristics prevents that premature exit. If indicators are met but no signal is set, the loop continues; if the signal fires without enough indicators, the loop refuses to exit.

Through v6 these exit rules were prose mandates the model was asked to follow. As of v7 they’re mechanism: exit evaluation runs on the Stop event in the hook runtime — the stop_state op records indicators each turn, and the stop_completion op evaluates them (off-switches: workflow_state_hook.enabled, stop_completion.continue_enabled).

Stagnation detection

A runaway loop — spinning on a fundamentally stuck task — is the failure mode Loop Mode guards against. A state hash is computed each iteration; if it doesn’t change for several iterations in a row, the circuit breaker trips. What happens next depends on the run:

  • Attended runs pause and ask for input — the loop is likely blocked on an external dependency, unclear requirements, or a test it can’t get past.
  • Autonomous runs (overnight) don’t pause. They auto-diversify instead — combining previous near-misses, trying a radically different approach, or re-reading the in-scope docs for a missed constraint — then reset the counter and continue.

A hard max_iterations cap always applies, and repeated diversification eventually escalates to an abort, so even unattended loops can’t spin forever.

Conceptual lineage

Loop Mode adapts Ralph’s autonomous-loop framework to Navigator’s context-efficient architecture. The autonomous “never pause” behavior draws on autoresearch’s NEVER STOP directive: if you run out of ideas, think harder — re-read in-scope files, combine previous near-misses, try more radical changes — rather than stopping.

Task ModeKnowledge Graph