Council and the three-tier adapter family

By now you have seen the loop hand one job to one assistant, and you have seen fusion ask a small panel the same question at once and have a judge merge the answers. Council is the next step up. It is a standing board of AI models — a configured group, each with a named role, a voting weight, and a cost budget — convened to decide the calls that are too important to leave to one voice.

The shape is deliberately like a real committee. Each member reads the question and the evidence, then casts a vote — GO, PIVOT, or NO-GO. The votes are weighted (a more trusted member counts for more), scored against the dimensions the board cares about, and folded by a synthesizer into one written verdict: a recommendation, how confident the board is, how much it agreed, and — crucially — the dissent that did not win, written down on purpose so it is never lost. The whole session retries if a member stumbles, stops if it blows its time or money budget, and is logged in full so a human can replay it later.

That last part is the point of Council, and what separates it from a quick panel: it is built for doctrine-level decisions — the rules and big bets a project lives by — and for acting as a heavyweight, consensus Validator when being confidently wrong would be very expensive. A person convenes the board for those moments. fusion is the everyday second opinion; Council is the one you call when the answer becomes policy.

Think of it like… a courtroom, not a hallway chat. fusion is asking three sharp colleagues in passing and taking the sense of the room. Council is a full panel of judges: each has standing and weight, each writes their opinion, the majority forms a ruling, and the dissents are recorded in the official record — because tomorrow someone will need to know not just what was decided but why, and who disagreed. Where the analogy bends: here the judges are AI models, the "ruling" is a JSON report plus a memo, and the entire hearing can be re-run from its transcript.

Here is the whole hearing in one picture. The same question goes to every member at once. Each returns a vote. The votes are weighted and scored, a synthesizer writes them up into a single verdict, and a separate verifier checks the claims before anything is signed. Notice that the verifier is an observer — it never votes on the outcome it is checking.

Council is more powerful than fusion, but power has a price: more models, more rounds, more time, more money. So you do not reach for it by default. The honest question is how expensive it would be to be wrong. If a mistake costs a few minutes to redo, a single check — or a quick fusion panel — is plenty. If a mistake would set a rule the whole project follows, or send a long autonomous run down the wrong road, that is when you convene the board.

An AI working inside the harness makes this same call constantly, and the rule it follows is exactly that: pick the lightest tool that fits the stakes. A routine unit gets one assistant. A risky or genuinely ambiguous fork gets fusion — a blind panel whose agreement is the strongest cheap signal you can get. A doctrine-level decision, or a verdict that must stand up to scrutiny later, gets Council. Spending a board's budget on a trivial question is as much a mistake as rubber-stamping a doctrine change with a single opinion.

Think of it like… deciding how serious a medical visit needs to be. A scrape is a bandage — handle it yourself. Something nagging gets a quick word with a couple of doctors who happen to be on shift. But a life-changing diagnosis goes to a full case conference where every specialist weighs in and the decision is documented. You match the ceremony to the cost of getting it wrong — not to how interesting the question feels.

Pick a situation, then press Next to walk the decision the harness makes. Each diamond is a yes/no question about the stakes; follow where a "no" peels off and watch which tool the path lands on — one assistant, a fusion panel, or the full Council board.

Step back from Council for a moment, because there is a second idea hiding under it — and under fusion too. Every one of these systems has to do the same humble thing: actually call an AI model's command-line program and read what comes back. That little piece of plumbing is called an adapter. And in this suite there is not one adapter but a family of them, in three layers, all driving the very same agent CLIs.

Why three? Because three different parts of the suite need to make the same call with different amounts of armor. The bash tier is what fusion uses — quick shell scripts that run a CLI and grab its output. The mjs tier is what Council uses — the same call, now wrapped with retries, cost tracking and an audit log, returning a tidy result object. The TypeScript tier lives in a product codebase and adds the heaviest armor of all — strict validation at the edges, a guarantee that it never crashes, a "circuit breaker" that stops hammering a failing service, and tests. Same destination, three thicknesses of safety belt.

