The Loop pane: Loop, Graph & Super

Open with open loop. The pane now has three ways to work, picked with the tabs at the top:

• Loop — the classic: one agent, one goal, judged passes until it clears your bar.
• Graph — a pipeline of specialized stages (plan → research ∥ build → integrate → test ∥ review → document), judged at the end, with targeted fixes: the judge’s critique re-runs only the stages it implicates (and what depends on them), never the whole pipeline. Stages run on your agent windows, or on headless workers — sub-agents with no window of their own — so the shape of a graph is no longer limited by how many windows you have room for.
• Super — the graph where each worker stage also self-refines a bounded number of times before handing off. Loops inside a graph: the highest quality per stage, at the highest spend.

A loop takes a goal (“punchy hero copy”, “make the tests pass”), sends an agent at it, has a judge score the result, feeds the critique back, and goes again — until the score clears your bar or the iteration cap trips. The concept doc explains the methodology; this pane is where you run them.

Loops with a crew

A refine loop is one agent doing the whole goal every pass. Tick Run it with a crew and the agent you picked becomes the orchestrator: each pass it splits the work into independent pieces, assigns each to a crew member, waits for them, and merges the results into the single artifact the judge scores. Everything after that — judging, the confirming reviewer, the plateau detector, cascades — is unchanged, which is why this is still a loop and not a graph.

You choose the crew; the orchestrator chooses the assignment. Tick the agent windows and headless workers it may use. It decides who does what and how to split the work, but only within that list — an assignment to anyone outside it is refused rather than honoured, because your list is what bounds what the run can spend. Headless workers count, so a five-way split doesn’t need five windows.

Budget for pieces + 2 agent runs per pass instead of one: the split, the pieces themselves, and the merge. Most pieces per pass caps it, and there’s a hard ceiling of 8 regardless.

Pieces that can run at once do; two pieces given to the same crew member run one after the other, because one window is one CLI.

When a crewed pass isn’t crewed

Four things can go wrong, and each falls back to the orchestrator doing the pass alone rather than failing the loop: nobody on the crew is reachable, the orchestrator doesn’t answer, its split can’t be read, or every piece fails. A merge that fails is different — the pieces are real work, so they’re joined in order instead of thrown away.

Every one of these is written onto the pass, in yellow, along with anything else that was repaired — a dropped assignment, a truncated split, a crew member whose window closed mid-run. A crewed pass and a solo pass produce artifacts that look identical, so the note is the only place the difference is visible. Expand any pass in the history to see who was asked to do what.

Graphs: setting one up

The fastest entry: type or say graph: <objective> — the pane opens in Graph mode with the objective prefilled (it never auto-runs; you still read the estimate and press Start). Or set it up by hand:

1. Write the objective and pick a pipeline (Quick build · Build & ship · Research & write).
2. Tick 1–3 worker windows. Stages that don’t depend on each other run in parallel across windows — two windows genuinely halve the wall clock on the parallel stretches; one window runs the same pipeline serially.
3. Pick 1–3 judges. With several, they score in parallel and the weakest score gates — the fix round addresses every judge’s critique at once (each critique arrives attributed).
4. Optional: let the planner add stages (up to a cap you set, 0–3). If the goal genuinely needs a stage the pipeline lacks — say a benchmark pass — the planner may propose it; the engine sanitizes and wires it in, the board shows it, and the addition is disclosed up front on the estimate card.
5. Optional: Pause for my approval after the main build. The run parks with the deliverable on screen — Approve continues to the check/document stages; Request changes sends your note back exactly like a judge critique (only the implicated stages re-run). Waiting for you never burns the time budget.
6. Set the quality bar and the budgets: judge rounds, time, and cost.
7. Read the estimate card — expected stage runs, tokens, a low→high cost band, and an ETA, plus a plain-language line about what the quality bar means. A bigger run asks you to tick an acknowledgement first: nothing big builds without you seeing its cost, time, and quality expectations.
8. Start. The board shows every stage live — waiting · running · ✋ your call · done · failed — with attempts, per-stage scores (Super), and running spend against your budgets.

How a graph converges

The judge scores the integrated result 0–10 and the engine routes deterministically: clear the bar → done; just under → re-run the stages the critique names; well under → redo the build stage; far under → re-plan. Each fix round re-runs only affected stages plus what depends on them. Anti-runaway guards are always on: per-stage timeouts, the round/time/cost budgets, and a plateau detector — if a fix round barely changes the result, the run ends with the best version instead of burning budget. A stopped or budget-capped run still hands you the best result so far.

Setting up a loop

1. Give it the goal and pick the agent that will do the work.
2. Set the target score and max iterations (the guardrails).
3. Start it — each round shows the attempt, the judge’s score, and the critique that seeds the next round.
4. Templates cover common loops (copy polish, test-fixing, refactor passes) so you don’t write the scaffolding each time.

While it runs

Everything about a run lives in its own window. Stop any loop manually whenever the latest attempt is good enough for you, whatever the judge thinks.

All loops at the bottom of the window lists every loop in the workspace — including ones whose window you closed — with its status, latest score and progress, and buttons to stop, re-run, open or delete each one. Collapse it when you don’t need it. If you close every Loop window while a loop is still running, a small chip appears in the bottom-left corner; click it to open the window again.

The Run Monitor

Once a run starts, a panel appears under the goal showing what it’s doing. It shows the shape of the run rather than repeating the pass list further down the window.

Colour means the same thing everywhere in it: green succeeded, red failed, yellow wants attention — being judged, retrying, or waiting on you — and grey hasn’t started. Yellow is also the only state that moves, so something needing you is visible without reading anything.

For a loop, two views you can switch between:

• Track draws the pass as a figure-eight: the right lobe is the agent working, the left is the judge, and the crossing in the middle is the confirming judge — the gate every pass has to get through. The marker sits wherever the pass currently is.
• Rings draws one ring per pass, growing toward a dashed line that marks your bar. It answers the question the track can’t: whether passes are creeping toward the bar or stalling short of it.

A pass with a blocking defect shows red even at a high score — “9.6 but wrong” isn’t shippable, and a number on its own can’t tell you that.

For a graph, the stages appear as a constellation, laid out left to right in dependency order so anything on the right is waiting on something to its left. The bar underneath has one segment per layer; a segment only turns green when every stage in that layer succeeded, so one failure colours the whole layer rather than hiding behind its neighbours.

Underneath either one is the line that does the most work: stages done, round, and spend against your budget — plus how the run ended once it has. If the window says “Best effort kept”, so does the monitor.

Quality-gate rubrics

Grade each pass against a rubric instead of a generic judge — say loop: polish the landing copy using the readability rubric. Built-in rubrics cover SEO, readability, brand fit, and code / tests pass; each carries a default bar so “nothing ships below it” is baked in (you can still set your own until score N). The judge scores against that rubric’s checklist and tags each fix to the item it serves.

Good to know

• Loops reuse the same judging machinery as the Model Council — scores are per-dimension, not vibes.
• Every round consumes real agent usage; the iteration cap is your budget control.