Deterministic browser automation vs AI agents: choose the execution boundary

The browser clicked the button. The engineering question comes next: who chose that button, what was allowed to change, and which observation proves the task is finished?

Deterministic browser automation executes an explicitly authored procedure. An AI browser agent selects some actions at runtime from a goal and its current observations. Both can use the same browser driver, and both need a separate acceptance check. Choose how much runtime judgment the task requires before choosing a product.

This comparison includes supplied October 15, 2026 screenshots of a fixed Playwright script and an independent runtime agent completing the same two-item task. Both records report accepted results. Different starting states, browsers, viewports and timing boundaries make these workflow demonstrations rather than a controlled performance benchmark.

What changes when a model chooses the next action?

The action-selection boundary separates a fixed browser program from an agent loop. A script can branch on page state and wait for conditions without asking a model. An agent can use deterministic click and fill tools while deciding which ones to call next.

A test written by AI can still execute as a fixed script. Conversely, an agent calling Playwright through MCP is still making runtime decisions. The transport doesn't decide whether the workflow is agentic.

Microsoft's Playwright MCP introduction describes structured page observations for model-driven interaction. Playwright's locator documentation describes how explicit programs identify elements. These are compatible building blocks with different roles in the control loop.

Deterministic execution describes the procedure. It does not freeze the website, network timing or account state. A fixed program can run consistently against changing data and still return different valid records.

When does a fixed browser script fit the job?

A fixed script fits a repeated workflow whose inputs, permitted actions and acceptance conditions can be written explicitly. Examples include a known export screen, a reviewed form flow or a regression check with a precise expected state.

Playwright auto-waits for actionability. A button can move or render late while a semantic locator still finds it. Comparing a capable agent with an intentionally brittle coordinate script would measure implementation choices rather than the architectural boundary.

A script also needs application-level checks. An enabled submit button proves that a click can be dispatched; it doesn't prove an export exists or that the correct record changed. Use retrying assertions for observable state instead of arbitrary sleep intervals.

The ongoing work is explicit maintenance. When a meaningful page contract changes, preserve the failing run, update the intended branch and review the revised check. Quietly broadening a locator until the test passes can change what the task means.

The supplied fixed-script record shows why setup and runtime recovery need separate labels. Attempt 1 failed after 0.537 seconds, before opening the target page or creating any todos: its browser command-line audit required --enable-automation. The original script, hash and failure log were retained. A separate corrected attempt added the launch flag while preserving the task assertions.

The corrected attempt passed the task checks. Model processing stayed outside the script execution interval; the executed script hash was reported unchanged. Codex helped prepare and repair the program, while the frozen browser procedure selected its actions during execution. The initial failure still counts as setup friction.

When does an AI browser agent fit the job?

A runtime agent fits work where the next step needs interpretation that has not been encoded into a maintained procedure. It might locate comparable information on unfamiliar supplier pages or choose a navigation path after reading the available options.

The extra judgment must be inspectable. Record the observation supplied to the model, the target it chose and the action actually dispatched. If the goal was to complete one exact todo, selecting a similarly named item is a failure even when the interface looks reasonable afterward.

An agent can use accessibility snapshots, DOM observations or screenshots. “Agent clicking” does not mean every system relies on raw screen coordinates. The observation channel and action-selection policy are separate choices.

Keep the model's freedom inside a defined task. A missing target should trigger a fresh observation or a stop, not permission to change a different item. For a deeper verification method, see browser agent verification.

How do you compare both routes on the same task?

A useful comparison starts with a shared acceptance contract rather than a preferred winner. The public TodoMVC demo supports a bounded state task: create two uniquely named items, complete only one, inspect both filters, reload and verify both items' states.

Use Automation boundary <run-id> A and Automation boundary <run-id> B. A passes only when it is completed; B passes only when it remains active. Both exact texts must survive reload. Preserve unrelated rows and verify their initial states remain unchanged.

Run a frozen Playwright implementation and an independent agent against equivalent starting state. Record differences in browser build, profile, viewport and task context. Don't give the second route the first route's output to copy.

The evidence should cover each part of the contract:

The guard is an injected test condition. It does not represent a naturally occurring product failure. Record it separately and keep the same acceptance rules for both routes.

A single pair of runs can illustrate the workflow. For a benchmark, predeclare repetitions and rotate run order. A reliability claim needs repeated cases, including failures, with an independent verifier. Don't convert one accepted demonstration into a success rate.

The supplied fixed-script run 20261015T064926Z-6a36a89a used a fresh headed browser context with empty starting storage, a 1280 by 800 viewport and explicit readiness conditions. Its summary reports one A and one B created, both initially unchecked; zero matches and no click for the deliberate A-missing target; only A completed; correct Completed and Active filter membership; and both exact texts and states preserved after returning to All and reloading. No unrelated rows existed initially.

Its environment record lists Playwright/playwright-core 1.62.1, Chrome 155.0.8059.40 and Node v26.8.1. The corrected attempt recorded a console resource 404. These are observations for this example, not required versions or evidence that either automation approach is generally more reliable.

What should you measure besides elapsed time?

Elapsed time is useful only when its start, finish and exclusions are clear. Separate installation and script authoring from browser execution. Keep model reasoning inside the agent task duration when comparing end-to-end work; a browser-call-only segment is a separate metric.

Record accepted completion, unexpected state changes, retries and human corrections. If a route fails, include the failed attempt and the cost of repair. A fast run that changes the wrong item has no accepted-task result.

