flow

flow

The default build flow for a request the working rules sized M or L. You stay on the main thread: research runs on cheap subagents, the user settles what only they can, you build (L: through tiered workers), and one ac/oracle reviews the result. No plan file is written. /ac/plan and /ac/coordinate start only when the user asks for them.

Standing rules

These hold for the whole run and sit before the procedure so a compaction keeps them.

• Sizes are the working rules' S, M and L. Between two sizes take the larger; when research changes the picture, resize and say so in one line.
• Spend. Research runs on ac/explore (this repository) and ac/librarian (anything external), building on ac/plan-worker-*, review on ac/oracle. Never a general-purpose agent: it is the costliest way to run a slice.
• One message per fan-out. Every independent subagent call of a phase goes out together. Each brief names one angle; two angles are two briefs.
• Research subagents (phase 2) run in the foreground: send every angle in one response without background, and their reports return as tool results in that same step. A background subagent costs the main session one extra step when it finishes: one more pass over the whole context, billed in tokens.
• Build workers (phase 4) and the review (phase 6) run with background: true. After that fan-out, end the turn with a one-line status; each completion arrives as a notification that starts your next turn, and when one arrives while others still run, end the turn again. Never wait with a sleep or until loop, a file-stability check, or repeated reads of an output file.
• A subagent report is a claim. Open what it cites before it changes a decision.
• The review in phase 6 is the only reviewer. Do not spawn an agent to re-check your own work.
• Ceiling. More than six slices, or work that will not finish in this sitting: stop before phase 4 and ask once with question whether to continue here or to hand the work to /ac/plan or /ac/coordinate. Do not start either yourself.
• A failed subagent moves down its model chain; it is not a question. A subagent call that comes back with a provider failure (Subagent failed (sessionID: ...), a <subagent ... state="error"> message, an error such as provider.invalid-output) or with no answer at all (Subagent completed without a text response., an empty report) failed on its model, not on the work. Recover by continuing the same child, not by a fresh spawn: call the subagent tool again with the same agent, sessionID: "<the sessionID from the failure text>" and the prompt Your last turn stopped on a provider error. Continue the task from where you left off without repeating finished work., so the child keeps everything it already read and wrote (a fresh spawn repeats all of it). When it answered nothing or broke off mid-stream (provider.invalid-output, an empty report), continue it on the same model until it has run retryAttempts times there (from the ac_models tool, 3 in the shipped config), since that is often a one-off; a 5xx was already retried inside the call, so it goes straight on. Then call ac_fallback_next({ tier: "<the agent name without ac/>", tried: [<every model this call ran on>], session_id: "<the sessionID from the failure text>", status: <the HTTP status, when the error carried one> }), with tried starting at the agent's chain head from ac_models unless you set its model yourself, continue the same child with model: "<the returned value>" as well (the child switches to it and keeps its context), and give that model the same number of attempts. A rate limit was retried 10 times inside the call, and the plugin gives one model 30 across continuations: wait:<seconds> means that model has retries left, so wait that long with one shell sleep and continue the child on the same model with tried unchanged. The tool bounds those waits itself. Start a fresh spawn with the full prompt only when the continuation is refused (Subagent session not found, is not a child of the current session) or the child's context overflowed. Only none, every entry of the chain tried, is a failure to report or ask about. Asking the user whether to retry wastes a round on a provider fault the chain exists to absorb.