The loop engine

The loop engine is what makes the stages one governed loop rather than a line of features. It owns four things: the project-level loop object and its numbered iterations, the canonical stage-transition table every surface enforces, checkpoint policy, and model economics. Its guarantee: every transition is validated against one law, every gate evaluation is audited — including autonomous pass-throughs — and budget stops are visible stops, never silent downgrades.

The loop object and iterations

Each project has one loop with an iteration counter — the header reads “Loop 12 · running · 3 agents”. An iteration opens when an intent activates and closes when every epic promoted within it settles and its learnings have seeded. The closing summary answers “what did loop 12 do”: score delta, epics shipped, learnings seeded, spend.

The loop can run in manual or continuous mode. In continuous mode, merge and iteration-closed events are exactly the triggers standing intents subscribe to — the loop turns itself. Pause blocks autonomous pass-throughs and new work while in-flight work finishes; approvals decided while paused apply on resume.

One transition table

The permitted stage edges — seven forward, five loop-backs — live in one versioned table. Client state machines derive from it and server mutations validate against it, so an illegal transition is rejected and audited no matter which surface attempted it. Attribution is by provenance, not wall clock: a work unit belongs to the iteration of its owning chain, even when iterations overlap.

Checkpoints and the autonomy dial

Every consequential transition passes a named gate:

Three modes per gate:

• Require approval — the transition holds until a person (or an explicitly authorized agent) decides.
• Approve by default — an approval is created with a deadline (30 minutes by default); it auto-approves unless someone objects first, which converts it to blocking.
• Autonomous — passes through, still audited.

The autonomy dial — supervised, balanced, autonomous — sets every gate at once; any per-gate override moves the project to custom. Approvals are actionable everywhere: inline in the inbox, from the desktop notification, or stella approve <id>. The requester can never decide their own approval, and agents decide only where you have explicitly listed them.

Model tiers

Stages request a tier — frontier, standard, or economy — and the engine resolves the concrete model from your project’s configuration. Defaults: Plan runs frontier, Analyse/Propose/Implement run standard, Review runs a panel of three. Per-work-unit overrides exist for the cases that warrant them, and a missing model mapping is an error, never a silent substitution.

Every model-backed piece of work — analyzer runs, derivation, spec sessions, task sessions, review panelists — registers as a work unit, which is what powers the live “N agents working” count and per-run cost capture.

Budgets and costs

Budgets exist at three grains — per project period, per loop iteration, and per epic tournament — each with a warn threshold and a hard stop:

• Admission is checked when work starts; a hard-stopped budget denies new work while in-flight work finishes and records its cost.
• A tournament hitting its budget stops with best-so-far selection through the normal review gates.
• Cost is truthful: prices are snapshotted at admission, usage settles idempotently, and unpriced work is labeled unknown — never presented as $0.

Ask “what did loop 12 cost?” and the answer is a number: stella costs show.

Working with the engine