Skip to main content
A session starts in the Mo composer in the Momentic app, or with qa start from the CLI. Every web agent in the session runs on Momentic browser tools. You write what to test, and Mo asks you for anything it still needs before it starts work. The brief decides the boundary of the run. See write a good brief.

​
Start settings

Beyond the brief, a session takes three knobs:
  • Effort (low, medium, high, or max, default medium) sets how long Mo tests and how many sub-agents it runs at once. See choose an effort.
  • Interaction speed sets browser pacing to default or human. Use human to add a delay between browser actions.
  • Environment names a configured Momentic environment. Mo sees variable names and descriptions and can use their values during execution. BASE_URL is also visible as a literal URL and sets the starting URL, so one brief can aim at staging today and production tomorrow. The session header shows the environment it ran in.

​
Choose an effort

Match the effort to the size of what you ask Mo to test: Testing time counts the minutes while Mo or its sub-agents are working or Mo is waiting on them, and starts when testing begins. Time spent clarifying the request does not count. Mo and its sub-agents get reminders as the deadline approaches. At the deadline, Mo stops the sub-agents still working, lets bug reproductions already in progress finish, and reports what it covered and what it left unfinished. If you change the request mid-session, Mo can restart the clock for the new scope. At high and max on web, Mo can split a broad request into separate areas and hand each one to a coordinating agent that plans and steers its own sub-agents. Mo keeps covering the rest itself. This lets a large session keep many sub-agents busy on distinct flows instead of a few broad ones. Sessions started for a GitHub pull request do not split. On a full open-source web application in Momentic’s evaluations, a one-hour high session finds several times as many confirmed bugs as a general-purpose coding agent given the same hour. With the work split into areas at max, Mo finds more than three times as many confirmed bugs in the same time as without the split.
max is deliberately tuned for thoroughness. It runs many more flows than the other levels, so a max session uses considerably more agent time. The volume of flows it executes often lowers the cost per bug found, but the total for the session is higher. Reserve it for full-application coverage.

​
Workspace repositories

Connect GitHub, then pick repositories on the Mo workspace page. Sessions use local checkouts at /home/user/workspace/repos/<repo-id> with read-only Git access. Mo attempts to refresh their default branches at session start. If a refresh fails, it can retain a cached checkout. The session agent can read the code, run git log over a diff window, and investigate the changes related to an observed behavior. Use this context for diff-based regression. Local checkouts retain about two weeks of commit history. An inactive branch may have only its latest commit. For an older investigation, Mo can fetch the selected revision’s full history in the background. It tells you before starting because the download can take a while. You can keep asking questions while it runs. Only the default branch is refreshed at session start. Other branches can be stale or missing. Name the branch or commit you want checked in the brief so Mo can fetch it inside the sandbox. Ask Mo to confirm the checked-out revision before relying on a diff-based run. The checkout provides context for planning and debugging; Mo tests your running app rather than starting it from the checkout.

​
Sign-in

Give Mo a test account and the instructions it needs to sign in. Each web sub-agent has a separate browser. Mo can establish authentication once and pass the saved authentication state to sub-agents using that account. If sign-in, sign-out, or account switching is under test, describe it in the brief. For credentials, one-time codes, and MFA, see give Mo access to your site.

​
Reuse credentials across sessions

Save a test account in a workspace environment when several sessions need the same sign-in details:
  1. Open Mo environments and choose Create environment. Enter a name such as staging and the app’s Base URL.
  2. Open the environment and use Add variable to save QA_EMAIL and QA_PASSWORD. Turn on Sensitive for passwords and tokens. Add a Note that explains which account or role each variable belongs to.
  3. Select that Environment in the session composer. In the brief, name the variables and the sign-in steps rather than copying their values.
For a web session from the CLI, select the same environment. Single quotes keep the shell from expanding the variable references:
Mo and its sub-agents can use the saved values during execution. The environment tool lists variable names and notes; it shows BASE_URL as a URL and keeps other values out of that listing. Sensitive values cannot be revealed or copied from the environment page after saving. Mo loads these environments from your workspace. Repository tests use the environment definitions in momentic.config.yaml. For values needed by only one session, use the CLI’s --env-var or --env-file options.

​
Set up and tear down test data

Some products need a fresh user per run, or an account with a role or a license that the flow uses up. Name a setup endpoint in the brief, with its payload and the response field that holds the account to sign in with, and name a teardown endpoint for the data the run leaves behind. Mo calls setup before the sub-agents start and teardown after the pass.

​
During the session

Bugs appear in the report while the run continues, and the first bugs can appear within minutes. Open the transcript of any sub-agent to see what it did, or message Mo to change the scope. You do not have to wait for the session to finish. qa send steers the active turn when Mo is working. Mo reads your message between tool calls and continues its work. qa stop stops the root turn, and qa stop --subagents stops every active sub-agent turn too. qa archive stops and archives the session. Use qa unarchive to restore it.

​
Repeat a session on a schedule

Open Schedules in the Mo section of the app. A schedule holds a name, the prompt, a cron expression, and a time zone. It can also pin an Environment and set Effort and Interaction speed. These settings apply to every recurring run and to Run now. Each occurrence starts a new session, and the schedule page lists the past runs and their reports. A schedule that names an environment you later delete fails at session start instead of running without its variables.

​
Find a session

The Sessions page lists every session in the organization. Filter it by platform (Web, Android, iOS) and by environment; the environment list includes every configured environment, not only those with sessions. The filters live in the URL, so a filtered view can be shared.

​
What a pass costs

A session bills the active runtime of its agents, not the wall time of the session. Each agent reports the seconds it spent working. A session also bills the hosted browser time the sub-agents use, the emulator or simulator time for a mobile session, and the inference the agents use, which Momentic bills at cost. The scope of the brief and the effort drive the cost. Higher effort runs more agents for longer.

​
Next

Session reports

Agent outcomes, findings, and bug details.

Triage

Accept a bug, or record intended behavior for the next run.