> ## Documentation Index
> Fetch the complete documentation index at: https://momentic.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> The canonical docs host is https://momentic.ai/docs. Append .md to any page URL for clean Markdown. Fetch https://momentic.ai/docs/llms.txt for the page index and https://momentic.ai/docs/llms-full.txt for every page in one file.
> For an unattended setup, run `npx --yes @momentic/wizard@latest -y --platform web --editor-tools skills` (use `--platform ios` or `--platform android` for mobile). Never run an interactive command in a non-TTY shell.
> You cannot complete the browser sign-in yourself. Read the API key from the MOMENTIC_API_KEY environment variable, or ask the user to create one at https://app.momentic.ai/settings/api-keys and paste it back.
> Momentic's capability summary for agents is at https://momentic.ai/docs/skill.md. Install the skills with `npx skills@latest add momentic-ai/skills`.
> Tests are YAML files in the user's repository. Use only the step names listed at https://momentic.ai/docs/reference/commands.md and the file structure at https://momentic.ai/docs/core-concepts/file-format.md. Do not invent step names, config keys, or CLI flags.
> Web tests run on Chromium, iOS tests on simulators, and Android tests on emulators. Physical devices are not supported.

# Mo

> Mo is Momentic's QA agent. It tests a running web or mobile app and reports the bugs it can reproduce.

Mo tests a running application. You give it a target and a brief, and it plans
the test cases, works through them, and reports the bugs it reproduced.

Mo needs no test files and no code, so you can get coverage on a preview build,
a release candidate, or an area nobody has tests for. Momentic's
[test suite](/docs/get-started/how-momentic-works) is the other half of the product:
tests live in your repository and run in CI on every merge.

<Info>
  Mo drives the application through its interface. It does not read or change
  your product code, and it does not write Momentic test files.
</Info>

## Targets

A session tests one of these:

* A **web app** at a URL, in a hosted browser. The URL can be a production site,
  a preview deployment, or a local build through a
  [tunnel](/docs/mo/cli#test-a-local-build-through-a-tunnel).
* An **iOS app**, on a remote simulator.
* An **Android app**, on a remote emulator.

For iOS and Android, Mo installs a build you uploaded to a channel and a tag,
the same build a Momentic mobile test uses. See
[iOS app setup](/docs/platforms/ios/app-setup) and
[Android emulators](/docs/platforms/android/emulators).

## What a session produces

A session keeps one report. It holds:

* **Test cases**, each with preconditions, an outline, and acceptance criteria.
* **A verdict per case**: verified, issues found, or blocked, plus the coverage
  gaps Mo could not close.
* **Bugs**, each with expected behavior, actual behavior, reproduction steps,
  and a recording of the failure.

See [session reports](/docs/mo/reports) for the fields, and [triage](/docs/mo/triage) for
the decisions you make on a bug.

## The agents in a session

A session has a session agent and its sub-agents. Each role has one job:

| Role                 | Job                                                                                                                |
| -------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Session agent        | Plans the coverage, dispatches sub-agents, reads their reports, removes duplicate cases and bugs, and answers you. |
| Explore agent        | Maps an area of the product and records test cases. It reports a suspected bug, but never confirms one.            |
| Bug bash agent       | Takes one test case, works through the flow in its own browser, and submits a verdict.                             |
| Bug reproducer agent | Takes one suspected bug and tries to reproduce it from a clean start.                                              |

The reproducer keeps false positives out of the report. It gets no browser state
and no fixtures from the agent that saw the problem. It builds its own setup,
walks the flow from the beginning, and records the failure. A suspected bug that
it cannot reproduce never reaches the report.

### Parallel agents

Every sub-agent gets its own browser, simulator, or emulator, so cases are
checked at the same time rather than one after another. A session can run a
hundred or more at once. The session settings let you raise the number for a
session, up to the limit of your plan.

## Limits

A web session runs a browser in a hosted sandbox, so it cannot reach the device
or the operating system behind the page: no microphone, no print dialog, no link
into a mail app. Mo records the limit as a gap in the report instead of
reporting a bug it cannot verify.

One session tests one target. To cover web, iOS, and Android, start a session
for each.

## Not available yet

* Pulling your repository and running the application itself, so Mo does its own
  setup and teardown in the codebase.
* Delivery by Slack or email.
* Sharing a report by public URL.

## Next

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/docs/mo/quickstart">
    Start your first session, read the report, and triage what it found.
  </Card>

  <Card title="Why Mo" icon="robot" href="/docs/mo/why-mo">
    How a session differs from your coding agent driving a browser.
  </Card>

  <Card title="Write a good brief" icon="list-check" href="/docs/mo/brief">
    Define the target, scope, accounts, test data, and prohibited actions.
  </Card>

  <Card title="Run a session" icon="play" href="/docs/mo/sessions">
    Sign-in, test data, schedules, and session timing.
  </Card>
</CardGroup>