DEV Community: BrowserAct

Separate browser health from export health in your automation

BrowserAct — Sat, 07 Nov 2026 05:32:00 +0000

Your worker connects to a browser, opens the supplier portal, and exits without an exception. The monitoring panel turns green. The finance team still has no usable invoice.

The missing piece is a second health signal: did the business task produce the agreed result?

When evaluating hosted browser infrastructure and agent workflow tooling, I would keep those signals separate. This article proposes a small record and incident-routing exercise. It is not a test result for BrowserAct, Browserless, or any invoice portal. We publish it from the BrowserAct team.

Give each signal a narrow meaning

For this design, browser health answers a technical question: could this worker establish and use the intended browser connection during a particular observation window?

Export health answers a different question: did the requested account, period, and document set produce an accepted artifact?

Neither signal should stand in for the other. A connection probe cannot prove an invoice is correct. A valid file saved earlier cannot prove the browser is currently reachable.

Keep timestamps with both observations. An old green result is especially misleading after a worker restarts or a session expires. Also record which account reference and execution environment were involved, without copying credentials into the incident ticket.

Start with a record that permits uncertainty

Here is a fictional application-side record. These fields are a proposed convention, not either vendor's API schema:

{
  "job_id": "demo-export-042",
  "account_ref": "supplier-account-demo",
  "requested_period": "2026-10",
  "runtime": {
    "status": "reachable",
    "observed_at": "2026-11-07T05:00:00Z"
  },
  "workflow": {
    "status": "awaiting_artifact",
    "last_confirmed_step": "export_requested",
    "request_ref": "demo-request-91",
    "observed_at": "2026-11-07T05:01:00Z"
  },
  "artifact": {
    "status": "not_verified",
    "manifest_ref": null
  }
}

This job is pending, even though its runtime observation is green. Do not convert it to success because the worker returned a zero exit code.

The request reference is useful only if you actually observed one. If the portal supplies none, keep it absent and describe the evidence you do have. Never manufacture an ID to make the record look complete.

Route the next investigation by evidence

A small decision table makes ownership clearer:

Latest evidence	Next investigation
Browser connection failed before page access	Runtime or connection owner checks the environment
Browser reachable, portal asks for login	Authorized account owner handles authentication
Export request acknowledged, file still pending	Workflow owner checks the existing request status
File exists, account or period does not match	Acceptance owner rejects and investigates the artifact
File accepted, delivery destination unavailable	Delivery owner resumes delivery from the saved artifact
Submission outcome uncertain	Inspect current portal state before considering another submission

These are investigation routes, not automatic permission to retry. In particular, a connection loss after submission does not establish that the server rejected the action. The last confirmed step matters more than the final exception text.

If the evidence is too weak to choose a route, label the state unknown and name the person or check that can resolve it. Avoid turning missing evidence into a guessed technical diagnosis.

Keep the business acceptance rule explicit

For invoice collection, a file-extension check is insufficient. A proposed acceptance rule could include the intended supplier account, billing period, readable content, expected document identifiers, and a manifest of unresolved items.

The expected set needs a source. If you only know that three files were downloaded, you cannot infer that the month contains exactly three invoices. Store the observed count and mark completeness unknown until you can compare it with an authoritative list.

Assign acceptance a version. When the rule changes, retain the earlier result and identify which version produced it. That prevents a dashboard from quietly rewriting historical success after the definition changes.

Rehearse ownership before choosing a provider

Use a test account or synthetic exercise to walk through four situations: a failed connection, an expired login, a delayed artifact, and a failed delivery destination.

For each, ask who detects the condition, who can inspect the evidence, who is allowed to act, and how the task resumes. Write down the actual answer, including responsibilities that remain with your own team.

Then evaluate the candidate implementation against those same situations. A provider may help with several layers; your contract still needs to identify the integration boundary. Do not infer that a service owns an entire recovery process simply because it exposes one relevant feature.

This exercise can be completed as a tabletop review before live testing. Label it accordingly. A convincing walkthrough is not proof that the production workflow survives an outage.

Report three outcomes instead of one green light

At minimum, show runtime observations, accepted business jobs, and unresolved jobs separately. Add the age of the oldest unresolved task so a quiet queue does not hide stalled work.

For an individual job, link to its accepted artifact or explain the remaining verification step. For recurring reports, keep failures and unknowns in the denominator. That gives an operator something concrete to investigate instead of a reassuring connection metric.

Our BrowserAct vs Browserless guide explores the infrastructure and workflow distinction. The record above is one way to make that distinction reviewable in your own evaluation.

Who owns the gap between a healthy browser and an accepted export in your current system?

Price browser automation per verified task, not per click

BrowserAct — Sat, 07 Nov 2026 04:24:30 +0000

A browser job can finish in thirty seconds and still leave someone with ten minutes of reconciliation. If your evaluation counts only browser runtime, the slower implementation can look cheaper while doing more useful work.

When comparing a framework such as Playwright with an agent workflow product such as BrowserAct, I would start with a small outcome ledger. The purpose is to expose who pays for retries, review, and maintenance. This is a proposed measurement method, not a benchmark of either product.

Disclosure: this article is published by BrowserAct. The numbers below are fictional arithmetic examples, not product prices or customer results.

Define one unit of useful work

Take a monthly invoice collection job. A useful unit could be one supplier account and one billing month, with an agreed list of expected documents.

A completed browser session is not automatically a completed unit. Your acceptance rule might require readable files, matching account and date range, and a manifest that identifies missing documents. If the expected set is unknown, record completeness as unknown instead of silently counting it as complete.

Use the same acceptance rule for both implementations. Otherwise you are comparing a file collector with a page navigator and giving them the same success label.

Keep attempts inside the original job

Suppose a request needs three attempts before the files are verified. That is one successful business job with three attempts. It is not three jobs, and it is not three successful completions.

