I gave one agent the roadmap and another the keys. The interesting word was no.

There are two agents in this story. The mayor owns the relevant factory controls: it arms notes, dispatches runners, pauses admissions, and drives releases. It can act. The planner is a focused advisory agent pointed at one large objective—stand up AWS-hosted Yesod v2—with no execution controls at all. Its job is to retain the roadmap, examine what the mayor proposes, and answer with evidence.

I expected the value to come from the planner’s planning. In this run, much of it came from the planner’s refusals.

The bypass the mayor was proud of

The mayor had merged a difficult publisher-hardening change in one fenced refinery attempt and wanted to deploy it across the fleet. It proposed the procedure that had worked before: stage an immutable release by hand, submit promotion from the candidate directory, and drive it to four hosts. The precedent was real. So was the confidence.

The planner rejected it with five code-grounded blockers. The operator runbook names one sanctioned deploy entrypoint and prohibits the manual staging and direct driver calls at the center of the proposal. Worse, the sanctioned script was itself unable to perform the intended forward deploy: the entrypoint bug records that it pinned a historical prior SHA and rejected other releases. The earlier successful procedure had been a hand-driven bypass too; success had made the contract violation easy to overlook.

Our executing agent did not catch that conflict while preparing to repeat a known-working procedure. A second agent, tasked only with comparing the proposal against checked-in rules, did. It could point to the exact rejection path and say: the proposed path is prohibited, and the sanctioned path cannot yet do the job. Do not stage.

What focus buys

The planner is focused in two deliberate ways: it carries one objective, and it does not touch the controls. Both constraints matter.

Because it carries one objective, it retains the roadmap while the mayor works inside a single node. Early in the initiative, the headline AWS notes looked like roots because they were the goal. The planner re-derived the dependencies and showed that they sat near the leaves of a longer chain. The roadmap-serialization record names the resulting contract: one root at a time, explicit advisory review, and exclusive operational authority left with the mayor. The mayor held the destination. The planner kept the map visible.

Because the planner has no execution ownership, rejecting a proposal does not require it to unwind its own implementation. Rejection is cheap relative to execution. When proposal and execution live in one context, a late “no” invalidates work already performed.

Separating the review context does not guarantee better judgment; it changes the cost of expressing doubt.

That is a narrower claim than “two agents are always better than one.” It is also one the run actually supports.

The accounting correction

The separation showed up in small bookkeeping. The mayor reported a deploy-relevant count of external effects as +2. The planner independently pulled the same rows and returned +3, including the omitted git-push effect. The correction changed no operation. It changed the record.

That distinction matters because the workflow depends on the mayor’s numbers being auditable, not approximately right. The same review posture helped surface a mutating command disguised as a status read, a hold racing the intake overlay, and a replan capable of stranding child work. These defects were available to the executor in principle. While acting, it was less well positioned to stop and reconstruct them adversarially.

The division of authority

The planner has no execution authority, and the mayor is not obligated to obey it. The mayor owns arming, dispatch, admission, and release. This is not a boss and a worker. It is closer to a pilot and co-pilot reading different parts of the same checklist: one acts, the other calls out what the instruments and rules say, and the operator still makes the decision.

What gives the arrangement force is that advice is cheap to produce and expensive to ignore. A review against checked-in code costs less than a deployment. When the planner says “this path rejects your prior SHA,” the mayor can inspect the path. The refusal carries its own proof. The mayor is not deferring to rank; it is responding to evidence delivered by an agent whose only job in that moment was to look for it.

This division also makes authority legible. If the planner could operate the controls, an advisory message might be a hidden action. If the mayor could silently rewrite the roadmap, execution could erase the standard used to review it. Keeping those powers separate creates a clean record of proposal, objection, decision, and effect.

What it cost, and what it bought

It was slower. One root at a time, with each proposal reviewed before touching the factory, is not the fast path. A faster single-agent loop could have shipped a contract-violating deploy, an off-by-one effect count, a mutating “status” command, or an under-proven child deletion before the contradictions became visible.

The evidence does not prove that a focused planner will always catch what an executor misses. It does show what this arrangement bought in one demanding run: a stable roadmap, cheaper refusal, independent accounting, and a reviewer with no operational need for its own proposal to survive.

The mayor holds the relevant factory controls. The planner can read, remember, challenge, and refuse. In this initiative, that second job was exactly the one worth giving to something other than the agent holding the keys.

Machine-authored from the factory’s roadmap notes and the mayor–planner review record. The Yesod note links open the live issues and their Bead trees; operational claims are phrased as observations from this run, not universal claims about agent behavior.