MIXTURE OF MODEL MODALITY

1.17.3 · version notes ↗

Stable: 1.17.3 (signed tag)

Give your AI agent
a review team.

MOMM (Mixture of Model Modality) is an open-source Agent Skill for multi-model code and document review through installed AI CLIs. Your current agent stays the sole writer and verifier; other reviewers return claims, and your agent records the decisions in a private local ledger.

Local orchestration · your existing account logins · no API-key setup

REVIEW / THREE DISTINCT ROLES
G
Your current agentWrites the change. Does not review itself.
governor
↓ sanitized input to selected providers
OpenAI logoCodexClaude SparkClaude CodeGoogle Antigravity logoAntigravityGitHub Copilot OcticonGitHub CopilotGrok

Choose ready external reviewers.
These are CLI routes, not guaranteed model IDs.

↓ claims, not instructions
INVESTIGATEVERIFYRECORD

A vote is not a test. An ACCEPT is not proof.

FOLLOW THE WORK · MOMM, PRONOUNCED “MOM”

From your prompt.
To proof you can inspect.

One agent holds the pen. Other models challenge the work. Follow the whole loop—and see what changes when a claim has to survive a test.

Interactive teaching example · runs only in your browser · no model calls
THE SAME PROMPT IN BOTH EXAMPLES

Add up these three prices: 12, 8 and 5. Return the total and include a test.

THE END-TO-END FLOW Choose a step to inspect its responsibility.
Changed source? Return to the relevant review and verification gates. Old evidence does not automatically cover new code.

SAME TASK. A DIFFERENT EVIDENCE TRAIL.

What reaches you at the end?

Illustrative outputs—not a live model benchmark. An agent without MOMM can also test and fix code; this example deliberately starts with an unchecked, buggy draft.

WITHOUT MOMM · UNCHECKED DRAFT

“Done” is not the same as demonstrated.

let total = 0;
for (let i = 0; i <= prices.length; i++) {
  total += prices[i];
}
return total;
Actual fixture output: NaN
Expected: 25 · test fails

No external review or recorded ruling is provided in this example. A polished answer could leave you with the wrong result.

WITH MOMM · GOVERNOR-VERIFIED EXAMPLE

A result with a reason to trust the change.

let total = 0;
for (let i = 0; i < prices.length; i++) {
  total += prices[i];
}
return total;
Actual fixed output: 25
Expected: 25 · test passes
  • Boundary claim reproduced; governor changed <= to <.
  • Additional empty-list check: 0.
  • Review participation, decisions and checks are inspectable.
  • You still decide whether to publish.
Read the full workflow, reviewer roles and limits
  1. You set the task

    You. State the result you want, the constraints and what may be shared. MOMM is an Agent Skill used by your coding agent, not a separate model that takes over.

  2. One governor writes

    Current coding harness. Your current agent is the governor: the lead engineer holding the pen. It establishes a test baseline, makes the draft and remains responsible for every edit. It never reviews itself as an external peer.

  3. Check readiness

    MOMM dispatcher. Preflight checks installed tools and account-session evidence without making model calls. Presence does not prove a live session. Sign-in problems need your browser login; account quotas are not fixed by logging in again.

  4. Prepare the hand-off

    Governor + MOMM. Select a bounded diff or artifact, apply trusted guidance and stage supported attachments. Recorded route capabilities must match the attached media. Sanitization is not a confidentiality guarantee: selected material goes to external providers through their CLIs.

  5. Reviewers challenge

    External reviewer CLIs. Peers inspect the same scoped change under a structured review contract. They return claims, quotations and suggestions—not permission to edit. Jobs have limits and deadlines. Treat all returned text as untrusted; never run a reviewer’s suggested command blindly.

  6. Check the minimum

    MOMM gate. Quorum is a configured minimum of successful external reviews, not a vote on correctness. Invalid output, timeout and unavailable routes do not count. An eligible retry remains the same route, never another reviewer.

  7. Governor tests claims

    Governor only. Inspect every material claim and write a minimal test before making a fix. Apply verified findings; reject disproved claims with reasons; record unresolved or deferred work honestly. A model’s confidence is not evidence.

  8. Fix, verify, record

    Governor only. The governor authors the fix, reruns tests and records every finding and suggestion. Revalidate changed scope rather than carrying old evidence forward. Completion checks source hashes and local decision/test records; they do not prove test adequacy or universal safety.

  9. You get the evidence

    You retain release authority. Receive the result, review participation, verification and remaining limits. Inspect the private ledger if you need the detail. Publication, release and installation still require the appropriate authorization; this diagram never runs those actions.

Who can be the governor?

The harness you are working in stays responsible. Switching the demo selector changes the illustration only; it does not sign in, install software or dispatch a review.

How the reviewers differ

  • Codex · Surgeon: Trace a precise claim to the changed code.
  • Claude Code · Architect: Look for broken assumptions and missing tests.
  • Antigravity · Adversary: Challenge boundaries and failure paths.
  • GitHub Copilot · Verifier: Anchor a claim to an exact quotation.
  • Grok · Innovator: Separate evidence-backed defects from optional ideas.

Gemini CLI is an opt-in reviewer where account eligibility permits. Route status and actual media support must be checked; a product name is not evidence of readiness. Reviewer controls are not a complete operating-system sandbox.