Assign a job ID before starting. Record attempt IDs underneath it. Keep failed and uncertain attempts in the cost numerator, even when a later attempt succeeds.

Here is a fictional application-side record. It is a design sketch, not a BrowserAct or Playwright API schema:

{
  "job_id": "demo-supplier-2026-10",
  "acceptance_version": "invoice-set-v1",
  "attempt_count": 3,
  "outcome": "verified",
  "runtime_cost_usd": 0.18,
  "model_cost_usd": 0.12,
  "operator_minutes": 8,
  "review_minutes": 2,
  "evidence_ref": "internal://demo/manifest-001"
}

Use references to protected evidence rather than putting invoice contents or credentials into the evaluation table. Track operator time and review time separately so you can see whether a change removes work or merely moves it to someone else.

Show recurring and setup costs separately

For a fixed evaluation window, recurring cost per verified job can be calculated as:

(runtime + model + service allocation + human time + maintenance)
----------------------------------------------------------------
                   unique verified jobs

Service allocation means the portion of a subscription or shared infrastructure assigned to this workload. Write down the allocation rule. Do not charge the entire shared service to one candidate and exclude equivalent infrastructure from the other.

Report initial implementation time separately. If you amortize it, state the assumed volume and lifetime, then show a second result without amortization. A short pilot cannot establish how many future jobs will actually run.

Elapsed waiting and active human work also differ. A twenty-minute export may require no operator attention. A two-minute export that interrupts someone five times has a different operating cost. Record both elapsed duration and active minutes.

Work through a fictional month

Imagine 100 requested jobs, of which 90 meet the acceptance rule. Runtime and model costs total $45 across all attempts. Allocated services cost $25. Operators and reviewers spend four hours, valued at a hypothetical $30 per hour. Maintenance takes another two hours at that same assumed rate.

Recurring cost is $250: $45 + $25 + $120 + $60. Dividing by 90 verified jobs gives about $2.78 per verified job.

If you counted only runtime and model usage, the result would be $0.50. Neither number is a product quote. The gap shows why the ledger needs human work and maintenance.

The ten unresolved jobs remain visible. Report the completion rate alongside cost, since an implementation could appear cheap by abandoning difficult work. If there are zero verified jobs, report cost per verified job as undefined, not zero.

Make the comparison fair enough to act on

Use matched tasks, accounts, periods, and acceptance rules. Separate normal jobs from expired-login cases and changed-page cases. Keep retry budgets and operator access comparable. Record why a job was excluded before calculating results.

Do not assume a framework has no authentication or debugging support. Playwright documents both authenticated-state reuse and a Trace Viewer. Your cost question is how your implementation uses those capabilities and who maintains the surrounding workflow.

Apply the same scrutiny to a managed product: measure actual operator minutes and maintenance rather than assuming a subscription eliminates them. Include time spent updating the reusable instructions when a website changes.

Use the ledger to decide what to fix next

High review time points toward a clearer acceptance rule or better evidence. High recovery time points toward login handling and escalation. High maintenance time points toward workflow ownership and change management. Expensive model usage deserves attention, but it is only one line.

Our BrowserAct vs Playwright guide covers the broader responsibility split. The practical next step is a matched pilot with a ledger you can audit, followed by a second measurement after one real maintenance event.

Which cost do you currently record least reliably: review, recovery, or maintenance?

Test a browser workflow handover with a second operator

BrowserAct — Sat, 07 Nov 2026 03:17:25 +0000

A browser workflow succeeds while its author is watching. Another operator receives the prompt, runs it with a different reporting account, and cannot tell whether the returned file is complete.

The missing component may be the handover rather than browser control.

When evaluating BrowserAct, Browser Use, or an internal browser stack, include the artifact the next operator receives. Can that person identify the required inputs, account boundary, expected output, and recovery path without asking the author to reconstruct the original run?

The following is a proposed evaluation procedure. It is not a benchmark result or a claim that one product automatically passes it.

Hand over a task contract

Start with the requested business outcome. "Download the report" leaves too much unstated. Which organization, date range, document type, and destination should the run use? What evidence would show that the output belongs to that request?

Describe required inputs separately from incidental facts in the author's environment. A browser ID configured on one machine is an environment reference, not a universal input that every operator can resolve.

Likewise, a remembered account nickname is insufficient if the target application can switch organizations after login. The workflow should tell the operator which indication to verify on the current page.

Declare who executes the procedure

A reusable procedure for an agent and a program that runs without agent judgment are different deliverables.

An agent procedure can ask the agent to inspect the current page, identify the relevant control, and choose the current element index. It should describe the target semantically and explain what to verify afterward.

An unattended program needs an implementation that resolves its targets and handles the relevant failures without that live judgment. Saving a sequence of temporary element numbers does not turn an agent procedure into an unattended program.

This distinction matters during handover because it defines the environment the recipient must provide. Do not let the filename or the word skill imply a stronger execution guarantee than the artifact actually supplies.

Include an acceptance checklist

Give the recipient a way to decide whether the result meets the task contract. For an illustrative report workflow:

Account scope: matches the requested organization
Date range: matches the requested period
Output type: requested document, not a listing screenshot
Coverage: all requested records accounted for
Destination: verified file saved in the intended location
Unresolved items: individually recorded

This is a design checklist, not an actual test result or product output schema. Adapt it to the requested outcome. A task that returns structured rows needs different checks from one that delivers original PDF files.

Keep command success separate from business completion. A click can be acknowledged while the export job is still processing. A file can exist while containing an unexpected date range.

Give recovery a boundary

Describe the next permitted action for the failures the procedure expects. An expired account session, a missing document, and an uncertain export submission should not receive identical retries.

For an uncertain submission, the recipient should inspect the current job or result before repeating the action. For a missing human dependency, the procedure should state how to record the dependency and stop.

