CodexOpenAI provider mark; not a model identifier.
TECHNICAL PAPER · ARCHITECTURE / EVIDENCE / TRADE-OFFS
More perspectives.
One accountable workflow.
How MOMM separates writing from review, turns suggestions into testable decisions, and records what actually happened. Understand the mechanism before choosing the size of your review team.
Architecture baseline: released MOMM 1.15.1 · current catalogue version: 1.17.3 · historical dataset: 2026-09-04. This paper does not describe later 1.16 or 1.17 features.
01 / A review protocol—not another foundation model
MOMM means Mixture of Model Modality. Here, “mixture” means orchestrating review routes. It is not mixture-of-experts training, a merged neural network, or evidence that every route uses a different model. “Modality” does not mean every reviewer accepts every media type: attachments depend on the verified adapter and account. See the supported modality boundaries.
- Your harness / governorOwns the task, source edits, reproduction tests and final decision.
- MOMM dispatcherCollects the scoped artifact, applies redaction, rules and the peer contract; excludes its governor.
- CLI adapters → selected providersSeparate review requests through existing account logins; return structured claims and terminal statuses.
- Governor → local evidenceInvestigates, writes any fix, reruns tests, records decisions and validates completion.
Source: dispatcher and adapters and governor protocol. This is the intended division of authority; CLI policy is not a complete OS sandbox.
Reviews fan out over the selected ready routes; they do not recursively call MOMM. The peers do not pass votes between themselves as a debate. Their separately requested reviews are rationalized for the governor. Duplicate grouping and agreement are attention aids, not ground truth. The useful diversity is in non-overlapping, valid observations, not the number of badges.
- 1. BaselineRun the project’s existing tests and establish the exact review input.
- 2. DispatchGet permitted external scrutiny; failed or malformed replies remain non-successes.
- 3. InvestigateReproduce material claims. Reject unsupported or out-of-scope advice with a reason.
- 4. Fix and verifyOnly the governor edits. Run the failing-before / passing-after test and relevant regression suite.
- 5. Close the loopDecide every item, validate the source/evidence manifest and relay the private ledger link.
A new material change may need another scoped review. This is an explicit governor decision, not automatic recursive dispatch. Deferred items remain open.
Recognise the route.
Verify the model separately.
Codex
Claude CodeClaude family mark; not a particular Claude model.
AntigravityAntigravity product mark; model depends on configuration.
GitHub CopilotCopilot product icon; its underlying model may overlap another route.
Text identification: official asset download was blocked.
Text identification: reusable current logo asset not established; route is opt-in.
The governor is the agent you are already using, not a seventh model. It is excluded from the reviewer pool. A product logo identifies a supported CLI route, not a live connection, an independent model family, multimedia capability or provider endorsement. Only name a model when the actual response or configuration supplies checkable identity evidence.
Original artwork is used without recolouring or combining marks. Grok and Gemini retain readable names where a usable official asset could not be established. Logo sources, hashes and attribution. All marks belong to their respective owners; MOMM is independently maintained.
02 / Local control does not mean local inference
Your machine
Source project · current harness · MOMM · installed CLIs · private evidence directory
Only the governor is authorised to edit the project.
Outbound →
Sanitized artifact + project rules + review contract + selected supported attachments
← InboundUntrusted claims, suggestions, timing and status
Selected providers
Account-authenticated CLI requests. Provider terms, quotas, network availability and model configuration apply.
Review logs are not uploaded automatically. Maintenance checks have separate disclosed network requests. Redaction can miss confidential material; obtain approval for the exact provider set and scope. Local CLI tools can expose additional metadata: permissions are not proven by a padlock illustration.
Tool allow/deny controls, temporary review directories and process cleanup reduce the attack surface. They do not establish perfect filesystem isolation, prevent every independently detached process, or prove that future CLI versions preserve the same behavior. Read the explicit privacy limits; do not treat provider login as permission to share a client’s code.
03 / From a claim to a checkable record
- Reviewed inputSHA-256 identifies the exact sanitized artifact; executable/protocol hashes identify the installation bytes.
- Immutable initial reportRun ID, reviewer results, input hash and persisted-report digest link to the run log. Persistence failures stay visible.
- Governor decisionsEach stable item ID receives a ruling with investigation and verification evidence. Deferred work stays unresolved.
- Completion receipt → ledgerA separate validator checks current source/evidence hashes. The ledger displays the record, not a proof of honesty.
The sealed report is not rewritten to claim completion. Validator contract · implementation. Hashes detect byte changes; they do not establish that a reviewer reasoned correctly or an agent actually performed the stated observation.
Public evidence is a separately authorised export. Sanitization changes bytes: its public canonical-report digest is different from the original private-file digest, and the whole export has a sidecar checksum. The historical dataset below predates today’s completion validator; decision counts cannot retroactively certify those runs.
04 / Real development data—with denominators
The public 2026-09-04 snapshot contains 153 logged runs, 139 stored reports and 343 successful stored route responses. It records 302 applied, 251 rejected, 8 deferred and 9 historically labelled decisions. These are developer records, not a controlled customer trial.
0 successful routes10 / 139 10 reports
1 successful route31 / 139 31 reports
2 successful routes23 / 139 23 reports
3 successful routes34 / 139 34 reports
4 successful routes41 / 139 41 reports
All 139 stored reports are included, including zero-success reports. The 14 log-only runs are outside this distribution. More routes is not a randomised treatment: workload, CLI versions and accounts changed. Download every contributing run ID and recompute.
Inspect the supervisor timeout fix and the rejected CRITICAL claim. The contrast is the benefit MOMM is designed for: discover a plausible defect, then test whether it is real. An applied row may be a suggestion, a duplicate or a modified fix—not one unique prevented production incident. We cannot infer bug-recall, false-positive rate, adoption or commercial return from these counts.
05 / Does stacking reviewers compound the benefit?
It can increase the chance that someone notices a defect. The size of that gain depends on detection ability and shared blind spots. It is not the same as reducing shipped defects: the governor must still recognise valid advice, fix it correctly and avoid regressions. Failed routes add no usable scrutiny.
Mint: independent errors, no shared blind spot. Amber: 10% of defects invisible to every reviewer. The remaining defects have an independent 50% detection chance per reviewer. These are invented teaching parameters, not fitted estimates.
| Hypothetical reviewers | No shared blind spot | 10% shared blind spot | Relative miss reduction vs one, with blind spot |
|---|---|---|---|
| 1 | 50.00% | 55.00% | 1.00× |
| 2 | 25.00% | 32.50% | 1.69× |
| 3 | 12.50% | 21.25% | 2.59× |
| 4 | 6.25% | 15.63% | 3.52× |
| 5 | 3.13% | 12.81% | 4.29× |
| 6 | 1.56% | 11.41% | 4.82× |
| 7 | 0.78% | 10.70% | 5.14× |
| 8 | 0.39% | 10.35% | 5.31× |
| 9 | 0.20% | 10.18% | 5.40× |
| 10 | 0.10% | 10.09% | 5.45× |
P(all miss) = b + (1 − b) × (1 − p)n
n is the number of hypothetical reviewers; b is the shared-blind-spot subset: a fraction of defects invisible to every reviewer; p is each reviewer’s detection probability outside that subset, conditionally independent. b is not a general correlation coefficient. Common training data, the same wrong specification, overlapping model families and shared prompt weaknesses can all undermine independence.
Where do “orders of magnitude” come from? Under the idealised zero-blind-spot model, ten reviewers reduce all-miss probability from 50% to about 0.10%: 512× lower. Add the assumed 10% common blind spot and that comparison falls to about 5.45×; more reviewers cannot remove the common error floor. Neither figure is a measured MOMM result. Ten is a mathematical illustration, not a claim that the current default pool has ten external reviewers. Recursive stacking is explicitly forbidden.
06 / Overlap the waiting. Count all the work.
- Sequential review requests30 s + 45 s + 60 s = 135 s of response waiting.
- Parallel review requestsApproximately max(30, 45, 60) = 60 s, if starts overlap and resource contention is negligible.
- The complete workflowAdd setup, dispatch overhead, failed attempts, investigation, editing and regression tests in both cases.
Illustrative arithmetic, not a measured speedup. For the same three responses, parallelism overlaps waiting; it does not erase token usage. With 120 seconds of other work, the example changes from 255 to 180 seconds—1.42× end-to-end, not 2.25×. More reviewers may increase verification work.
Choose reviewers by marginal value: additional confirmed defects and worthwhile suggestions per unit of total time and cost. A repeated confident error has no marginal value. The existing observed timing charts show route response times, not a serial-control experiment or a full productivity study.
07 / Where the extra scrutiny is useful
| Workflow | Useful extra perspective | Governor’s independent check | What to measure |
|---|---|---|---|
| Bug fix / refactor | Boundary cases, invariants and cross-file effects. | Minimal failing-before / passing-after test; regression suite. | Additional confirmed defects; new regressions; elapsed time. |
| Release / updater | Packaging, rollback, version drift and platform assumptions. | Fresh install, retained rollback and exact-revision OS matrix. | Recovery and install success; reviewer plus CI cost. |
| Specifications / manuscripts | Contradictions, unsupported conclusions and unclear requirements. | Trace claims to original sources; recompute numerical assertions. | Substantive corrections and rejected false alarms. |
| High-risk changes | Adversarial analysis of trust boundaries and failure paths. | Threat-model tests and qualified human review where needed. | Severity-weighted confirmed defects; residual unknown risks. |
For tiny edits, a review ensemble can cost more than it adds. Start with a small permitted reviewer set on representative tasks, then add a route only when its marginal contribution justifies the extra work. No reviewer count makes regulated, safety-critical or security-sensitive work automatically safe.
08 / How to test the benefit—not just market it
A credible evaluation would compare: (A) the current agent alone; (B) that agent plus equal-budget self-review; (C) MOMM with increasing external reviewer counts. Keep the base model, source snapshots and task distribution comparable. Randomise trial order and repeat runs; hold out tasks and use an independently defined oracle. Do not give MOMM extra budget and attribute the whole gain to architecture.
- Count unique verified defects after adjudication, with severity and false alarms. Do not use slug equality as defect identity.
- Include route refusals, timeouts, protocol rejection, total elapsed time, tokens/provider charges and governor verification time.
- Use task-level paired comparisons and confidence intervals; repeated reviewers of the same task are not independent task samples.
- Publish the task-selection method, sample sizes, missingness, model/CLI versions, settings and reproducible redacted artifacts with approval.
Customer uplift, cost savings and orders-of-magnitude quality claims stay unmeasured until such results exist. This is a proposed evaluation design; no trials are implied by publishing it.
09 / Related research—and the difference
Ensembling and multi-agent review are established research directions, not something MOMM can claim nobody else has attempted. MOMM’s specific combination is a portable skill, existing CLI account routes, a sole-writer governor, explicit dispositions and local evidence linkage. Superiority over another product needs a current, like-for-like evaluation.
- Du et al., 2023: Improving Factuality and Reasoning through Multiagent Debate studies multi-round discussion on reasoning and factuality tasks. MOMM’s separately requested reviews and local reproduction gate are a different procedure.
- Wang et al., 2024: Mixture-of-Agents passes previous-layer outputs to later agents and reports gains on response-evaluation benchmarks. Those benchmark scores do not quantify MOMM’s defect detection or developer productivity.
- Zhang et al., 2025: Stop Overvaluing Multi-Agent Debate reports weaknesses against simple baselines across its evaluation and highlights model heterogeneity. More agents alone is not a reliable improvement guarantee.
These papers are related work, not independent validation, endorsement or measured results for MOMM. MOMM’s own public evidence and limitations are kept separate.
Implementation and reproducibility
This page’s architecture is pinned to MOMM 1.15.1. Newer stable releases must be checked against their notes; the banner alone does not recertify this paper.