The Loop

The Loop

build-loop routes work through a lead orchestrator, invokes bounded subagents with scoped context, and accepts output only after verification. The loop is Assess → Plan → Execute → Review → Iterate (5× max) → Learn, where Review runs seven ordered sub-steps and Iterate loops back to Review on failure.

Phases and agent obligations

Phase	Agent obligation
Assess	Read live repo state, tooling, memory, Rally, and current docs. Define the goal and pass/fail criteria.
Plan	Produce a dependency-ordered plan with MECE file ownership, validation gates, and approach tradeoffs.
Execute	Implement the accepted plan. Keep edits scoped to owned files.
Review	Run critic, validate, fact-check, simplify, auto-resolve, and report steps.
Iterate	Fix review failures until pass or a real blocker is reached.
Learn	Always emit the Learn outcome and capture durable lessons when warranted.

Phase 2 — Plan-verify gate

Phase 2 plans pass through a deterministic plan-verify gate (scripts/plan_verify.py) before acceptance, then an adversarial plan-critic for the non-deterministic checks grep cannot catch — alternatives considered, MECE scope quality, marker adequacy, and headline drift. A scope-auditor enforces the Plan→Execute boundary: every commit that changes a public signature must either confirm internal_only or list the missing caller files.

Review sub-steps

Review runs in order. Iterate re-enters Review on any failure:

1. Critic — adversarial read of the implementation.
2. Validate — tests / deterministic checks / runtime smoke / deploy verify.
3. Optimize — opt-in metric loop.
4. Fact-Check — trace every rendered metric and claim to its source.
5. Simplify — reuse, clarity, altitude cleanups.
6. Auto-Resolve — fold safe fixes back in.
7. Report — scorecard marking every acceptance criterion ✅ / ⚠️ / ❓.

Multi-model by tier

Each role maps to an abstract tier — Frontier / Thinking / Code / Pattern — and any model that meets the tier's benchmark contract can fill it. The Anthropic mapping is the fresh-install default; equivalents from other providers substitute when their benchmarks meet the tier contract.

Selection runs on two axes: a work-role segment (Generative Reasoning, Agentic Execution, Representation/Retrieval, Governance/Evaluation, plus dormant lanes) and a seven-rung capability tier ladder (T0–T5, plus T-S for specialist infrastructure), both encoded as data in references/model-taxonomy.json — the durable source of truth.

The (segment, tier) role is the key into that index. An agent's model: frontmatter is an index-derived recommended fallback kept in sync by scripts/sync_agent_model_defaults.py (never hand-edited). At dispatch the orchestrator resolves the role live through scripts/resolve_agent_model.py and overrides the frontmatter, so the running model always reflects the current index plus availability.

Availability-aware resolution: a model observed unavailable at dispatch (a provider outage) is recorded so the role falls back to the next host-reachable model in its tier — a frontier/judgment role degrades at most to the thinking tier, and a model the current host cannot dispatch is never offered. Outage records carry a timestamp and auto-expire after a TTL (BUILD_LOOP_OUTAGE_TTL_SECONDS, default 1800s).

What you observe at runtime

The agent prints a short status line per phase ([Phase 1: Assess], [Phase 2: Plan], [Phase 3: Execute], then each Review sub-step), and ends with a scorecard marking every acceptance criterion ✅ / ⚠️ / ❓. Completed, verified work is committed automatically. The only human-confirmation gates are production push, irreversible delete, and major user-impacting decisions.