A useful recovery instruction identifies the observation that permits progress. "Try again later" is less actionable than "resume after authorized access to the reporting page has been restored."

Also state when the workflow should stop. A reusable procedure that contains only happy-path steps invites the next operator to improvise through the most consequential part of the job.

Run the handover without author coaching

Use an authorized account and a bounded task. Give the second operator the artifact and its documented prerequisites, then record the clarification questions that arise.

Do not silently fix the environment halfway through and count the task as independent completion. Record whether help was needed, what was missing, and whether the returned output passed the checklist.

The result can be useful even when the workflow fails: it reveals which assumptions remained in the author's head. Revise those assumptions into explicit inputs, environment requirements, or recovery decisions before repeating the evaluation.

Save evidence that helps the next run

The handover should identify where verified outputs and failure evidence can be found, while keeping credentials and private document contents out of general instructions.

A screenshot may explain why an interaction stopped. A job record may prevent a duplicate export. A verified artifact may mean the business outcome is already complete even if the browser response was interrupted.

The next operator needs to distinguish those cases without opening every diagnostic file or guessing what the author intended.

Compare the complete handover

Apply the same task, account scope, acceptance checks, and permitted recovery budget to each implementation. Record author intervention alongside verified completion. Avoid treating a polished demonstration as evidence that the procedure is transferable.

Our BrowserAct and Browser Use comparison discusses workflow reuse as an evaluation angle. The handover test makes that angle observable: another operator either has enough information to execute and verify the task, or the missing assumptions become visible.

Saved authentication is not a portable workstation

BrowserAct — Sat, 07 Nov 2026 01:40:46 +0000

A reporting workflow works on an operator's laptop. The team prepares an automation environment with saved login state, opens the same page, and discovers that the workflow also depends on a local browser extension.

The login may be valid. The environment is still incomplete.

This is an illustrative migration problem, not a report of testing a particular portal. It is useful because it separates two decisions that are often bundled together: reusing authenticated state and reproducing the machine context in which the work previously succeeded.

BrowserAct offers an imported Chrome environment and a direct-control path to the local browser. Choosing between them should start with the dependencies the task actually needs, rather than a general preference for one browser mode.

Inventory the working environment

Before moving the workflow, ask the operator to identify what makes the current environment special. Useful categories include:

The account and organization selected in the target application.
Any extension that adds controls, transforms content, or participates in authentication.
Client certificates or device-specific access requirements.
Enterprise sign-in that depends on the current desktop environment.
Files, settings, or human steps used during the workflow.

Treat these as questions to investigate, not claims that every application has these dependencies. A simple dashboard may only need an ordinary login. Another system may depend on something the operator no longer notices because it has worked for years.

Record the minimum necessary facts without copying secrets into the inventory. The goal is to identify the dependency, its owner, and how to verify it.

Separate copied state from live context

An imported browser environment can be useful when the needed asset is existing authenticated state and the task can run independently of the user's currently open browser.

Direct control is a different arrangement: the task operates in the live local browser environment. That can matter when a required extension or machine-bound context is already there.

Neither description establishes that every dependency will work automatically. Do not infer extension parity, certificate availability, or a complete enterprise sign-in path from the fact that an account cookie was available.

Also distinguish an environment dependency from a navigation dependency. A local extension may be required; whichever tab happened to be open yesterday usually should not become the workflow's hidden starting condition.

Turn each dependency into an observation

Replace a vague requirement such as "use the same browser" with observations you can check before running the business operation.

For example, an application-side record might contain:

Requirement: approved reporting extension
Owner: workstation administrator
Observation: expected reporting control visible
Business action: not started
Failure route: environment review

This is a fictional planning record, not BrowserAct configuration or a successful test result. Its purpose is to make a failure actionable. If the expected control is absent, the next step is to investigate the environment rather than retry an export button that is not present.

For account scope, record the expected organization and verify the application's current indication. A configured browser name can tell the agent why that environment exists, but it does not replace checking the page it actually opened.

Keep navigation ownership explicit

Even when the live local environment is necessary, give the automation its own execution session and the task an explicit starting page. Avoid borrowing another operator's active execution context just because it uses the right account.

Read current page state before choosing an interactive target. A saved numeric element index is not a durable identifier across different page states.

These practices address a separate failure mode from missing extensions: navigation collisions. A valid environment can still produce confusing results if the agent operates on a page another task is changing.

Test the chosen path with a small operation

Start with a read-only check that exercises the dependency. If an extension provides a report control, verify the control and the intended account context before attempting the export. If enterprise sign-in is the dependency, verify access through the environment that the eventual workflow will use.

Only then add one scoped business operation and validate its output. A visible dashboard does not prove that a download contains the right dates or belongs to the intended organization.

Save installation, access, operation, and artifact verification as separate outcomes. That makes it possible to recover a failed migration without repeating successful steps or describing incomplete work as production-ready.

Document what remains tied to the machine

If the workflow must stay on a particular workstation, say so in its operating instructions. Identify the dependency owner and the observation that should be checked after a machine, account, or extension change.

If it can move to a dedicated environment, record which dependencies were verified there. Avoid treating a copied profile as evidence that every part of the previous workstation moved with it.

Our browser-mode selection guide gives the broader context. The practical migration decision comes from the dependency inventory and the result of the smallest useful check.

Make your browser CLI smoke test prove one useful thing

BrowserAct — Sat, 07 Nov 2026 00:33:21 +0000

A successful package installation proves that a package installed. It does not establish which account a browser will use, whether a reporting page is accessible, or whether the next scheduled job will retrieve the intended data.

For a browser automation rollout, I would make the first acceptance check deliberately small: read the intended page in the intended account, record what was observed, and close the execution session. That is enough to identify several setup problems before adding exports or account changes.

