---
title: "Mo, the AI QA engineer."
description: "Mo is an AI QA engineer. Point it at your app on web, iOS, or Android and get bugs back, each with a recording and repro steps. Try it on your app."
canonical: "https://momentic.ai/mo"
last-updated: "2026-10-06T23:08:50.793Z"
---

# Mo, the AI QA engineer.

URL: https://momentic.ai/mo

platform   / mo

Mo tests your app from a prompt. Review what passed, what broke, and what was blocked before you ship.

[Try for free](https://app.momentic.ai/mo) [Get a demo](/sales)

Use a web URL, or tunnel your local or private app. Mobile sessions use an uploaded iOS or Android build and require mobile access.

## Bug bashing for web and mobile apps.

117,010   bugs caught before deploy

Agents

Mo runs independent test cases in parallel.

Findings

Review bugs, reproduction steps, and available evidence.

Prompts

Tell Mo what to test and what should happen.

Platforms

Test a web URL or an uploaded Android or iOS build.

## From a prompt to verified behavior.

Describe the flows that should work. Mo explores the app and checks the outcomes.

01

### Point

Provide a URL or uploaded mobile build. Describe expected behavior, test accounts, data rules, scope, and actions to avoid. Mo asks for missing context in the session chat.

02

### Bash

Mo plans test cases and runs them in parallel, up to your plan limit. A separate agent reproduces functional bugs before they're reported. Blocked cases remain visible.

03

### Report

Findings appear in the app while the session runs. Review case verdicts, expected and actual behavior, reproduction steps, and available evidence. Export the report for your coding agent to investigate a fix.

## Verify the build against your prompt.

Start in the app or with the CLI. Give Mo the target, expected behavior, and actions to avoid, then review what it verified and what was blocked.

Start a web session bash

```bash
npm install -g qa
qa login
qa start "Test the cart at https://staging.example.com/cart.
Check quantity changes, totals, and persistence after refresh.
Do not place orders or submit payments."

# Use the session ID returned by qa start.
qa status <session-id>
qa read <session-id>
qa report <session-id> --require-idle --output ./mo-report
```

The npm install needs Node.js 22.12+ in the 22.x series, or 24+. Report export checks readiness once. If the report is not ready, keep following the session.

### Make the target reachable

Use a staging or preview URL and provide sign-in instructions. Tunnel a local or private app, and allow Mo through deployment protection. Mobile sessions need access and an uploaded build.

### Define the expected behavior

Name the flow, the outcome to check, test data, and prohibited actions. Mo asks for missing access or context in the session chat.

### Review tested and blocked cases

The report records case verdicts and bug evidence. Blocked cases haven't been verified. A separate agent tries to reproduce functional bugs. Recordings are included when available.

### Fix, then recheck

Accept a bug or mark it as working as intended. Review suggested Knowledge base entries. After deploying a fix, ask Mo to rerun the reproduction and export the updated report.

Read the docs

- [Mo quickstart](/docs/mo/quickstart)
- [Write a testing prompt](/docs/mo/brief)
- [Session reports](/docs/mo/reports)

## Know what works before you ship.

Review tested flows, reproduced bugs, and blocked cases. After a fix is deployed, ask Mo to recheck it.

### Bug bash on demand

Give Mo the areas and expected behavior to check. Agents execute cases concurrently and file findings with reproduction steps and available recordings.

Check the build when it's ready.

### Make dogfooding count

Run Mo before your team uses the build. Review failed and blocked cases, then spend the human session on product judgment.

Give your team findings to work from.

### Exploratory testing

Mo chooses flows from your prompt and the running app. A separate agent reproduces functional bugs before they're filed.

Test beyond the cases you've already written.

### Another check before release

Start a session against the build you want to release. Findings appear while it runs; human testers still cover physical hardware and local product requirements.

Review findings as they're filed.

### Keep checking the behavior

Schedule another Mo pass or provide merged diffs to focus exploration. Your coding agent can turn covered flows into repository tests for CI.

Schedule another pass or keep a repository test.

### Coverage across your targets

Start one session per target. Web sessions use hosted browsers; iOS uses simulators and Android uses emulators. Review tested and blocked cases for each target.

Review coverage for each requested target.

Trusted by teams that ship every day.

A Fortune 1000 file-collaboration platform · 700M+ registered users

“We pointed it at staging before a release and it found  27 bugs in an afternoon  . Nobody wrote a test. The engineers just got the report.”

Senior Engineering Manager   File-collaboration platform

27

bugs from one bug bash

116

agents exploring at once

2 days

of manual QA automated in a single run

[30 min   daily test execution, down from 7 hours   "Momentic gave us a fast and reliable way to validate Poe.com's AI responses, even when they weren't deterministic."  Momoko F. Head of Product Operations, Quora](/customers/quora)

[8x   increase in release cadence   "It's like giving someone your QA checklist and watching them execute it for you!"  Sriram S. Engineering Lead, Source Control, Retool](/customers/retool)

[80%   faster release cycles   "With Momentic, we've caught bugs that would have eluded even our most diligent internal tests."  Alex C. CTO, GPTZero](/customers/gptzero)

[6x   faster end-to-end test creation   "We've already seen a 30% decrease in production incidents thanks to Momentic's automated testing."  Hanna K. Head of QA, CoverGo](/customers/covergo)

[85%   reduction in production incidents   "Momentic gives us reliable end-to-end coverage, so we can focus on features instead of maintaining tests."  Alec H. Staff AI Engineer, Mutiny](/customers/mutiny)

[Browse all](/customers)

## Mo covers web, iOS, and Android.

One prompt per target. Hosted browsers, simulators, or emulators.

[01    Web     Point Mo at any URL our hosted browsers can reach, or a local build through a tunnel. It bug bashes the live app.](/web-app-testing)[02    iOS     Point Mo at an uploaded iOS build. The bash runs on a Momentic-hosted simulator.](/ios-testing)[03    Android     Point Mo at an uploaded Android build. The bash runs on a Momentic-hosted emulator.](/android-testing)

## Mo, answered.

How much of my product does Mo actually cover?    You choose the scope. The report shows tested flows, findings, and any blocked or unverified cases.    Do I ever have to write or maintain tests?    No. There is no test suite. You give Mo an objective and read the report.    We already point a coding agent at Playwright. Why Mo?    Mo plans test cases from your running app and prompt without maintaining a saved test suite. Agents run the cases in parallel, up to your plan limit. A separate agent reproduces functional bugs before they're reported.    We have coding agents but no QA team. Is Mo for us?    Yes. Give Mo a build or preview and the behavior to check. Your team reviews its cases, findings, and coverage gaps. Your coding agent can investigate a fix from an exported report.    What does Mo need to reach my staging environment?    A reachable URL or uploaded mobile build, sign-in instructions, and a test account. A [tunnel](/docs/mo/tunneling) or Connector gives Mo access to a private app. Pass credentials through environment variables. Session data and available evidence are stored in the Mo app; see [security and data use](/security).    How do I start a run?    In the app composer, with the [CLI](/docs/mo/cli), or on a cron schedule. The Momentic GitHub App gives Mo read-only repository and pull request context. Include the pull request, preview URL, and expected behavior in your prompt.    Is it safe to run Mo on production?    Yes, with boundaries in the prompt. You name the actions Mo must not take (submit a payment, delete an order, touch admin surfaces) and the data it must not modify. Most teams still point it at staging first.    How does Mo decide what counts as a bug?    A separate agent reproduces suspected functional bugs before they enter the report. Findings include expected and actual behavior, reproduction steps, and recordings when available. Static findings, such as typos, can use a screenshot instead. The report also shows blocked coverage.    Can Mo replace our bug bash?    Mo executes cases from your prompt and files findings with reproduction steps and available recordings. Review blocked coverage. Keep people for product judgment and exploratory feedback.    Can Mo do exploratory testing?    Yes, and that is the default. You give Mo an objective instead of a script, and Mo decides which flows to try.    We dogfood before every release. Where does Mo fit?    Run Mo on the build first, then dogfood. Your team reads a report instead of walking the same flows, and it spends the session on what Mo could not judge.    Does Mo replace our outsourced QA team?    It replaces the repeat passes, not the people. Mo runs the same flows on demand and reports the same day. Human testers still cover local payment methods and real hardware.    Can we keep the flows Mo tested as a suite?    Yes, as Momentic tests. A flow Mo covered becomes plain-English steps in a YAML file in your repo. Your coding agent writes that file over our MCP server, and the CLI runs it in CI.    How many agents does Mo run at once?    A hundred or more on a single bug bash, up to your plan limit. Each agent gets its own hosted browser for web, or a simulator or emulator for a mobile build.    How is Mo different from Codex or Devin driving a browser?    Mo starts from a running app and your prompt. Agents plan and run test cases, and a separate agent reproduces functional bugs. Agents run in parallel on hosted browsers, simulators, or emulators, up to your plan limit. Your coding agent can read the report to investigate a fix.    How do you keep false positives out of the report?    A separate agent starts from a clean browser or device session, follows the authentication and setup instructions, and uses equivalent test data. A functional bug it cannot reproduce is not filed as confirmed. Static findings use screenshots without a separate reproduction run.    Does Mo learn how our product works?    Yes. Agents look up relevant Knowledge base entries on each AI-assisted step. Mark a finding as working as intended and give the reason. Mo drafts a linked entry; review and accept it to make that guidance available to later sessions.    Do we have to choose between Mo and our coding agents?    No. The [CLI](/docs/mo/cli) exports findings, reproduction steps, and available evidence as files your coding agent can read. It can investigate a fix, then ask Mo to recheck the deployed change and export the updated report.    Do the bugs go to Jira or Linear?    They can. The report lives in the Momentic app; its test cases sync to TestRail, Qase, or Testiny, and an accepted bug files to Jira or Linear.    We already have a Playwright suite. Why do we need Mo?    Mo needs no test script. You give it an objective or a spec, it explores the running app, writes the cases itself and runs them across many browsers at the same time. Your suite covers the cases someone already wrote, so Mo is how you find the bugs that have no case yet.    How is this priced?    Mo is self-serve. Sign up and you get $250 in Mo credits on us. Sessions bill active agent runtime, hosted runtime, and inference against a separate Mo balance. Inspect a session with [qa cost](/docs/cli-reference/mo/commands/cost). See [pricing](/pricing) for repository-test step credits.

Still have additional questions?

## Verify what you ship.

Start a bug bash, or book a demo using your app.

[Try for free](https://app.momentic.ai/mo) [Get a demo](/sales)
