Why Mo, not your coding agent's computer use

Your coding agent can already drive your app. Devin computer use gives it a desktop, Codex drives a browser with its Computer Use plugin, and Claude Code or Cursor can call Playwright MCP. Each one checks one flow at a time, on the change it made, and reports what it saw once. Mo is built for the other job: a pass over a product area, a bug confirmed by an agent that did not find it, a report with the same fields on every run, and a recheck after your coding agent ships the fix.

​

The difference

​

Bug reproduction by a second agent

An agent that sees a failure once can report only what it saw once. An expired session, a rate limit, or a mistyped value looks the same as a defect in one screenshot, and the agent cannot tell you which it was. In Mo, the agent that finds a suspected bug never confirms it. The suspected bug goes to a bug reproducer agent that starts from a clean session, with 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. If the reproducer cannot reproduce a suspected bug, the bug never reaches the report. A case that access or a sandbox limit stops comes back as blocked, not as a bug. See the agents in a session and verdicts.

​

Coverage beyond the change

A coding agent tests what it changed, because that is the context it holds. It does not know which other flows the change can break, and it has no reason to open them. Mo starts from a product objective, an uploaded spec, a Confluence page, or an open prompt. Explore agents walk the product area and record the cases, including states that no test covers. The case list is in the report, so you can read what was covered and message Mo to add what was missed. See review the coverage and use cases.

​

Parallel agents on hosted infrastructure

A coding agent with computer use checks one flow, then the next, and your terminal waits for each one. Ten flows cost ten times one flow. A Mo session gives every case its own agent and its own browser, simulator, or emulator, and runs them on Momentic’s infrastructure. A session runs a hundred or more at once, up to your plan limit. One customer session ran 116 agents, returned 27 reproduced bugs from one bug bash, and covered two days of manual QA in one run. Cases and bugs appear in the report while the session continues, and the first bugs can appear within minutes. Your terminal stays free the whole time. See parallel agents and during the session.

​

One job per agent

Your coding agent is one general agent. It plans, explores, decides, and writes up the result in one conversation, so the agent that found a bug is also the agent that decides it is a bug, and it judges with the context window it filled while exploring. A Mo session splits that work into roles, each with its own tools and its own browser:

• The session agent plans the coverage, dispatches sub-agents, removes duplicate cases and bugs, and answers you.
• Explore agents each map one product area and record test cases.
• Bug bash agents each take one case and submit one verdict.
• A bug reproducer agent takes one suspected bug and confirms it from a clean start.

The agents drive the browser with Momentic steps, the same step format the Momentic CLI runs, and they read the accessibility tree when a screenshot does not show which element to act on. See the agents in a session.

​

A fixed report shape

Teams build a version of this in-house: a coding agent plus Playwright MCP, one command for a bug bash, and a scheduled run that explores the product and posts a report. It works for a single run. The agent plans a new trajectory on every run, so two runs of the same brief return different coverage and a different write-up, and you cannot compare this week’s pass to last week’s. And the browser tooling covers web only, so mobile stays manual. A Mo session keeps the shape fixed. Every case has the same fields: name, summary, preconditions, outline, and acceptanceCriteria. Every case has one of three verdicts: verified, issues found, or blocked. Every bug has expected behavior, actual behavior, reproduction steps, and a recording. The same brief targets a web URL, an iOS build on a remote simulator, or an Android build on a remote emulator. See session reports and targets.

​

What you keep after the run

A coding agent leaves you a conversation. Close it, and the reasoning behind the verdict is gone with it. A Mo session leaves a report, and the report connects to the tools you already run:

• A case syncs to TestRail, Qase, or Testiny with the fields those tools use.
• An accepted bug files to Jira or Linear with a link back to the session.
• A run on a pull request comments the result and reports a status check you can require before a merge.
• A case carries the preconditions, outline, and acceptance criteria a Momentic test needs, so your coding agent can turn it into a .test.yaml file that runs in CI on every merge.

See integrations and what to do with an accepted bug.

​

Memory of your product

A coding agent session starts with no memory of your product, so you explain the same conventions on the next pass, and it reports the same intended behavior again. Momentic keeps a knowledge base of your terminology, your rules, and your known flows, and the agents retrieve it during a session. When you mark a bug as works as intended, Mo drafts a knowledge base entry from your reason, and a later session reads it while it explores that flow. Your Momentic tests read the same entries. See triage.

​

A session your coding agent starts

Mo does not replace the coding agent. It is a session the coding agent starts after it ships a change. You start a session in the web app, or with the mo CLI from a terminal. The mo-qa skill lets Claude Code, Cursor, Codex, or Devin install the CLI, start the session, and follow it, so your coding agent keeps working on the change it made while Mo covers the rest of the product. See the Mo CLI and install the Mo skill.

​

The fix loop

With computer use, the agent that found the bug is the agent that fixes it and the agent that decides the fix worked, and it does all three in one context window. Mo splits the loop between two agents that check each other’s work. The mo-qa skill runs it when you ask your coding agent to fix the bugs Mo found:

1. The coding agent exports the report with mo report <session-id> --require-idle. The export holds the bugs, the test cases, the verdicts, and the human triage decisions as JSON, plus the reproduction recording for each bug.
2. For each bug in scope, the coding agent reads the expected behavior, the actual behavior, and the reproduction steps, reproduces it against the code, and fixes it.
3. It serves the fix on the target Mo is testing, the tunnel for a local branch or a new preview deployment, and asks for a recheck with mo send --session-id <session-id> '<message>', naming the bug and the revision in the message.
4. Mo reruns the original reproduction. The coding agent exports the report again and compares the verdicts with the baseline. A fix counts as verified only when the original reproduction passes.

The coding agent writes the change, Mo tests it, the coding agent fixes what Mo reproduced, and Mo confirms the fix, without a person carrying screenshots between them. For a bug that stays fixed, the coding agent writes a Momentic test from the case, you run it, and you add it to the suite your CI runs, so the next release checks that flow without a Mo session. See install the Mo skill and what to do with an accepted bug.

​

When to use your coding agent instead

Use your coding agent when one flow is the whole job and it changed the code, because it can check that flow in the same conversation. Start a Mo session for the rest: a pass over a product area, a run on a pull request that reports a status check, a mobile build, and a bug confirmed by an agent that did not find it.

​

Next