One thread runs the whole loop. A fresh subagent reviews every change.

Run the thread anywhere. Let it start its own subagents.

Run the conductor wherever you already work with your agent — the Claude desktop app, Claude Code in a terminal, or inside an Orca Run. The reviewer subagents are started by that thread itself, inside the same session. That is what makes it efficient: there is nothing else to launch, keep alive, or wire together, and the reviewer still sees only what it should.

• Using Orca? Record the Run you already use for the solo team with intent-cli session-layer topology record-orca-run. intent-cli never runs orca or creates a Run.
• The runtime must be able to start an isolated subagent. If yours cannot, use a multi-seat team, where review has its own seat.
• intent-cli never starts or manages an agent. It renders the contract, checks the gates, and records what the thread did.

Ten steps per unit, one unit at a time

intent-cli guide solo-conductor gives the thread this loop with the exact intent-cli, gh, and git commands for each step. You don't run them; the thread does.

While CI and the full test suite run in the background, the thread investigates the next unit. A CI wait is bound to the head SHA and the run attempt, never to whatever ran last on the branch.

Have another model family check the work

Declare the team under [[cross_runtime_review.teams]] in .intent-cli/config.toml. On the repositories that declaration lists, the thread records a verdict from the conductor's runtime and one from a different runtime (Codex, Claude, Cursor, Copilot, or OpenCode) against the PR's current head, and approval is refused until that gate is satisfied on that head. Publishing an issue through publish-flow likewise needs a design verdict on the packet. Both reviews run as the command lines intent-cli renders, in read-only clones; the thread launches them and records the verdicts.

The guide advises a reviewer model from a different vendor and model family than the conductor's; the gate does not check this. These gates keep an honest workflow honest and are not a security boundary — gh pr merge itself is not gated.

Install, then hand this to your agent

npm i -g intent-system

Open your coding agent in the repository and paste:

Set up intent-cli in this repository as a single-seat solo-conductor team.
Follow intent-cli's host initialization guidance (dry-run first) and ask me the decisions that are mine.
Before recording team_mode, confirm every intent-cli that reads this host is v0.32.0 or later.
Record team_mode=solo-conductor, confirm guide bootstrap reports solo-conductor-complete,
then run the first unit with intent-cli guide solo-conductor.
Start a fresh subagent for every review, and check with me before publishing an issue or merging.

On a host that is already set up, the short trigger phrase is: “Run this work as a solo conductor.”

What the agent runs

1. intent init — dry-run first, then --write.
2. intent-cli team-mode set --domain <domain> --team <team> --mode solo-conductor --write
3. intent-cli guide bootstrap — it reports solo-conductor-team-bootstrap in state solo-conductor-complete, then asks you to accept the model and checks repository access, claims, and that the runtime can start an isolated reviewer.
4. intent-cli guide solo-conductor — then the loop above, one unit at a time.

Sharing the host with other machines or seats? Upgrade every intent-cli that reads it to v0.32.0 first. An older intent-cli rejects a team-mode.json that contains solo-conductor, and the whole file then fails to load for every team on that host.