Why Mo, not your coding agent's browser

Your coding agent can already open a browser. Reach for a Mo session instead when you want a pass over a whole product area rather than a check on the change you just made.

​

Coverage in parallel

A coding agent verifies in the session you are in: one browser, one flow at a time, while your terminal waits for it. A Mo session gives every test case its own agent and its own browser, simulator, or emulator, so a pass over dozens of flows does not take the sum of their run times. See parallel agents for the numbers, and run a session to start one.

​

Cover the flows you did not 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. Mo starts from a product objective, an uploaded spec, or an open prompt, and the explore agents walk the product area to find the cases, including states that no test covers. You get the case list in the report, so you can see what was covered and add what was missed. See session reports and use cases.

​

What reaches the report

An agent that sees a failure once can report only what it saw once, and you are left deciding whether to trust it. In Mo, a suspected bug goes to a bug reproducer agent that starts from a clean session with no state from the agent that found it. Only a bug it reproduces reaches you. A case that access blocks is reported as blocked instead of as a bug. See session reports.

​

What Mo remembers about your product

A coding agent session starts with no memory of your product, so you explain the same conventions on the next pass. Momentic keeps a knowledge base of your terminology, your rules, and your known flows, and the agents retrieve it during a session. Triage adds to it, so a later run does not report the same intended behavior again. See triage.

​

Next