Turn a browser exploration into a workflow without freezing the page

A browser agent finds an Export button, clicks it, and downloads a file. The run succeeds. Someone asks you to turn that run into a reusable workflow.

The tempting implementation is a transcript: open the same URL, click the same numbered element, wait the same number of seconds, and download again. That preserves yesterday's observations. It does not establish that those observations will still be true tomorrow.

A useful migration from exploration to repeatable execution preserves decisions and expected results, while refreshing the page evidence used to make each decision. The interface can be MCP, a CLI, or application code. The ownership of those decisions still needs to be explicit.

Start with the uncertain parts of the job

The official Playwright MCP README describes structured accessibility snapshots and discusses both MCP and CLI plus Skills. Its guidance gives you possible interfaces to evaluate; it is not a measurement of your particular workflow.

Before changing interfaces, take one successful run and annotate each step with a question: what did the agent have to discover here?

For a hypothetical monthly export, the answers might be:

• Which account is currently signed in?
• Which date filter controls the export?
• Is the export action available for this role?
• Did the click start a job, create a file, or merely open another dialog?
• Does the resulting artifact cover the requested period?

Some answers may be stable enough to express in code. Others require a fresh observation every time. Move the stable decisions into the workflow; retain observation where the answer can change.

Separate a reusable instruction from a captured reference

A reference returned by a page snapshot identifies an element in that observation. Treat it as temporary unless the tool's documented contract says otherwise.

The reusable instruction is closer to:

Inspect the current page, find the enabled export control for the selected period, confirm its meaning, and use the reference from that observation.

It is not:

Click element 17 because that worked in the discovery run.

A stable application locator can be a reasonable alternative when you control the application and can maintain its contract. An accessibility-based selection can also be appropriate. Neither approach removes the need to confirm that the action belongs to the intended account and scope.

Write the boundaries before the commands

Here is a proposed workflow contract. It is an illustrative application design, not a BrowserAct or Playwright API schema:

{
  "workflow": "monthly-export",
  "inputs": {
    "account_key": "example-account",
    "period": "2026-10"
  },
  "preconditions": [
    "live_account_matches_requested_account",
    "selected_period_matches_requested_period"
  ],
  "submission": {
    "action": "request_export",
    "uncertain_result": "inspect_existing_export_before_retry"
  },
  "completion": {
    "artifact_exists": true,
    "artifact_period_matches": true
  }
}

The contract makes three decisions reviewable: which conditions must hold before submission, what to do when submission is uncertain, and what counts as completion. Command syntax can change without silently changing these requirements.

For a BrowserAct skill, express each step in terms of the current page state and keep account checks explicit. A skill still requires an agent to interpret observations. If you need a script to run without an agent, implement that interpretation and its failure handling in code rather than leaving an instruction such as “choose the right button” unresolved.

Make uncertainty a first-class exit

A click timeout does not tell you whether the server accepted an export request. Automatically repeating the click can create duplicate jobs.

Define an uncertainty branch before you package the workflow:

Observation	Proposed response
Export history shows the requested job	Inspect that job instead of submitting again
A matching verified file already exists	Return its recorded artifact reference
An explicit validation error rejected the request	Correct the input within the permitted scope
The result cannot be determined	Stop and retain the evidence for review

These are design choices for the example, not claims that every vendor exposes an export history or an idempotency key. When the site provides neither, the safe recovery boundary may be narrower.

Validate the migration with changed state

A replay that succeeds against the same open page is weak evidence of reuse. Exercise conditions that challenge the assumptions you removed from the agent loop.

Try a different permitted date range, a different ordering of controls, an expired session, and a submission whose response is interrupted. Use test accounts or a controlled environment where these cases can be exercised safely. Check whether each case completes, rejects the input, or stops at the intended boundary.

Record artifact correctness, observation count, operator interventions, and elapsed time. If you compare model consumption, record the model, tool versions, input scope, and retry policy too. A shorter command does not establish lower total consumption after recovery and verification are included.

The result of this exercise should be a smaller set of repeated decisions, with clear evidence for every action that still depends on live state.

I work on BrowserAct. This article develops the workflow-design angle from our MCP and CLI selection guide. It presents a proposed method and fictional contract; it does not report a customer-portal test or a measured performance advantage.