Plan First. Two Councils. No Exceptions.

I shipped a broken plan. Then I built the pattern that would have stopped it.

Three in the morning. I had just approved my own plan. Not reviewed it, approved it. My tired brain said it was solid. The agents started executing. By morning I had a beautifully built implementation of the wrong thing.

That night should have taught me something obvious. It didn't, not yet. I filed it under "bad night" and moved on. Then it happened again.

One reviewer is not a floor. It is barely a filter.

The problem with a single council

Most review processes follow the same shape. An artifact goes in, one set of eyes looks at it, a green light comes out. That is a single point of failure dressed up as a process. When the reviewer and the author share context, and they almost always do, you get confident reviews of confident mistakes.

Operational security figured this out decades ago. Two officers required to authorize a nuclear launch. Two approvals on transfers above a threshold. Not because the individuals are incompetent. Because any single person, no matter how sharp, can be wrong. The four-eyes principle exists precisely to stop shared blind spots from becoming shared catastrophes.

I had to build my own version of that, for agents, for plans, for every artifact before it lands.

Plan as artifact

The first shift was forcing myself to write the plan down before anything runs. Not as notes. As a formal artifact. Objective, steps, expected outputs, definition of done, and, the part that kept saving me, what is explicitly out of scope.

The plan becomes the thing that gets reviewed. Not the code. Not the output. The plan.

This matters because the most expensive failures start before a line runs. An agent that executes brilliantly on the wrong plan produces perfect garbage. Catching the plan failure at the artifact stage costs almost nothing. Catching it after hours of execution costs everything downstream.

The two councils

Once the plan-as-artifact exists, two independent councils review it. Fleet and oracle are the abstract names, the specific compositions stay internal, because that part is the moat. What matters is that they are genuinely independent. Not the same panel prompted two different ways. Not the same model with a temperature change. Different vantage points, different priors, neither knowing the other's verdict until both have weighed in.

Karpathy pointed at something real when he described multi-model council review. The multi-agent consensus literature has built on similar reasoning. My version is not novel, it is operational. The pattern borrows from everywhere and commits to nothing proprietary in the abstract shape. What I keep private is the concrete configuration.

Convergence or iterate

The artifact does not land until both councils converge. What convergence means specifically, I am not publishing that. It is the most important part of the discipline and the part that stays private. The abstract shape is: agreement means it lands, disagreement means it goes back for revision. Sometimes that is a second draft. Sometimes a third.

Yes, it is slower.

What the slowdown buys

I want to be honest about the cost. A plan that would have landed in thirty minutes now takes ninety. Under deadline pressure, that feels like a tax on momentum.

Here is what happened when I ran this pattern for a month: the artifact that landed after convergence was almost never the artifact I submitted first. Wrong scope. Unstated assumptions. Steps that depended on something that had not shipped yet. Optimistic timelines on the parts I was most excited about.

Every one of those catches was cheaper in council than it would have been in execution.

The math flipped on me. Two councils reviewing a plan before anything runs is dramatically cheaper than one engineer debugging why the execution went sideways at hour three. The ninety minutes upfront stopped multiple downstream scrambles. The pattern started paying for itself inside the first week.

What it looks like in practice

A restructuring plan came up for review. One council passed it. The other flagged that two existing capabilities would silently break, they lived upstream, they were not mentioned in the plan, and they were not obviously connected to the component being changed. Neither reviewer had fabricated the concern; the dependency graph made it real.

Under a single council, that plan lands and ships a regression. Under the two-council pattern, it goes back. The plan gets updated to sequence the dependency fix first. Both councils converge on the second draft. No regression. No 2am incident.

That is the pattern working exactly as designed.

The principle

This is not about distrust. It is about architecture.

One review council is a single point of failure regardless of how skilled the reviewers are. Two independent councils reviewing the plan before execution means a confident mistake has to fool both separately. Systems that are genuinely independent rarely fail in the same direction at the same time.

Plan first. Two councils. No landing without convergence.

The zero-defects discipline that sits on top of this is a longer story. That one is coming.