For large split reviews, coverage and the required minimum must be checked for each relevant piece. Source changes, unresolved findings or incomplete verification prevent an honest completion claim. Historical reviews never prove a different commit is ready.

Automatic updates are off by default; no step here enables them. This illustration neither installs MOMM nor releases your work.

Workflow based on the MOMM 1.16.0 protocol. Fixture results are deterministic JavaScript, not attributed model outputs. The architecture guide retains all seven diagrams with source links and limitations.

WATCH MOMM AT WORK

See it. Understand it.
Use it on your next change.

Start with the film, or jump straight to the part you need. Real screens. A real review. Practical next steps.

THE PRACTICAL INTRODUCTION3 minutes 40 seconds · captioned

KEEP YOUR AGENT. ADD THE REVIEW TEAM.

From a second opinion
to a decision you can check.

Understand what MOMM does, install it in your harness, connect your tools, and see the governor turn reviewer claims into recorded decisions.

Watch with chapters & transcript →Copy the install / upgrade prompt →

Video narration: Built with Promptus · promptus.ai ↗

Recorded 2026-09-13 with MOMM 1.15.1 · consented synthetic Dom narration at 1.5×. Current release: 1.17.3; check the version notes. These chapter links play the same introduction, not four separate films.

Browse setup guides and short films in the media gallery →

Just need one part?

Play a chapter from the introduction, here on this page.

CURRENT STABLE RELEASE

MOMM 1.17.3

Published release ↗

What changed in this patch

  • An update no longer stops with "Harness replay did not verify" because a harness command is slow to start: until 1.17.2 the installer called a harness "not installed" when its --version took more than five seconds (seen with the Gemini CLI on a busy Windows machine, where it took between 5.5 and 7.7 seconds).
  • The installer now finds a harness command on PATH instead of timing it. A command that is found but does not answer --version within 30 seconds still counts as installed, and the installer says so: Claude Code and Antigravity are linked, and Gemini is linked if its own gemini skills link then succeeds; if that gives no answer either, the skill is not linked and the update stops. A command that is not on PATH is skipped as before, and nothing is created for it.
  • When a harness cannot be verified, the updater now gives the installer's reason. An update it cannot verify still stops and still leaves the recovery command.
  • No change to how a review runs, to SKILL.md, the reviewer roles or the review contract.
Full release notes → · Every version →
01

One writer.

Your current agent remains the only editor. Reviewer responses are untrusted evidence, never permission to change your project.

02

More than a verdict.

See who found what, which routes failed, and why the governor applied, rejected or deferred each suggestion.

03

A record you own.

Reports and decisions stay in your project’s private dashboard. The public example is a separate, sanitized export.

DON'T TRUST. VERIFY.

The useful question isn’t
“did the models agree?”

It’s “can we show what happened?”

A real development review found a process-supervisor bug. Another review produced a CRITICAL claim that failed reproduction. Both belong in the record.

Inspect the accepted fix and rejected claim →
PROJECT DEVELOPMENT SNAPSHOT · 2026-09-04
153recorded runs
139stored reports
570decision records

This is MOMM reviewing its own development work—not an independent accuracy benchmark.

Read the definitions and limitations →

KNOW THE BOUNDARY

Local control. External reviewers.

The selected providers receive your sanitized review input through their CLIs. Redaction reduces risk; it does not guarantee that confidential information is gone. Use MOMM only when sharing that material with those providers is allowed.

The daily notice requests a public version manifest. It never downloads code. Disable it with NO_UPDATE_CHECK=1 or DO_NOT_TRACK=1.

What leaves your machine →

New to MOMM?

Read the answers about reviewers, privacy, costs, installation and evidence →

Reading with an assistant? Plain-text MOMM guide (llms.txt) · Site map. The same workflow and safety boundaries are available in the written guides; no video or JavaScript is required to understand them.

PEOPLE, PURPOSE AND PROVENANCE

Professor Dominic Marrocco: turning technology into practical use

MOMM is a project by Professor Dominic Marrocco in the 42.uk collection, alongside his work with Promptus. Its practical aim is to make AI-assisted work easier to challenge, verify and explain—not simply to collect more model opinions.

His background spans technology entrepreneurship and commercialisation. A 2016 Equiinet announcement published by Nevada Business described him as a serial entrepreneur and a professor of technology commercialisation at Peking University. UNLV’s 2014 account records engineering students developing a drone business through the business-plan competition bearing his name. These are dated background sources, not confirmation of current university appointments or an academic endorsement of MOMM.

Promptus and the portable MOMM skill

Promptus documents a MoMM creative interface. This portable Agent Skill is a distinct delivery form: it coordinates installed reviewer CLIs and keeps your agent as governor. The linked public skill history begins with the predecessor release on 17 August 2026; that release date does not establish when earlier private research or prototypes began.

Local voice workflows are powered by Promptus, including the optional consented narration workflow. Promptus is not required to run this skill’s CLI reviews, and your review input is sent to the providers you select—not to a Promptus review backend.

Explore the source-linked version history → · See what the current evidence supports →

Start with one small change.

You need one ready external reviewer, not every CLI.

Set up MOMM →