SAMI puts a council of AI models on every task. The council carries it through five stages, and each stage ends in a yes/no vote before the run moves on.
The Council
Guardiansone equal vote each
LeadWriterVoteNoback to deliberation
Yeson to the next stage
Lead and Writer are duties, not ranks.
The full rules
There are no separate review or draft models: every Guardian votes with equal weight at every stage, the whole run.
The Lead coordinates the stage and announces the outcome. It votes with equal weight too: a coordination duty, never a higher rank or a super-vote.
The Writer writes at Build and Harden, and at Acceptance only to fix a failed check, a limited number of times. The other Guardians read and send change requests.
Each Guardian votes Yes or No; there is no third option.
Every selected model is a Guardian with an equal vote for the whole run. Two of them carry per-stage duties: the Lead coordinates the stage and converges the discussion, and the Writer is the only model that writes code or runs commands. Duties are jobs, not ranks. A no never ends the run: it loops back until the council reaches a genuine yes. If the objection is not resolved within a bounded number of rounds — or the run budget runs out, or you cancel — the stage moves on with it recorded as unresolved, visible in the War Room.
Inside every stage the models work through a shared ledger of claims, challenges and proposals, each backed by evidence. An objection stays open until the model that raised it is satisfied or the Lead records it, objection preserved — then the council votes.
Context for every stage
Semantic, keyword and code-aware retrieval is merged into one focused context block for the council. From there it flows into every stage: a shared baseline every stage reads, a per-stage slice pulled on top, and cross-stage recall, so any model can look back at what another said earlier in the run. Project retrieval is part of every paid plan.
Context engine
Hybrid retrieval blends three modes into one context stream for the council.
Semantic
meaning-based search
Keyword
exact-term search
Code intelligence
workspace grounding
Shared baseline context
Every stage reads it, the whole run.
01
01
Understand & Contract
Per-stage sliceEach stage pulls its own on top.
02
02
Plan
03
03
Build
04
04
Harden
Cross-stage recall04 looks back at 01: any model can recall what another said earlier.
05
05
Acceptance
A follow-up run remembers the last one
On paid plans, a follow-up run on the same project carries forward the decisions from earlier runs, so the council does not re-open a choice you already settled.
The workflow
Five stages, always in this order. Each one ends in a binary vote by the whole council before the run moves on.
01
Step 1: Understand & Contract
Clarifies the request with you, then fixes the contract the build must follow
The council collects its open questions — missing information, unclear scope — and asks you in batches. You answer inline, and it keeps asking until every selected model agrees the task is understood. Clarification has no fixed number of rounds.
In the same stage the council turns the clarified request into a binding contract: interfaces, data flow, module boundaries and file layout — the exact shape the later stages must build.
All yes: request understood, contract sealed
02
Step 2: Plan
One complete structure the whole council stands behind
Every model pressure-tests the approach. The Lead converges it into one plan for the complete structure — folders, files and modules — building on the layout the contract fixed, never a parallel one.
03
Step 3: Build
Only the Writer writes code; every other model reviews it
The Writer builds exactly the plan the council agreed. The other models critique the direction, sketch alternatives and file change requests — they never write to your workspace. Right after the council's yes, SAMI runs the project's build and tests if it has any.
04
Step 4: Harden
Every model challenges the build for defects, correctness and security gaps
The council attacks the build: edge cases, race conditions, unsafe input, and claims that do not hold up against the code or earlier decisions. Voting is binary — yes, or no with a written reason. The Writer applies the validated fixes, and the project is run again.
NoYes
Deliberate
Vote
Sealed
How a No resolves
A no is never dropped or rubber-stamped. The model that votes no says why, and the council deliberates — counter-arguments, alternatives — until the objection resolves into a genuine yes. If the objection is not resolved within a bounded number of rounds — or the run budget runs out, or you cancel — the stage moves on with it recorded as unresolved, visible in the War Room.
All yes: fixes applied, objections resolved
05
Step 5: Acceptance — Execution-Verify Gate
A final audit, then the project is actually run
Most AI tools vote on plausibility: they read the code and decide whether it looks right. SAMI's Execution-Verify Gate makes the council vote on proven behaviour. It runs typecheck, lint, tests and build when the project defines them, and a failing run goes back to the council before the stage can move on. The same gate already ran after Build and Harden; here it has the last word. Acceptance has no build duty of its own, so it writes nothing itself; only a failed check can bring the Writer back in.
Passing run — proven, not assumed. The council votes on a confirmed result.
Failing run — the real failure goes back to the council. The Writer may make a limited number of fixes to that failed check, and the council always votes again. If the objection is not resolved within a bounded number of rounds — or the run budget runs out, or you cancel — the stage moves on with it recorded as unresolved, visible in the War Room.
Sending work back
Build, Harden and Acceptance can send the run back to Understand & Contract or Plan with a written change request — a limited number of times per run, so refinement converges.
You set the autonomy
Three autonomy levels decide how much you approve along the way. They change the checkpoints you see — not the council. Multi-model review is on at every level.
L1Level 1
Ask before every tool call (default)
You approve every tool call, including file reads, and each finished stage before the next one starts.
You approve every step
L2Level 2
Ask before destructive calls
Reads run on their own. You approve every file change and command, and confirm each stage before the next one starts.
You approve changes
L3Level 3
Full auto
No approval waits for you: the council's yes moves the run on. You can still steer the council from the composer.
You review the outcome
The council never switches off. Autonomy only governs how often the work pauses for your approval. Every stage is still reviewed and voted on by the full council, and a no still loops back to a genuine yes — even at the most autonomous level. If the objection is not resolved within a bounded number of rounds — or the run budget runs out, or you cancel — the stage moves on with it recorded as unresolved, visible in the War Room. Destructive commands are blocked at every level.
