| name | marshal-plan-consensus |
| description | Reach a consensus on the APPROACH before committing a fleet to build it. Spawn several biased, independent solvers that each propose a plan for the same question, then an independent judge that converges them into one concrete plan (or narrows the question and re-runs). Use when the approach is contested - multiple valid designs, ambiguous scope, or a costly wrong turn - not for obvious work. The engine runs the agents; this playbook is the judgment. Hand the converged plan to marshal-orchestrate to build it.
|
Reaching a consensus plan before you build
When what to do is clear you just decompose and delegate (marshal-orchestrate). When how to do
it is contested - several plausible designs, fuzzy scope, an expensive-to-undo direction - you first
turn the question into an evidenced plan that survived independent scrutiny. The loop is frame
-> solve (in isolation) -> judge -> converge or build.
This is not one agent's plan. It is biased, independent, multi-angle convergence: each solver starts
from a different prior, proposes without seeing the others, and an independent judge arbitrates - it
never authors a fourth plan of its own.
When to use
- A non-trivial goal where the approach is genuinely contested, or a wrong turn is costly (a schema,
a public API, a migration strategy, a refactor boundary).
- Not for obvious tasks - reaching for consensus on a clear change is wasted spend; just orchestrate.
The three rules that make it work
- Biased. Each solver holds ONE prior (below) and argues it. Don't ask one agent for "the best
plan" - that collapses to a single opinion.
- Independent. Solvers must not see each other's plans. Spawn them together so they run in
parallel isolation; only the judge reads all of them.
- Sealed. Each solver ends with one parseable line:
PLAN: propose|abstain - <one-line approach>, above a short plan body (scope, files, key decisions, what it explicitly will NOT do).
1. Frame the question
Write ONE concrete, narrow question, plus the constraints/rules that govern it and the minimal files
or context a solver needs to answer. Vague questions produce vague plans.
2. Spawn the solvers (no-peek, read-only)
Route to read-only clients (they inspect the repo and produce a plan, not edits) and give each the
same question + its prior + the required PLAN: line. Run them together so they cannot see each
other:
run_many([
{client: <read-only>, goal: MINIMAL_PRIOR + question, task_id: "plan.<id>"},
{client: <read-only>, goal: STRUCTURAL_PRIOR + question, task_id: "plan.<id>"},
{client: <read-only>, goal: DELETE_PRIOR + question, task_id: "plan.<id>"},
])
Share one task_id so usage() / report() group the round. The priors:
- minimal - the smallest viable change that resolves the goal; explicitly do NOT over-engineer.
- structural - the structurally clean design; accept higher cost (a helper, an abstraction, an
extra handoff) to land something an architecture review won't reject later.
- delete - question the necessity. Can this be solved by deleting or collapsing, or not built at
all? If it must be built,
abstain and let minimal/structural win.
3. Judge - converge, don't author
Feed the three sealed plans to one independent judge agent. It arbitrates between the proposals;
it must not invent a fourth design not present in any solver (that means it's solving, not judging).
It emits exactly one:
consensus - the proposals agree (same boundary, same files, no contradictory choices). Output the
one concrete converged plan.converge - they disagree but are close: narrow the question to the open disagreement and re-run
step 2.escalate - genuinely stuck or the goal is ill-posed. Stop and bring it to a human.
Even when a direction looks obvious, run the gate: it turns a hunch into a plan with stated scope,
files, and non-goals.
4. Converge loop
On converge, re-run the solvers with the narrowed question. Cap at ~3 rounds. If a round makes no
progress (same split twice), escalate to a human or drop the goal - never loop forever.
5. Build
On consensus, the converged plan is your spec: hand it to marshal-orchestrate (decompose into
independent tasks -> spawn -> review -> integrate), and gate the result with marshal-review-gate
when the change warrants a quorum.
Invariants to respect
- Solvers and judge are headless - the question + prior in the prompt is all they get; no questions.
- Independent means parallel + isolated; only the judge sees all plans, never a solver.
- The judge converges among the proposals; it never authors a new plan of its own.
- An obvious direction still passes the gate; cap the rounds and escalate - never loop forever.
