> ## 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.

# Momentic vs a coding agent driving a browser

> When to let your coding agent verify a change with computer use, and when to run a Momentic test and hand the result back to the agent.

Cursor, Claude Code, Codex, and Devin can open a browser and check the change
they just made. That works for one diff in one session, and the check disappears
with the session. Momentic keeps the check as a YAML test in your repo, runs it
on managed browsers, emulators, and simulators, and returns the evidence from a
failing step to the agent over its [MCP server](/docs/coding-agents/mcp-server). For
a running app with no test suite, see [Mo](/docs/mo).

## What each one is for

|                   | Coding agent with computer use                      | Momentic                                                                                                       |
| ----------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Starting point    | The diff in the current session.                    | A test file, or a goal for an [agentic step](/docs/core-concepts/agentic-testing).                                  |
| After the session | A message in the chat.                              | YAML in your repo, reviewed in a pull request and run by CI.                                                   |
| Repeat runs       | The agent reasons about the page again.             | Steps replay from the [step cache](/docs/reliability/step-cache) with no AI call on a cache hit.                    |
| A moved element   | The run fails, or the agent guesses a new selector. | [Auto-heal](/docs/reliability/auto-maintenance#locator-auto-healing) re-resolves it mid-run.                        |
| Concurrency       | One browser per session.                            | [Hosted browsers, emulators, and simulators](/docs/running-tests/hosted-test-environments), sharded across CI jobs. |
| Platforms         | A browser.                                          | Web, iOS simulators, and Android emulators from the same YAML format.                                          |
| Product context   | What the agent reads in this session.               | The [knowledge base](/docs/ai/knowledge-base) and [memory](/docs/ai/memory), retrieved on every AI-assisted step.        |

<Note>
  Agentic steps are non-deterministic. Keep critical paths step-based and wrap
  each agentic step in an assertion. See [agentic
  testing](/docs/core-concepts/agentic-testing).
</Note>

## Read a failing run

When a coding agent maintains the suite, it also debugs the runner. It re-runs a
flaky spec, reads a stack trace, and guesses which selector moved. Each of those
turns costs wall time before the agent reaches the product bug.

The test adapts as it runs, so that work does not reach your agent.
[Auto-heal](/docs/reliability/auto-maintenance#locator-auto-healing) re-resolves a
moved locator mid-run,
[failure recovery](/docs/reliability/auto-maintenance#failure-recovery) clears a
transient obstruction and retries the step, and
[classification](/docs/guides/auto-heal/in-flow-classification) triages what broke.

When a run does fail, it produces artifacts per step, and the agent reads them
through the MCP server:

* Screenshots before and after each step.
* A trace with the DOM, the network requests, and the console output.
* The step execution order with each step's status and duration.
* Video, when [`recordVideo`](/docs/configuration/momentic-config#recordvideo) is on.

See [run artifacts](/docs/running-tests/results#artifacts) for where each one is
stored, and
[request visual evidence](/docs/coding-agents/mcp-server#inspect-visual-artifacts)
for the prompts that make an agent display them.

A typical loop:

<Steps>
  <Step title="CI runs the suite">
    `npx momentic run` fails on a step and uploads the run.
  </Step>

  <Step title="The agent reads the failing step">
    With the `momentic-maintain` skill, the agent finds the run for the branch,
    reads the saved classification, and opens the artifacts for the first step
    that changed behavior.
  </Step>

  <Step title="The agent decides what broke">
    A product bug goes back into the code. A stale locator or an intended
    behavior change goes into the test file, in the same pull request as the
    code.
  </Step>
</Steps>

Devin can drive this loop with no extra setup beyond the MCP entry. See
[Devin](/docs/integrations/devin).

## What a repeat run costs

A coding agent that maintains a Playwright suite calls a model on every failure,
and again on every rerun of a flaky spec. Because the run adapts itself, your
agent is called for a product change and not for a test change, so the loop runs
less often and each cycle is shorter.

* Each run reports its duration and cost in the dashboard. See
  [run results](/docs/running-tests/results).
* [Hosted browsers](/docs/running-tests/hosted-test-environments) run the suite off
  your CI machines, so the runners can be lower-spec.

## Product context between runs

An agent session starts with no memory of your product. The
[knowledge base](/docs/ai/knowledge-base) holds your terminology, per-agent rules,
and known flows, and Momentic retrieves the relevant entries on every
AI-assisted step. A decision you record, such as marking a finding expected
behavior, becomes an entry that later runs retrieve.

## When the coding agent is the better tool

* The check only covers the diff you are writing right now. Use `momentic-spec`
  so the affected tests land with the change; see
  [spec-driven development](/docs/coding-agents/mcp-server#spec-driven-development).
* The task is a one-off inspection you do not want to keep, such as reading a
  staging page to confirm a deploy.
* The work is a code change. Momentic does not read or write your product code.

**Momentic is the right call if** the check must outlive the session, run on
every merge, and cover flows nobody touched in this diff, and if you want the
failing step handed back to your agent with its evidence instead of a stack
trace.

## Related

* [MCP server](/docs/coding-agents/mcp-server)
* [Devin](/docs/integrations/devin)
* [Momentic vs Playwright MCP](/docs/comparisons/playwright-mcp)
* [Momentic vs Stagehand](/docs/comparisons/stagehand)