A browser agent changes a report filter, sees a table and exports the rows. The file looks plausible, but it contains the previous filter's results.

The click succeeded. The table existed. Neither observation established that the application had finished presenting the newly requested data.

For developers building extraction skills or agent-driven browser checks, this is a readiness problem. Give the workflow an explicit way to recognize the requested application state before it reads the result. A longer pause may hide the problem during a demo without defining what completion actually means.

Methodology and scope

We reviewed Playwright's actionability, Locator API and assertion documentation on September 27, 2026. The workflow below is a proposed design, not a test of a particular website or a claim about measured flakiness.

The selection criterion was a narrow transition: a user changes a filter and the agent must distinguish old, loading, empty and complete results. This is separate from choosing a crawler or proving that a paginated API search covered an entire dataset.

Use the ideas only within authorized browsing. Reading a report does not authorize an agent to change shared settings or submit unrelated forms.

Actionable is not the same as complete

For a click, Playwright's documented checks include resolving a single element and checking visibility, stability, event reception and enabled state. Those checks help establish whether the action can be performed. Playwright actionability.

They do not define the business meaning of a finished report. Our recommendation is to record the requested filter separately from the observed result state.

For an illustrative inventory page, that record might name the selected warehouse, reporting date and sort order. The workflow then needs evidence that the rendered result corresponds to that request. A table left visible during refresh is not sufficient evidence merely because it can still be found.

Avoid using a forced click to solve missing result data. Bypassing an actionability check changes how the action is attempted; it does not establish which dataset is displayed afterward.

Enumeration takes a snapshot of what exists

The Locator API warns that locator.all() returns what is present without waiting for matches. For dynamically loaded lists, the documentation advises waiting for the full list to load before enumerating it. Playwright Locator API.

That behavior creates a useful review question: where, exactly, does the agent establish readiness before iteration? If the answer is only “locators auto-wait,” ask it to identify the specific operation and condition.

Our proposed sequence is to establish the intended result state first, then enumerate the bounded set needed for the task. Keep the extraction time and state evidence beside the output so a later reviewer can distinguish an empty result from a premature read.

Do not assume that a stable number of visible rows proves the complete dataset has loaded. A virtualized table, a capped result view or a paginated interface may expose only part of the data. Define the requested scope separately.

Build an application-level completion rule

A useful rule combines request identity with a terminal outcome. Choose signals the application actually exposes rather than inventing a selector that happens to pass today.

Our recommended record includes:

Requested state: the filter values and scope.
Observed state: the UI evidence tying the result to that request.
Terminal outcome: loaded data, a confirmed empty result or a visible failure.
Collection boundary: current page, selected range or a documented complete set.
Stop condition: elapsed budget or an unresolved state mismatch.

If you own the application, a result region can expose a meaningful status or request identifier. If you do not, use the available authorized evidence and report its limitations. Do not modify the target application or bypass access controls to manufacture a completion signal.

A disappeared spinner alone may be inadequate if the application also hides it after failure. Pair the signal with the expected success or empty-state evidence.

Wait for a condition, not a copied value

Playwright provides auto-retrying assertions that repeatedly check a locator condition until it passes or times out. Its documentation distinguishes these from ordinary non-retrying value assertions and offers polling for more complex conditions. Playwright assertions.

Our practical recommendation is to use an assertion that continues observing the relevant state, rather than extracting a value once and repeatedly inspecting the unchanged copy. The expected condition must still come from the task's contract.

A known row count can be useful for a controlled fixture. In production, do not invent that count from yesterday's report or from the first partial response. When the total is unknown, choose a different completion signal or state explicitly that the extraction is partial.

Bound the wait. A timeout should produce a diagnostic containing the requested state, last observed state and available evidence, not an apparently successful empty export.

A small readiness rehearsal

Before adopting a browser skill, propose a non-sensitive test page or authorized fixture with four outcomes: delayed new rows, a valid zero-result filter, a request failure and old rows that remain visible during refresh.

Write the expected result for each before running the workflow. The agent should return the new rows only after matching the requested state, accept genuine emptiness with evidence, and distinguish failure from an empty dataset.

Add a change of filter while an earlier request is still pending if the application supports that interaction. The acceptance question is whether the agent ties its extraction to the intended request, not whether the page eventually contains some rows.

These are proposed checks; we did not execute them for a listed skill. Keep any actual observations separate from the design expectations.

Limitations and the output

Some applications expose no reliable completion signal. A bounded sample, direct authorized export or documented API may be more appropriate than claiming complete UI extraction. Even a well-defined readiness rule cannot prove that the upstream report itself is accurate.

Hand off the extracted records with request identity, scope, completion evidence and unresolved gaps. A successful click belongs in the action log, not in the completeness field.

Our browser-versus-crawler guide covers the earlier tool-selection decision. Browse the skill directory for candidates, then evaluate what each workflow considers ready. The key distinction is simple: the interface may be usable before the requested answer is available.