Loops & Councils

LoopReview and Council are two specialized buildings for getting better answers out of agents than a single model in a single chat would give you. LoopReview iterates a draft against a reviewer until it converges; Council runs several models in parallel and synthesizes the result.

This page covers both buildings together because they’re often considered side by side — pick LoopReview when you want depth (revision over rounds), pick Council when you want breadth (multiple opinions in one shot).

At a glance

	LoopReview	Council
Default agents	Loop Orchestrator, Drafter, Reviewer	Council Orchestrator, Member A, Member B, Member C
Best for	Iterative artifacts that improve over rounds: drafts, designs, plans	One-shot decisions where multiple perspectives are valuable
Skills it ships with	/iterate	/convene
Place from	Building Type Drawer → LoopReview	Building Type Drawer → Council
Shape of output	One artifact, multiple rounds, visible round counter	One synthesis combining N parallel opinions
Tracked in	Loop Tracker panel (toggle with Cmd+Shift+L)	Single-pass conversation in the Council Orchestrator

How It Works

LoopReview

A LoopReview building runs a drafter-reviewer loop. The Drafter produces a draft. The Reviewer reads it and writes a review. The Loop Orchestrator decides whether the review’s asks are addressed yet — if not, the Drafter revises and the cycle runs again. Loops run for up to five rounds before stopping; you can stop them earlier from the Loop Tracker.

Each round produces a concrete artifact you can read. The output of round 3 is a real file on disk you can open, not an internal thought. If you want to abort after round 2 because the artifact is already what you wanted, you can. If you want to keep going past five rounds, start a new loop from the latest draft.

LoopReview is the right shape for work that gets better with revision: long-form documents, complex designs, plans with subtle trade-offs, anything you’d normally write a first draft of and then improve.

Council

A Council building runs N agents in parallel against the same question and then synthesizes. By default a Council has three Members (A, B, C). Each Member is configured with a different model and (usually) a different prompt — that’s the point. The Council Orchestrator takes your question, sends it to every Member in parallel, collects their answers, and produces a final synthesis that explains where the Members agreed, where they disagreed, and which answer to take.

You see the Members’ raw answers in the Orchestrator’s conversation, then the synthesis at the bottom. Nothing is hidden. The synthesis is the Orchestrator’s reading of the Members’ work, and you can argue with it if you don’t agree.

Council is the right shape for decisions where one model’s blind spot might matter: architecture choices, contentious calls, anything where you want to hear “would model X also say this?”

Default agents

LoopReview agents

• Loop Orchestrator. The Orchestrator drives the loop: hands the brief to the Drafter, hands the resulting draft to the Reviewer, reads the review, and decides whether another round is needed. Talk to the Orchestrator to start a loop with /iterate, to change the goal mid-loop, or to ask “is this converging?”.

• Drafter. The Drafter writes (or revises) the artifact. Talk to them directly only if you want to tweak a specific round’s output outside the loop — the normal pattern is to let the Orchestrator route work to them.

• Reviewer. The Reviewer reads each draft and produces structured feedback. Same rule: most of the time, talk to the Orchestrator; talk to the Reviewer directly only if you want to shape the review criteria for the next round.

Council agents

• Council Orchestrator. The Orchestrator dispatches the question, waits for the Members in parallel, and writes the synthesis. Talk to the Orchestrator with /convene to run a council, or with a plain message to ask follow-up questions on the result.

• Member A, Member B, Member C. Three independent Members, normally configured on different models (and often with different prompts). Each answers the question in isolation; they do not see each other’s answers. Talk to a Member directly only if you want to probe one specific answer.

Configuration

LoopReview

From the Building Window:

• Round limit. The default ceiling is 5 rounds. You can lower it (a 2-round loop is fast and useful for short artifacts) or raise it for harder problems.
• Drafter and Reviewer prompts. The two agents have separate prompt overrides. A common pattern is to give the Reviewer a strict checklist and let the Drafter run with a freer prompt.
• Per-agent models. Drafter and Reviewer don’t have to be on the same model. Strong reasoner for the Reviewer, fast model for the Drafter, is a common shape.
• Skill enablement. /iterate is on by default.

Council

From the Building Window:

• Member count and identity. Three Members is the default; you can add more (or fewer) from the building’s agent list.
• Per-Member models. This is the main lever. Set each Member to a different model so the synthesis actually reflects different perspectives. A Council where all three Members run on the same model is just a load test.
• Per-Member prompts. Optional, useful when you want each Member to come at the question from a different angle (for example, “argue for performance,” “argue for simplicity,” “argue for cost”).
• Skill enablement. /convene is on by default.

Typical workflows

LoopReview workflow

1. Place LoopReview in a project where the artifact will live.
2. Open the Loop Orchestrator. Describe the goal and the initial brief, or invoke /iterate and let it prompt you.
3. The Orchestrator dispatches the brief to the Drafter, then the resulting draft to the Reviewer. You see both messages in the conversation, and a round counter ticks up.
4. The Reviewer’s feedback goes back to the Drafter for revision. The loop continues until the Orchestrator judges the asks satisfied, or you hit the round ceiling, or you stop it.
5. Open the Loop Tracker panel (toggle with Cmd+Shift+L) to see all active loops at a glance.
6. When the loop finishes, the final artifact is on disk in your project folder.

Council workflow

1. Place a Council in a project. Configure the three Members on three different models (this is the whole point of using one).
2. Open the Council Orchestrator and invoke /convene. Provide the question — short and crisp helps.
3. The Orchestrator dispatches the question to all three Members in parallel. You see each Member’s answer arrive in the Orchestrator’s chat as it lands.
4. Once all Members have answered, the Orchestrator writes the synthesis: where the answers agreed, where they disagreed, and a recommended path.
5. If you disagree with the synthesis, argue with the Orchestrator. The raw answers are still visible — you can refer back to them.

Limitations

• LoopReview is bounded to 5 rounds by default. If your artifact still isn’t converging by round 5, the problem is probably the brief or the Reviewer’s criteria, not the round count. Edit one of those before bumping the ceiling.
• LoopReview writes one artifact at a time. If you want two parallel drafts compared, that’s a Council shape, not a Loop.
• Council runs members in parallel, so it costs N times a single chat (one call per Member). Plan around the Token Tracker accordingly.
• Council Members do not see each other’s answers. If you want Members to argue, that’s a Loop with multiple Reviewers — there is no built-in “debate” mode.
• Both buildings rely on the underlying CLI providers being reachable. A model that’s rate-limited will stall a Member or a Loop round.
• Neither building writes code or runs research by itself. They’re scaffolds for deliberation. Pair them with a building that does the actual work — for example, point a Loop’s Drafter at PRD output from CodeForge’s Planner, or have a Council weigh in on a Researcher’s notes.

Related

• Loop Tracker — the panel that shows active loops, their rounds, and lets you stop them.
• Workflows: Loops, Councils, PRDs — the mental model behind both buildings.
• CodeForge — common pair: have a Loop refine what a Planner drafts, or a Council weigh in on a Reviewer’s call.