The gap
Per-change approval solves the wrong problem
Every serious multi-agent system reviews individual changes before they land. Orchestration is deterministic. Agents are bounded. The repository is the source of truth. That architecture is right, and the field has largely converged on it.
But it leaves a structural gap.
When multiple agents write concurrently to shared state, individually valid changes can interact. A migration, a query update, and a configuration change each pass review in isolation. Applied together, they break the system. No per-change reviewer sees the full set. No automated evaluator holds the authority to stop it. The failure is not in any single change. It is in the set, and no one is looking at the set before commit.
This is not a monitoring problem. It is an authorization problem. The unit of authorization is wrong.
How GMAA works
Three moves, one unit
1. Individual changes are reviewed and approved one at a time
Every proposed change enters a review queue and is evaluated on its own terms before it joins the pending set. Nothing accumulates without passing individual scrutiny first.
2. All approved changes are assembled into a complete pending set
GMAA aggregates the full body of individually approved changes and surfaces cross-set conflicts: interactions, dependencies, and invariant violations that only become visible when the work is read together.
3. One accountable human ratifies or pulls the plug, before commit
An accountable human sits in a governed seat, independent of every agent that proposed work. That seat reviews the complete pending set from a structured briefing of conflicts and resolutions, then makes a single, binding decision: ratify and commit, or stop the set entirely. Nothing lands without that sign-off.
Key capabilities
What the framework holds
Approval-at-commit workflow
Authorization happens at two distinct levels, individual change and full set, with the governed seat holding final authority at commit. Neither level substitutes for the other.
Coherence boundary enforcement
GMAA places one writer over each coherence boundary: a defined set of shared state whose invariants must hold together. Everyone proposes. Only the writer commits. The boundary is governed as a whole, not piecemeal.
Human authority that cannot be automated away
The resolution of a jointly incoherent set often depends on facts outside the system of record: a planned migration, a customer commitment, a strategic constraint. Automated evaluators have no channel to that context. The governed seat does. Authorization is not a probability score.
Independent governed seat
The human reviewer sits outside every agent's coherence boundary. There is no shared substrate with the agents whose work is under review, and no organizational dependency that compromises the independence of the decision.
Structured briefing, not a pile of diffs
The accountable human reviews a briefing, with cross-set conflicts identified, resolutions proposed, and risks surfaced, not an unstructured stack of individual changes. The decision is informed, bounded, and executable.
One thesis, applied to code
The thesis is one sentence. At the point where changes enter a system of record, you authorize not only each change but the complete pending set, evaluated together against that system's invariants, ratified as a set by an accountable human independent of every initiator, before any member commits, with a receipt trail. The load-bearing word is set. Per-change review stays. The set is the layer on top of it, never instead of it, because the break lives in the combination that no per-change approver ever sees.
GMAA is that thesis applied to coding: agent seats and humans writing into one shared codebase and database. Running, that application is an operating system for the fleet, with the single-writer spine as its kernel and the set gate as the boundary nothing crosses on silence. It is real and operating today on Claude Code, and it now ships for Grok Build as a plugin with a companion engine zip, with a Grok Bot route for the chat architect. Claude, Grok Build, and later runtimes are how a seat boots, not what the system is.
The claim is not trapped in a repository. The second empty chair is the same thesis at the context window. Coding is the first application, not the ceiling. What the thesis refuses is completeness by assertion: the shape of the control is proven, but whether a given build catches every joint incoherence is earned against an adversarial test, not claimed.
The architecture is specified in full in the v1.6.1 canonical document: coherence boundaries, single-writer discipline, subagent roles, the governed seat, and the per-project implementation checklist.
Read it
Two documents. Start with whichever you are.
Frequently asked questions
Who holds authority in the governed seat?
One accountable human, independent of every agent that proposed work, sits at a governance plane outside the coherence boundaries. That person reviews the complete pending set and issues a single binding decision before commit.
Why can't an automated evaluator replace the human in that seat?
Because the correct resolution of a jointly incoherent set often depends on facts outside the system of record, such as strategic commitments, planned migrations, and customer constraints, that no automated evaluator has a channel to read. Agents grading agents also share the substrate and blind spots of the work they grade. Authorization requires a human with context, not a classifier with a threshold.
What is a coherence boundary?
A coherence boundary is a set of state whose invariants must hold together, for example a ledger and the rules that keep it balanced. GMAA assigns a single writer to each boundary. All agents read and propose. Only the designated writer commits. The boundary is governed as a unit.
Is per-change approval replaced by GMAA?
No. Individual change approval remains in place and is required. GMAA adds the set-level authorization layer on top of it: the layer where individually correct changes are reviewed together for coherence before any of them commits.
What does GMAA claim, and what does it not claim?
The framing is settled: the unit of authorization is the set, and no shipping system currently places an accountable human at that unit before commit. What GMAA does not claim is completeness by assertion. Whether a given implementation catches every joint incoherence, including transitive ones, is an open question, closed only by adversarial testing. The framework is called complete when the adversarial test comes back clean, not before.
Where can I read the full specification?
The Architecture v1.6.1 canonical document covers coherence boundaries, single-writer discipline, subagent roles, the governed seat, and the per-project implementation checklist in full. The thesis document, The Coherence Boundary, makes the case for why the set is the correct unit of authorization and why the governed seat cannot be filled by an agent. Both are available on this site: the architecture and the thesis.
Is the seat at the context window also a human?
No. At the code boundary the governed seat is a person. At the context window the same thesis is applied as machinery under a human-owned constitution: the operator authors and versions the rules the gate runs, and no person sits at per-set commit. The short version of that design is at Governed Context, the short version.
The empty chair
The chair is empty in every system you can find. GMAA fills it.
Your multi-agent framework approves changes. It does not ratify sets. GMAA adds the one authorization plane the platforms are built not to fill: an accountable seat, independent of every agent, that reviews the whole before anything commits.