This is a proposed readiness procedure using documented BrowserAct commands. It is not a report of running those checks against a customer's portal.

Write the expected observation first

Before opening the browser, define the page and account context you expect to see. A useful statement might be: "The reporting overview is visible for the operations account, and its date filter can be read."

Avoid an expectation such as "the page returns 200." A login page can load successfully while the report remains inaccessible. The observation should describe the business context, not just the transport or process exit code.

Keep the first check read-only. Downloading files, submitting forms, and changing settings introduce additional outcomes that make a setup failure harder to isolate.

Verify the configured environment

Use the browser registry to identify an existing configured environment:

browser-act browser list

Read the browser's description and type. Confirm that its purpose matches the task and that the account owner has authorized its use. A remembered browser name is not evidence that its current login or machine dependencies still work.

If the workflow depends on a local extension, certificate, or enterprise sign-in context, include that dependency in the readiness record. Copying login state and controlling the current local browser are different execution arrangements. Test the one the eventual workflow will actually use.

Create an execution context you own

For interactive work, open a new named session against the confirmed browser:

browser-act --session report-readiness browser open <browser_id> <authorized_page_url>
browser-act --session report-readiness state

Replace both placeholders with the configured browser and an authorized destination. These commands are a workflow example, not a runnable script with complete inputs.

The session name is a current execution handle. Do not attach to a similarly named session created by another operator or assume an old name still refers to a live session you own.

Read the resulting page state. Confirm the current URL, relevant account indication, and the actual reporting content. If a required fact is not exposed in that state, inspect the visible page further rather than guessing from the browser's configured description.

Record what passed and what did not

Keep installation, browser access, and business readiness as separate observations. A small record can be enough:

CLI available: yes
Configured browser identified: yes
Intended reporting page visible: no
Observed boundary: sign-in required
Next action: restore authorized account access
Export readiness: not tested

Those are fictional results illustrating a record format. They are not command output or a BrowserAct product status schema.

This record is more useful than a single boolean named setup_complete. It tells the next person that reinstalling the CLI is unlikely to resolve the observed sign-in boundary. It also prevents an untested export from being described as ready.

Stop at the boundary you found

If the page requires a human verification or an account dependency is missing, save the observation and follow the authorized recovery procedure. Do not keep opening new environments or changing account identities to turn a failed readiness check into a green result.

A readiness check succeeds as an investigation when it locates the dependency clearly, even when the business workflow remains blocked. Scheduling the full job can wait until that dependency is resolved.

When the read-only check is finished, close the session you created:

browser-act session close report-readiness

Closing an execution session is not the same as deleting its configured browser. The readiness record should survive independently so later attempts can use the evidence.

Expand one outcome at a time

After account and page access are verified, add the smallest next meaningful operation. For a report collector, that might be one scoped export followed by file verification. Only after that works should recurring scheduling, retries, and broader account coverage enter the acceptance checklist.

The purpose is to make each failure point identifiable. Installation, access, correct output, and repeatable execution are separate milestones. Naming them separately makes the rollout easier to diagnose and the completion claim easier to trust.

Our BrowserAct installation guide provides the starting setup context. Use the readiness procedure to check the environment you will actually operate after installation.

Browser cleanup and data retention are two different jobs

BrowserAct — Fri, 06 Nov 2026 22:54:46 +0000

An automation downloads a report, saves a screenshot for debugging, and closes a temporary browser session. The next run starts with an empty profile. The report and screenshot remain in the application's output directory.

That is an ordinary architecture, but it exposes an easy documentation mistake: describing a browser's temporary state as if it defined the retention policy for every artifact produced by the workflow.

This article presents an application design exercise. It does not report a deletion test, a security audit, or a run against a billing portal. BrowserAct's private stealth mode provides a fresh profile rather than reusable login state. The surrounding application must still decide what to do with its own files and records.

Draw the boundary around the browser

Start by listing the state that the browser environment is supposed to retain between runs. Cookies and local application storage can affect whether the next attempt begins signed in, remembers a selected organization, or sees a first-visit experience.

For repeated authenticated work, continuity may be useful. For a clean-state investigation, retained state can be exactly the variable you want to remove.

Make that choice for the task. Avoid selecting a temporary profile solely because the word private sounds appropriate. A recurring report collector that repeatedly loses its login may create more manual work without solving the problem you intended to address.

In BrowserAct, private mode is a stealth-browser configuration. It is not a general promise that every browser type, external account, and application output follows the same lifecycle.

Inventory what leaves that boundary

Now list the outputs separately. A small workflow might produce:

The requested report or invoice file.
A screenshot showing why a step failed.
A request trace used to diagnose an unexpected response.
A job record containing account scope, dates, and completion status.
A local retry record identifying an unresolved document.

These objects have different purposes. The file may be the requested business deliverable. The screenshot may only be needed during investigation. A retry record might remain useful after a browser session ends because it prevents duplicate work.

Closing a browser session does not define the lifecycle of those application-managed objects. Neither does starting the next session with a fresh profile.

Give each artifact an owner

For each output category, record who writes it, where it goes, who can access it, and which component is responsible for its eventual removal.

A design note could look like this:

business document: application output store; retained for the requested use
failure screenshot: diagnostic store; reviewed under a separate policy
request trace: restricted investigation evidence; shared only when needed
job status: coordinator database; enough detail to resume or deduplicate
browser profile: lifecycle determined by the chosen browser mode

This is an illustrative inventory, not BrowserAct storage configuration or a recommended universal retention schedule. The right duration depends on the user's requirements and the system receiving the data.

The useful property is explicit ownership. If every component assumes another component will clean something up, an artifact can survive indefinitely even when the browser itself is disposable.

Keep debugging evidence smaller than the source

A failed export does not always require sharing the full account page or request capture with everyone investigating it.

