The Council Picks The Move. The Triad Ships It.

A single model wrote your function.

The same model reviewed your function.

The same model approved your function for production.

That is not review. That is a meeting where one person attended three times and agreed with himself.

The LLM Council fixes one half of this problem. It fixes how the model thinks about a decision before any code gets written. But thinking is only half the system. After the decision lands, something still has to actually build the thing. And that something can quietly ship the wrong thing while telling you it shipped the right thing.

For that you need a Triad.

What The Council Does

Quick recap if you skipped the sister post.

The Council is five personalities pulled into the room before a hard decision. Contrarian, First Principles, Expansionist, Outsider, Executor. Each one reads the same brief and gives a short opinion. You synthesize. You pick.

It is a thinking pattern. It runs before code exists.

The Council asks "is this the right move." The Triad asks "did we actually make the move we said we made." Both questions matter. Skipping either one is how production breaks.

What The Triad Does

The Triad runs after the decision lands. Three models, three jobs, no overlap.

Planner. Reads the brief. Writes a plan. Is not allowed to touch code. Its only job is to find the holes in the brief before anything ships. Catches stale assumptions. Catches paths that got renamed two commits ago. Catches environment values that no longer mean what the brief thinks they mean.

Executor. Different model. Reads the plan and writes the code. It does not negotiate the plan. If the plan is wrong, that is the Planner's fault, not a debate.

Verifier. Third model. Reads the diff and the tests. Does not see the original plan. Its only job is to ask one question. Do these tests actually exercise what changed, or are they exercising the old thing under a new name. Right now this runs as a separate Opus pass with an adversarial system prompt. The intended end state is a Codex pass for true cross-vendor review. That migration is on the list.

Three models. Three jobs. No overlap.

Why The Combination Compounds

Council and Triad catch different failure modes.

Council fails at execution-layer drift. You can pick exactly the right move via Council and still ship the wrong thing, because the executor renamed a variable two commits ago and nobody updated the brief.

Triad fails at strategic drift. Three models can perfectly plan, execute, and verify a bad idea. The Verifier checks "did we do what we said." It does not check "should we have done it."

Stack them and the gaps close.

The Council runs at decision time. What should we build.

The Triad runs at delivery time. Did we build what we said we would.

A bad plan executed perfectly still gets to main. A good plan with a broken executor never does. You do not get to skip either one.

What It Actually Catches

Three real catches from the last few weeks. Names and hashes scrubbed.

The registry-key drift. Brief told the Executor to set LANE_C_PROVIDER in the chain config. Planner refused to start. It grepped the actual config first and found the key had been renamed to lane_c two arcs ago. Six different literal-drift catches landed in a single phase, all from the Planner doing this one move. The Executor would have happily set a key that does nothing.

The thirty-nine green tests. Executor shipped a new feature. Thirty-nine unit tests, all passing. Verifier read the diff and asked the question. Are any of these tests asserting on the new behavior, or are they all asserting on the legacy path. The answer was the latter. Silent overwrite. The Verifier blocked the merge.

The closeout that lied. This one is the Council-Triad handshake. Executor wrote a closeout summary that said "v1 shipped." Council ran on the summary itself, not the code. Contrarian flagged the framing. Outsider pointed out the knowledge layer was not actually wired. Three different premature v1 claims got caught the same way inside twelve hours.

None of those were caught by the model that wrote the code.

The Cost Math

The obvious objection is that three model passes is three times the cost.

Not really.

Most of the system runs on free-at-margin local or quota models. The Planner is a small fast model. The Verifier is a small fast model. Only the Executor is expensive, and only when the task demands it. Real cost increase is closer to 1.4x than 3x.

Now the other side of the ledger. One Verifier catch prevents one production rollback. One rollback costs more than a month of Verifier passes.

The question is not whether you can afford the Triad. The question is whether you can afford to ship without it.

How To Wire It Up

The Council is a skill. Same setup as the sister post.

The Triad is a slash command. Here is the working sketch:

/start-work
  -> create plan.md (singleton)
  -> dispatch Planner subagent with the brief
  -> Planner writes plan.md, returns
  -> hand off plan.md to Executor
  -> Executor writes code, returns diff
  -> dispatch Verifier subagent with the diff + tests (NOT the plan)
  -> Verifier returns pass or block
/end-work
  -> archive plan.md to .auto-memory/

The Verifier not seeing the plan matters. If the Verifier sees the plan, it grades the diff against the plan, which is just the Executor checking its own homework with extra steps. Withholding the plan forces the Verifier to ask the only question that matters. Do the tests prove the thing the diff claims to do.

That is the whole pattern.

When Not To Use It

Naming a variable. Renaming a file. Anything where the cost of being wrong is one undo command.

Use the Triad on changes that touch production state, change data shapes, or modify something a customer or future-you depends on. For everything else, ship.

A committee for every typo is just a committee.

Close

The Council picks the move.

The Triad ships it without lying about what happened.

Sources: Karpathy's llm-council, the sister post on LLM Councils, and the multi-agent debate paper arXiv 2305.14325.