VMAO — the default loop

VMAO is the default coordination loop — the one a session runs under when nothing else is selected. It is a generator-critic loop: a planner breaks the goal into sub-tasks, workers execute them, validators grade the results, and the loop either replans with that feedback or synthesizes a final answer. Most work fits this shape, which is why it is the fallback the other loops specialize away from.

This page explains the loop’s structure. For how a loop is chosen, see Coordination loops.

The four phases

Rendering diagram…

VMAO drives a session through fixed phases, replanning until verification is satisfied

PLAN. The planner is a reasoning role that runs in-process in the orchestrator — it is the one tier never dispatched to a worker. It reads the goal, decomposes it into a set of sub-tasks, and emits a structured plan. No agent tool loop runs here; the planner reasons and hands the plan to the coordinator.

EXECUTE. The coordinator dispatches the plan as two waves separated by a hard barrier. Wave one runs the non-validator members — the workers (and any synthesizer). The barrier collects their outputs. Wave two runs the validators, because a validator’s target is a peer worker’s output, so it cannot start until wave one has produced something to grade. Every wave passes through the governed dispatch path: a per-wave budget carve, a bounded-concurrency window, and per-member resume.

VERIFY. The validators’ verdicts are aggregated. A satisfied result proceeds to synthesis; an unsatisfied one re-enters PLAN with the failure feedback so the next plan addresses what fell short.

SYNTHESIZE. Once verification is satisfied, the loop composes the sub-task outputs into one session-level result and terminates.

Bounded replanning

The replan edge is not open-ended. VMAO carries two distinct caps — one on replan iterations, one on coverage iterations — each with its own failure signal, so an operator can tell why a session stopped. Exhausting a cap flows through the stall path, which can pause for human input rather than silently looping. Loop position is checkpointed at each barrier, so a crashed session resumes at the last barrier, never at round zero.

A grant is durable the moment you make it. When you approve more iterations at a stall, the raised ceiling is checkpointed at the grant — not at the next planning barrier. The gap between those two points is a full planning dispatch wide, so a restart inside it used to discard a decision the operator had already made, and the session resumed under the old cap as though nobody had answered. The grant raises the ceiling, never the counter, so the loop continues from the paused iteration rather than restarting it.

Variants of the same skeleton

VMAO is one skeleton with a variant seam: a strategy plugs domain-specific behavior into the fixed phases without reordering them. Two ship today:

• The generic strategy — arbitrary goals with a general-purpose decomposition prompt. This is what a plain SessionKind::Generic session runs.
• The Deep Research strategy — the same loop with research-specific planning, worker, validator, and synthesizer roles. See Deep Research.

The evaluator-optimizer loop is a third strategy on this skeleton — it maps generate → evaluate → refine directly onto PLAN → EXECUTE → VERIFY → REPLAN.

When to choose it

Reach for VMAO when the work decomposes into sub-tasks whose results need checking — research, multi-step analysis, anything where a first attempt should be verified and revised. It is the general-purpose default; the other loops are specializations for when the work has a sharper shape (a single artifact to refine, a question to sample, a claim to debate).

Where this shows up

• Build: Deep Research is the worked VMAO domain.
• Reference: the orchestrator’s session coordinator and the substrate vmao module under Reference.