Often a scoped note is enough: expected date range, observed result type, failure step, and the identifier of the restricted evidence. Keep cookies, authorization headers, signed download URLs, and private document contents out of general progress logs.

If richer evidence is necessary, preserve it in the intended destination with the relevant access controls. A temporary browser is not a substitute for choosing that destination deliberately.

Verify the business result before cleanup

Separate two questions at the end of an attempt: did the requested output pass verification, and did the execution environment close as intended?

A cleanly closed session can still have downloaded an incomplete report. A verified file can still be associated with a browser session that the job forgot to close. Record those outcomes independently so the next operator can tell whether to recover the artifact or release resources.

For a failure, save enough information to choose the next action before ending the session. Do not describe every failure as a reason to preserve all browser state forever; decide which evidence the recovery actually needs.

Treat a clean profile as one design choice

A fresh profile can help isolate whether retained browser state influenced a result. It does not establish anonymity to a website, remove the website's records, or verify deletion from an external output store.

Use the browser mode to control continuity at the browser layer. Use the application's own artifact handling to control its outputs. Keeping those responsibilities explicit makes both the workflow and its documentation easier to review.

Our private browser automation guide explains the persistence trade-off. Apply that choice alongside an inventory of the files and evidence your application actually creates.

Give parallel browser jobs an account-level budget

BrowserAct — Fri, 06 Nov 2026 21:47:04 +0000

A team splits a monthly reporting task across four browser sessions. Each session navigates independently. All four use the same account, request exports at once, and reach the same account-level limit.

The navigation is isolated. The workload still needs coordination.

This is a design walkthrough for that problem, not a measurement of a particular portal or a claim about BrowserAct throughput. BrowserAct supports parallel sessions that share a browser's login state while keeping their active navigation separate. That capability answers where a task runs. Your application still needs to decide when a shared account should receive more work.

Identify the resource being shared

Start by separating three identifiers in the job record:

The job identifies the requested outcome, such as one account's September report.
The browser identifies the configured browser environment and login context.
The session identifies the live execution context created for this attempt.

A session name is useful for routing commands. It does not establish that two jobs are independent at the business level. Two different sessions can still request the same document or change the same setting.

Record the business account separately as well. Several configured browsers might access the same portal account, so a browser ID alone may be an incomplete key for scheduling account-wide work.

Classify operations before adding workers

Reading independent report pages is different from updating account settings or starting an expensive export.

For an initial implementation, classify the steps by their effect. Independent reads may be candidates for bounded parallel execution. Account-wide changes deserve explicit sequencing. Export generation may need its own limit even when reading pages works concurrently.

Those are starting assumptions to validate for the actual portal. A site may enforce a total session limit, or a seemingly harmless action may update shared preferences. Separate browser windows do not tell you how the server handles concurrent requests.

You can begin with a small operation map:

report-page read: allow a small number in parallel
export generation: serialize until behavior is understood
account preference update: serialize
file verification after download: run locally and independently

This is an application design example, not a BrowserAct configuration file or a tested policy for any named vendor.

Put admission control outside the browser

Give the coordinator a queue keyed by the actual shared resource, such as portal plus account plus operation class. Only create or assign an execution session after the coordinator admits the job.

This avoids a common waste pattern: opening many sessions and then letting all of them wait on the same account restriction. Waiting jobs can remain ordinary queue records without occupying a live browser execution context.

A minimal job lifecycle might be:

waiting -> admitted -> executing -> verifying -> completed
                         |
                         +-> waiting_for_dependency
                         +-> needs_review

The coordinator owns these states. They are not statuses returned by BrowserAct. Keep its scheduling decision separate from what the browser observed so a failed page load cannot accidentally become a successful business result.

Release capacity deliberately

Capacity should return to the coordinator when the attempt ends, including failures. Session cleanup and business completion are related but different responsibilities.

A job can close its session after saving evidence and still remain incomplete because the export contains the wrong dates. Conversely, a completed file should not need its browser session kept open indefinitely.

When a human action is required, record that dependency explicitly. Avoid occupying every worker slot with attempts waiting on the same unresolved account login. The appropriate resume path depends on the workflow and the existing authenticated environment; do not assume a new session removes the dependency.

Retry the missing outcome

Give each requested output a stable business key. For example, combine the account, document type, date range, and document identifier when that identifier exists.

Before retrying, check for an already verified artifact with that key. A browser timeout after an export click leaves an uncertain outcome, not proof that the export failed. Inspect the existing job or saved result before starting the same export again.

If the portal reports a limit, record the observed message and any stated retry time. Keep that account's dependent jobs waiting while unrelated accounts continue within their own budgets. Do not increase concurrency in response to a rate-limit error.

Measure useful parallelism

Track verified outputs alongside active sessions, waiting time, repeated requests, and required human intervention. More open sessions are only useful if they improve completion without producing duplicate work or increasing account-level failures.

Start with a conservative limit, observe the actual workflow, and change one constraint at a time. There is no universal worker count that follows from the browser's ability to open another session.

Our concurrent browser automation guide covers the session and identity model behind this design. The account-level coordinator described here belongs to the application that schedules the work.

Debug a browser export with a one-action network trace

BrowserAct — Fri, 06 Nov 2026 20:39:15 +0000

A browser job opens a reporting page, changes the month, clicks Export, and receives a file. The job looks successful. The file contains last month's records.

That is a useful debugging scenario because clicking the same button again does not explain which month the application actually requested. The page label, the request parameters, and the downloaded artifact are separate pieces of evidence.

This tutorial proposes a small investigation procedure for that situation. It uses BrowserAct's documented request inspection commands. The export scenario is illustrative; it is not a report of testing a particular billing portal.

Start with one question

Before capturing traffic, write down the uncertainty you want to resolve. For example: "Did changing the month affect the request that generated this export?"