The thing to hold onto: they all dial the same number. The exact, proven way to invoke each CLI — which flags, in which order — is shared across all three tiers. So when you learn how the harness calls Kimi or Codex once, you have learned it everywhere.

Think of it like… three vehicles built on one engine. A go-kart (bash) is light and fast and has almost no safety gear. A family car (mjs) adds seatbelts, airbags and a service light. A racing car with full telemetry (TypeScript) adds a roll cage, a kill switch and a pit crew watching every reading. Different jobs, different protection — but the same engine block, and if you retune the engine you retune all three.

Here is why the family matters, told as a small disaster. The exact way to call a CLI is fiddly — Kimi, for instance, refuses some flag combinations and silently fails on others. Once, that exact invocation drifted: someone tweaked it in Council's adapter and, separately, in fusion's table, and the two slowly fell out of step. The fix was a rule the whole suite now lives by: there is one source of truth for the proven headless invocations, and all three tiers must stay in step with it.

This is a perfect, tiny example of the loop's anti-assumption discipline applied to the plumbing. You do not remember how to call a CLI and hope it still works — flags drift between versions. You re-prove it against the live CLI, and when you change one tier you update the other two in the same breath. That is a job for an agent: when a flag drifts, re-prove it at the real boundary, then propagate the fix across bash, mjs and TypeScript so they never disagree again.

Think of it like… a recipe pinned in a shared kitchen. Three cooks work from it. The day one cook scribbles a change on their own copy, the dishes stop matching. The rule that saves the kitchen: there is one master recipe on the wall, every copy is checked against it, and you only change it after you have actually cooked the new version and it worked.

To make the middle tier concrete, here is the shape of a Council adapter. The detail that matters even at a glance: it never just returns text. It returns a Result — either a success carrying the answer, its cost and how long it took, or a failure that says what went wrong and whether it is worth retrying. That structure is what lets a board track its budget and write an honest audit trail.

export async function invoke({
  memberId, prompt, system = '', model = 'gpt-5.5',
  maxTokens = 128000, reasoningEffort = 'high',
  runId = null, timeoutMs = 300_000,
} = {}) {
  if (!prompt) return { success: false, error: 'prompt is required', retryable: false };

  if (process.env.COUNCIL_CODEX_USE_SUBPROCESS === '1') {       // optional CLI path
    const bin = CODEX_BIN_CANDIDATES.find(p => existsSync(p));
    if (bin) {
      const r = await withRetry(() => invokeSubprocess({ bin, prompt, system, model, timeoutMs }),
        { adapter: 'codex-cli:exec', model, runId, maxAttempts: 2 });
      if (r.success) return r;
    }
  }
  // default: route via cliproxyapi, with retry/backoff
  return withRetry(() => invokeProxy({ prompt, system, model, maxTokens, reasoningEffort, timeoutMs }),
    { adapter: 'codex-cli', model, runId, maxAttempts: 3 });
}

You have now met both ideas in this lesson — the board and the adapter family — so here is how the three kinds of participant use them, pulled together in one place. The split is the same one that runs through the whole harness.

A human convenes a board for the biggest calls — a doctrine change, a bet the project will live with — and then steps back to observability: they read the verdict, the confidence, and the preserved dissent in the audit trail, but they do not sit in the deliberation. An LLM working in the loop chooses the right instrument for the stakes: one assistant for routine work, fusion for a risky or ambiguous fork, Council when the answer becomes policy or must withstand scrutiny later. And an agent maintaining the suite guards the plumbing: when a CLI flag drifts, it re-proves the invocation at the real boundary and updates all three tiers — bash, mjs and TypeScript — so they never disagree.

Think of it like… a company's governance. The board members (humans) call the big votes and read the minutes afterward. The duty manager (the LLM) decides, hour to hour, which decisions need a quick huddle and which need the full board. And the facilities team (the agent) keeps the building's wiring to code — re-checking it after every change so nothing fails mid-meeting.

Three quick questions. Pick an answer to see whether it lands — and why.