Token usage requires authoritative client telemetry. Response length is not a billable token count. A fixed browser script can avoid runtime model calls, but it still consumes browser compute and maintenance effort, so “no model calls” does not mean the workflow has zero operating cost.

A practical run record can use this shape:

{
  "route": "fixed-script-or-runtime-agent",
  "run_id": "record-the-actual-id",
  "accepted": null,
  "unexpected_mutations": null,
  "execution_ms": null,
  "retries": null,
  "human_interventions": null,
  "model_tokens": null,
  "limitations": []
}

These null values are unmeasured fields in a proposed schema, not results. Store raw observations before filling them. A later reviewer should be able to reproduce the acceptance decision without trusting the agent's final paragraph.

The supplied records expose the main comparison limits:

The agent did not read the fixed-script files or outputs. Its run reported that fixed-run settings were unavailable, so matching was unverified during execution. The later supplied fixed-run capture establishes a different viewport and browser. The script began empty; the agent preserved six existing rows. Do not divide 319.487 seconds by 2.218 seconds and present a speed ratio: those intervals include different work. The 7.124-second browser API subtotal is also incomplete and excludes the full agent loop. No comparable token or cost telemetry is supplied.

How should a hybrid workflow handle changes?

A hybrid workflow gives a model a narrow exception to resolve while keeping the accepted task fixed. The model can inspect a changed page and propose a new locator; a verifier must still confirm that it selects the intended record and changes only permitted state.

Preserve the original failure before attempting recovery. Check whether a timed-out write already happened, then resume from the last confirmed state. Replaying the whole task can create duplicates or repeat an external action.

For a maintained workflow, promote an accepted repair into reviewed code rather than rediscovering the same decision on every run. Keep the original prompt and proposed patch with the revised procedure. If the page doesn't support a trustworthy target, stop and hand the case to a person.

This is an execution-design decision. The Stagehand and Playwright comparison covers those products, and the AI-generated E2E review guide owns qualification of generated tests for CI.

Where does ego(lite) fit in an agent workflow?

A visible ego(lite) Space is useful when the exception needs a person to see the source and take over the current task. The ego-browser guide describes its agent connection, while the Space documentation explains the workspace.

The supplied independent agent run used Codex with the installed ego-browser helper in a Space named Execution boundary: ego. The controller reported live page observations and selected subsequent browser operations without reading the fixed-script files or outputs. The overview identifies the workspace; the detail retains the controller beside the native live task controls.

The value is inspectable collaboration around uncertain steps. It does not make the model's decisions deterministic or replace a maintained test suite. Use reviewed scripts for known repeated checks, and bring a visible Space into workflows where source review or human continuation changes the next action.

Independent run 20261015T071813Z-247d7161 reports all 11 checks passed. A and B were each created once and initially unchecked. The absent A-missing target had zero exact matches and received no click. Only A was completed; Completed included A and excluded B, while Active included B and excluded A. After returning to All and reloading, both full texts persisted with A completed and B active. All six unrelated rows retained their text, state and order.

The record reports zero todo retries, a browser-version metadata fallback and a screenshot scroll correction. Runtime ego reported 0.6.0.5; installed bundle metadata also contained 0.6.0.10, so those values are not interchangeable. The reported runtime used Chromium 154.0.8037.44 and Node 24.21.0. The controller UI showed GPT-6.1 Sol with High reasoning; the exact backend model identifier remained unknown. These environment differences limit comparison, while the screenshots support the narrower outcome: each path preserved the same requested A/B result under its own observed conditions.

FAQ

These questions distinguish execution policy, browser tools and the evidence needed for a meaningful comparison.

Does deterministic automation always return the same data?

A deterministic procedure can read different data from a changing website. Repeatability concerns the defined steps and validation, not a promise that external content never changes.

Is a Playwright script written by AI an AI agent?

A frozen script executes without runtime model decisions unless it explicitly calls a model. AI-assisted authoring and agentic execution are different stages.

Does using MCP make automation deterministic?

MCP defines a tool interface. An agent can choose those tools dynamically, so the protocol alone does not fix the plan or guarantee task completion.

Are browser agents limited to screenshot clicking?

Browser agents can use structured accessibility or DOM observations as well as screenshots. Record the channel actually used when explaining behavior.

Can a script handle a changing layout?

A script can handle changes that its locators, waits and branches accommodate. A positional selector and a semantic locator have different failure boundaries.

Can an agent repair every broken workflow?

An agent can attempt only the recovery actions its task permits. Missing access, ambiguous identity and changed business meaning may require a person to stop or revise the task.

Should both routes use the same browser?

Matching the browser build and starting state reduces avoidable differences. When matching isn't possible, report the difference and narrow the conclusion.

Is a successful click a successful task?

A successful click confirms an action was dispatched. Acceptance needs a fresh observation of the intended application state.

Can a single run establish which route is faster?

One timed run describes that attempt. A general performance comparison needs matched timing boundaries, repeated runs and retained failures.

When should an agent result become a CI check?

A recurring check needs reviewed assertions and a maintained execution contract. Keep exploratory observations separate from the test that gates a release.

Related reading

The Browser Use and Playwright comparison covers a named product pair. The browser automation debugging guide explains how to locate a failed transition. For a task that needs visible human continuation, download ego(lite) and keep the source in a dedicated Space.