That question sets a much better boundary than "collect all network traffic." It tells you which action to perform, which requests deserve attention, and what would count as an answer.

Also record the expected account, date range, and record type outside the capture. A response cannot prove that a workflow selected the correct organization if you never wrote down the intended organization.

Isolate one interaction

Use your own named session in a browser that you are authorized to operate. Navigate to the relevant page and inspect its current state:

browser-act --session export-debug state

Read the current element list and locate the month selector or filter by its meaning. The numerical indices belong to that particular state snapshot. Do not copy an index from a previous run and assume it still identifies the same control.

Once the page is ready, clear earlier captured traffic:

browser-act --session export-debug network requests --clear

Then perform exactly one meaningful action, such as applying the date filter. Inspect the current page again before deciding which control to use next. Mixing filter changes, pagination, and repeated export clicks into one experiment makes causal interpretation harder.

Find the response that matters

Start with likely data calls:

browser-act --session export-debug network requests --type xhr,fetch

Read the captured request list. Choose a request because its URL, timing, and purpose match the action you just performed. The first successful request might be analytics or application configuration rather than your report.

After finding a candidate, use the request ID returned by the current capture:

browser-act --session export-debug network request <request_id>

Inspect its method, parameters, and response together. A date might be supplied in a JSON body rather than the URL. Pagination might be represented by a cursor rather than a page number. Treat those as observations from this application, not conventions to assume everywhere.

Separate three outcomes

A useful investigation distinguishes these cases:

The request contains the wrong scope. Return to the filter or account-selection step. Retrying the export repeats the same mistake.
The request contains the intended scope, but the response is incomplete or unexpected. Investigate the application's response and any subsequent requests before changing selectors.
The response appears correct, but the saved file differs. Follow the export and download sequence. A table request and an export-generation request may serve different purposes.

HTTP 200 only describes the transport-level response. It does not establish that all pages were included, the requested account was selected, or the file is an invoice rather than a summary report.

Leave a small evidence note

You rarely need to paste an entire capture into a ticket. A compact note can carry the reasoning:

Expected: organization A, September, invoice documents
Action observed: applied September filter once
Request observed: date bounds matched September
Response observed: 25 rows and a continuation cursor
Unresolved: whether export includes later pages
Next experiment: inspect the export-generation request

These are fictional observations, not actual BrowserAct output or a product schema. Their purpose is to show what a useful handoff contains: expectation, observation, uncertainty, and one next action.

Keep session cookies, authorization headers, private records, and signed download URLs out of the shared note. Network inspection can expose more information than a screenshot of the table.

Decide what to automate after the investigation

Finding a structured response does not establish a stable public API contract. It might rely on a cookie, a CSRF token, prior browser actions, or an expiring URL. Keep the existing browser flow until you understand that dependency.

The practical result of this procedure is a narrower next decision: fix selection, investigate pagination, or inspect file generation. That is enough progress for one debugging pass. Automating a guessed endpoint before resolving those questions only moves the uncertainty into code.

For the broader request-inspection workflow, see our BrowserAct network inspection guide.

Keep browser session ownership in your job record

BrowserAct — Fri, 06 Nov 2026 19:27:41 +0000

A browser job needs more than a remembered window name. When several agents or scheduled tasks use the same browser, the application needs to know which task opened each live session, whether that session still exists, and who is allowed to close it.

Our browser automation sessions guide explains the distinction between a task session and a browser identity. This post turns that model into an operating checklist for an Agent-assisted workflow. It is not a claim that a session name remains valid across restarts or that separate sessions create separate accounts.

Keep identity separate from the task window

In BrowserAct, multiple sessions on one browser share browser-level login state while keeping navigation and live task context separate. Use a new task session for independent work under the same approved identity. If the identity must differ, choose the appropriate separately configured browser instead of assuming a new session isolates cookies.

That distinction matters during recovery. A missing session means the runtime handle is unavailable. It does not by itself establish that the browser profile disappeared, that an account logged out, or that another identity should be used.

A saved session name is a reference to something that may be live, not a guarantee that the underlying window still exists.

Record what your job actually opened

Keep a small application-side record with the job reference, approved browser reference, session name, creation time and current lifecycle state. Record creation from the actual command result, rather than discovering a convenient existing session and claiming it as your own.

For an Agent workflow, the conversation's tool-call history is also evidence of ownership. A session appearing in an inventory does not establish that this job created it. Treat the inventory as a view of runtime availability, then combine it with the ownership record before deciding what to operate.

Use task-specific names so two concurrent jobs are less likely to collide. Avoid putting customer secrets or credentials into session names; those names can appear in logs and command output.

Open, inspect, act and verify

The following is a command skeleton with placeholders. Replace the browser ID with an existing authorized browser. The click target must come from the current state output, interpreted by the Agent.

browser-act --session invoice-check-A browser open <existing-browser-id> https://example.com
browser-act --session invoice-check-A state
browser-act --session invoice-check-A click <current-index>
browser-act --session invoice-check-A state

The element index belongs to that state snapshot. After navigation, a click or another page change, inspect the current state before choosing the next target. Do not save an old index as a reusable selector or use shell text matching as a substitute for deciding which control is correct.

A reusable Agent procedure can preserve the target meaning, such as the relevant invoice row or a Download control. It should still let the Agent inspect the page and resolve the current control at execution time.

Recover from evidence, not from the name alone

Before resuming a stored session reference, check the live runtime and your own creation record. If your session still exists, continue in it rather than reopening the same name as though it were new.

If it is unavailable, determine whether opening a new owned session on the same approved browser is appropriate. Then inspect the resulting account and page state. Do not treat the recovery as permission to close unrelated sessions or switch to a different person's account.

If another job owns the matching session, leave it alone. Independent task windows are useful precisely because recovery in one job should not interrupt another job's navigation or unfinished form.

