Put a browser agent to work, one checkpoint at a time

1. Name the result before naming the clicks

A browser agent is useful when the work lives across pages: compare event venues, collect invoices, update a draft listing, or reconcile a small set of records. Give it the destination, the allowed actions, and proof of completion. A request such as ‘visit these six venues and compare wheelchair access, capacity, and cancellation terms’ provides a result you can inspect. ‘Browse around and find something good’ leaves the agent to invent your decision criteria.

Separate discovering information from committing a choice. Reading a venue page and drafting an inquiry are different tasks from submitting that inquiry. Decide the boundary in advance. For a first run, choose a task with a small, known set of pages and a result that fits in one table. Measure how much correction it needs before expanding the scope.

2. Prepare a session you can recognize

Open the intended account and workspace before starting. Tell the agent which tab contains the task and which organization it should be using. Check the visible account name, project, and relevant date range. Two tabs can look identical while pointing at different workspaces. The agent should confirm the target from the page before editing a record.

Use the product's supported sign-in process. Do not paste passwords or exported session cookies into a task brief. Playwright's authentication documentation explains that stored browser state can contain cookies and headers capable of impersonating an account. That is a concrete reason to treat authentication files as credentials. If a login, verification challenge, or unsupported access screen interrupts the task, complete that step yourself and resume from the observed page.

1. Identify the workspace

   Record the visible account and workspace name. Confirm that the supplied links open there.

2. Establish the starting state

   Ask the agent to report the current page, active filters, and any open modal before it begins.

3. Keep a small task inventory

   List each record or URL once so completion can be tracked without revisiting finished items.

3. Use an observe, act, verify loop

Each meaningful action should start from a fresh observation and end with a check of the new state. Opening a filter, selecting a month, and seeing the filtered records are separate events. A click that returned without an error does not establish that the intended filter took effect. Ask for the selected value, record count, or resulting heading when that state matters to the task.

Describe controls by their visible purpose: the ‘Export’ button inside the invoices panel, or the field labelled ‘Start date.’ Playwright recommends user-facing attributes such as roles and labels because page structure can change. Its actionability checks also distinguish visible, stable, enabled controls from controls that cannot yet receive input. A browser agent may use different technology, but you can still require it to inspect the current page and resolve an ambiguous target before acting.

4. Put checkpoints before commitments

Checkpoints belong where the next action changes the consequences of the task. Collecting prices can continue within the brief. Choosing between a refundable and nonrefundable option needs your stated preference. Sending a message needs the intended recipient and content. A useful checkpoint presents the actual proposed action, the evidence behind it, and any unresolved choice. It should not ask you to approve a vague plan that has not been prepared.

For a form, have the agent fill a draft where the website permits it, then summarize the fields before submission. For a batch edit, inspect one representative change and any exceptions before applying the rest. Avoid inserting a review after every harmless navigation. That creates noise and makes consequential requests harder to notice. Use the simulator to practice distinguishing a navigation step from a commitment.

5. Diagnose a stall before retrying

When an action times out, determine what happened before repeating it. The page might still be loading, an overlay might cover the control, the session might have expired, or the server might have accepted the request before the connection failed. These causes require different responses. Repeated clicking can create duplicate records without repairing any of them.

Ask the agent to inspect the page and the relevant destination record. If the new inquiry appears in the site's sent list, preserve that result and continue from there. If no result exists and the form still contains the draft, retry once after resolving the visible cause. If the outcome remains uncertain, pause the write and report exactly what is known. A partial report with four completed comparisons and two inaccessible pages is more useful than silently omitting the inaccessible pages.

6. Inspect the final artifact

Finish by checking the deliverable against the inventory. A six-venue task should contain six rows, including rows whose facts could not be established. Open a sample of source links and confirm that the evidence supports the exact claim. Check whether capacities refer to seated or standing guests and whether a cancellation policy belongs to events or hotel rooms. These small category mistakes can reverse the recommendation.

For downloads, open the file and inspect its contents. For submitted forms, verify the confirmation or destination record. Record what was completed, what was only drafted, and what remains blocked. Save the brief and a short recovery note if you expect to repeat the task. Next time, reuse the criteria and checkpoints, then observe the current website again instead of assuming last month's page arrangement still applies.