Close only the resources you own

When your work is complete and no user handoff remains, close the session your job opened:

browser-act session close invoice-check-A

Record the close result. If cleanup fails, retain the session reference and error so a later operator can distinguish an orphaned resource from an intentionally active handoff. An unconditional cleanup of every session in an inventory creates a much larger failure than one unfinished job.

This procedure still requires Agent judgment about the current page, ownership and outcome. Packaging it as a Skill makes that judgment reusable; it does not turn the procedure into a standalone unattended script. Keep the lifecycle record, page evidence and business result distinct so the next run can continue from facts instead of assumptions.

Don't overwrite browser observations with enriched contact data

BrowserAct — Fri, 06 Nov 2026 18:20:26 +0000

A contact pipeline often starts with two useful outputs: fields observed in an authorized browser session and an email address returned by a separate provider. Combining them into one email column is convenient until someone asks where the address came from or why it belongs to that person.

Our agent skills versus dedicated email tools comparison explores the choice between buying a workflow and maintaining an integration. This post focuses on one implementation detail: preserving the evidence when browser extraction and enrichment disagree. It is a design example, not a report of a live contact-extraction run.

A blank observation is still data

Suppose the browser reached the intended profile, but the account could not see an email address. That observation does not prove that the person has no email. It also does not authorize the pipeline to invent one.

Record the access outcome and the field outcome separately. An unavailable page, a failed extraction, and an accessible page with no visible address require different follow-up. If all three become an empty string, a later operator cannot tell whether another extraction attempt is useful.

Keep the original observation after a provider lookup. A provider result may add useful evidence, but it should not rewrite what was visible in the browser at the time.

Keep two records before making one decision

Here is an illustrative application-side shape. The address uses the reserved .test domain and is fictional; none of these fields is presented as a vendor's API schema.

{
  "record_ref": "example-contact-001",
  "browser_observation": {
    "page_access": "confirmed",
    "email_visibility": "not_visible",
    "visible_email": null
  },
  "provider_result": {
    "address": "person@example.test",
    "identity_match": "unresolved",
    "verification_label": "deliverable"
  },
  "decision": {
    "status": "review_identity",
    "accepted_email": null
  }
}

The record deliberately has a provider address and no accepted address. A deliverability label describes one property of an address; it does not resolve whether the provider matched the correct person or employer. The identity decision still needs evidence.

The reverse case is also useful: an address may be visible on the page while an external lookup returns nothing. Preserve the observed address and its source. Whether it should enter a downstream system depends on your team's acceptance rule, not on the availability of another provider result.

Separate observation, verification and acceptance

Use different fields for what the browser observed, what the provider returned, what verification reported, and what a reviewer or policy accepted. Store the relevant source reference and observation time with each piece of evidence.

Avoid a rule such as accepted_email = visible_email or provider_email when it discards identity checks or source requirements. A nonempty string is not enough to express why a value was accepted.

Define explicit outcomes for unresolved identity, provider failure, rejected address and accepted address. A failed provider request should remain a technical failure, rather than being converted into evidence that no address exists.

Make retries add evidence

Give the contact a stable internal reference so a later lookup can attach a new result without replacing the earlier observation. Keep request time, provider reference and relevant status. Avoid logging session cookies, access tokens or unnecessary personal fields.

If a profile becomes unavailable, retain the earlier observation with its timestamp rather than pretending it was freshly observed. If the employer changes or two people have similar names, keep the conflict visible until the identity mapping is resolved.

Retries should follow the unresolved step. An extraction failure may justify another page observation. A provider timeout may justify another provider request. An identity conflict requires review; repeatedly running the same lookup does not resolve it automatically.

Choose the workflow after defining the handoff

A dedicated tool can be the clearer route when its standard inputs and reviewed export match the job. A browser skill plus an enrichment integration earns its maintenance cost when source preservation, custom decisions or exception handling matter to the receiving team.

BrowserAct can supply a browser execution step, but that does not make it an email database or prove the quality of a separate provider's result. The integration should make the boundary visible. Before writing a value into a CRM, a reviewer should be able to explain which source supplied it, what checks passed and what remains unresolved.

What a browser automation comparison should measure after the demo

BrowserAct — Fri, 06 Nov 2026 17:11:06 +0000

Two browser jobs can both report success and deliver different results. One may leave original invoice files in the finance archive; another may return a table of links that expire before anyone retrieves them. Comparing their completion times as if they performed the same job produces a misleading result.

Our BrowserAct and Skyvern invoice-workflow comparison uses documentation to shortlist execution routes. It does not establish a same-portal speed, cost or success-rate winner. This post proposes the measurement harness that would be needed before making those claims.

Freeze the task, including its destination

Start with one authorized account, an explicit invoice-date interval and a known expected document set. Record the supplier region and account variant. Decide whether the task needs invoice PDFs, shipment details, credit memos or a subset of those documents.

The task ends at the agreed destination, not at the final browser click. If finance needs durable files in an approved archive, both candidates must be evaluated against that same handoff. A temporary result link is an intermediate artifact unless that is explicitly the requested deliverable.

Store the approved scope separately from each run's observations. If a candidate silently changes an empty date filter or switches to another account, preserve the mismatch rather than accepting the files as equivalent output.

Record stages rather than a single success flag

A comparison record should make intermediate success visible without confusing it with delivery. An illustrative application-side record could contain:

{
  "experiment_ref": "invoice-pilot-A",
  "scope_ref": "approved-scope-v1",
  "candidate_ref": "configured-route-A",
  "stages": {
    "request_accepted": true,
    "portal_access_confirmed": true,
    "retrieval_finished": true,
    "archive_reconciled": false
  },
  "unresolved": [
    {
      "expected_document_ref": "example-invoice-004",
      "reason": "retrieved_file_identity_mismatch"
    }
  ]
}

This is a synthetic record, not an output schema from either product or evidence of a real run. Its purpose is to show how a finished retrieval can coexist with an incomplete archive. Counts and timestamps should come from actual observations, with the evidence needed to audit them.

A file manifest can carry document reference, account reference, document type, saved path, byte count, checksum and verification result. Check business identity independently of byte validity. Two valid PDFs are not interchangeable merely because they both open.

Keep human work inside the observation window

Record when a human had to renew login, confirm an account, handle a second factor or resolve an exception. Capture elapsed job time and operator time separately: waiting for a person is different from the person spending ten minutes diagnosing a mismatch.

Keep the operating model explicit. A local runtime needs a responsible machine and process; a managed route still needs ownership for account access and output handling. These are evaluation questions, not assumptions that every product in a category has identical requirements.

Also distinguish setup from recurring work. A reusable workflow may have a substantial initial build cost. Excluding that cost from a first-month comparison is different from amortizing it across a declared number of future runs. Show the assumption instead of hiding it in a single headline price.

Make the second run part of the experiment

After reconciling the first run, repeat the same scope. Observe duplicate handling, version changes, missing-item recovery and interrupted retrieval. Do not intentionally invalidate a live account or manufacture destructive failure conditions for the sake of a test.

Use ordinary, authorized exceptions when they occur. Record the cause as unknown when evidence is insufficient. A challenge encountered once is not proof of a platform-wide failure rate, and a successful demonstration is not proof of broad supplier coverage.

Retain candidate configuration and observation dates so a later rerun is interpretable. Browser mode, workflow revision and output settings can change the comparison even when the product names remain constant.

Compare cost only against comparable delivery

Track charged usage, setup effort, recurring operator effort and archiving work separately. If one candidate delivers only part of the expected set, report the missing work alongside its cost; do not present a low spend as the price of a complete task.

BrowserAct and Skyvern can each be shortlisted for a particular workflow, but documentation and a demo answer different questions from a controlled pilot. A useful comparison report lets the reader inspect the approved scope, delivered files, human interventions and unresolved items before drawing a conclusion.

Put a scope check in front of your billing browser job

BrowserAct — Fri, 06 Nov 2026 16:03:34 +0000

A billing collection job can download a perfectly valid PDF from the wrong place. File checks will not catch that mistake if the document belongs to another product, organization or reporting period.

OpenAI is a useful example. Its billing help distinguishes ChatGPT billing from API-platform billing. Sharing a brand or a login identity does not turn them into one billing workspace.

This post adapts our OpenAI API invoice workflow guide into an application-side design. It does not demonstrate an authenticated account or a working portal collector. The small guard below compares supplied scope observations; it does not verify a login or retrieve an invoice.

Give the request an identity before opening the browser

A request such as “download last month's OpenAI invoices” leaves several decisions implicit. Specify the product, approved account reference, date basis and period before the task starts. Resolve “last month” once at request creation, using the finance team's agreed timezone.

Keep the approved scope separate from the observation made after login. If the same code fills both from the currently selected workspace, a comparison will always succeed, even when the workspace is wrong.

Use a non-secret account reference in logs. Credentials, session cookies and access tokens belong in the authorized credential mechanism, not in the manifest or exception report.

A small guard with a narrow responsibility

The following local data model is illustrative. Its field names are not OpenAI API parameters or a BrowserAct Bot input schema.

from dataclasses import dataclass
from datetime import date

@dataclass(frozen=True)
class Scope:
    product: str
    account_ref: str
    date_basis: str
    start: date
    end_exclusive: date

def require_same_scope(expected: Scope, observed: Scope) -> None:
    for scope in (expected, observed):
        if not scope.product or not scope.account_ref or not scope.date_basis:
            raise ValueError("incomplete scope")
        if scope.start >= scope.end_exclusive:
            raise ValueError("empty or reversed period")
    if expected != observed:
        raise ValueError("scope mismatch; stop before retrieval")

An approved scope might use your application's label openai_api, an account reference mapped to the authorized organization, invoice_date, and an explicit calendar interval. The observation must be grounded in the current page and selected filters. Mapping a displayed organization name to an approved reference needs its own reliable rule; this function cannot discover that mapping for you.

The comparison intentionally fails on any difference. A mismatch is a reason to inspect the request or selected workspace, not permission to silently rewrite the expected value.

Keep permission and availability separate

A matching scope does not establish that the current identity can view every required document. Check permissions and the visible billing history independently. OpenAI's help identifies API organization owners as the route to API billing details; do not generalize that into a claim that any signed-in user can retrieve the same records.

An empty listing also deserves a specific outcome. It could reflect an incorrect scope, unavailable history, insufficient access or an expected set that needs review. Do not manufacture an invoice from usage totals or substitute another product's receipt to make the job appear complete.

If the portal needs renewed login or human confirmation, pause the affected route and retain the approved scope. A successful confirmation should resume the intended job, rather than creating a new request with a different organization selected.

Validate the handoff after retrieval

Scope checks belong before retrieval; reconciliation belongs after it. Match the files against the expected document list and retain the relevant product, organization reference, document identifier and retrieval time.

A generated export link is an intermediate result. Confirm that the authorized file is saved in the intended archive and that its contents match the expected document. Keep invoice documents, receipts and usage summaries distinguishable when the finance process treats them differently.

On a repeat run, use the same approved scope and explicit version policy. An existing filename is not enough to establish either a duplicate or a newer document. Record unresolved items and their reasons so the next operator can continue without repeating the whole month.

BrowserAct's browser workflows are one possible execution route to evaluate. Whatever tool performs the navigation, the application should preserve the request identity from approval through the final file register. A scope guard is a small control, but it prevents one class of wrong result from being mistaken for a successful download.