Run one browser task across every row in your spreadsheet

I want an app for running one browser automation task across a whole list of records at once, instead of kicking them off one at a time. It runs on Browser Use Cloud, reads its input list from Google Sheets, and writes results back to the same sheet. The audience is internal tool builders and ops people who have hundreds of accounts, portals or records that all need the same browser task run against them.

The first screen is batch setup. The user picks a Google Sheet and a range, and the app loads it with Get Values, treating the first row as the header so every column name becomes an available placeholder. Below that the user writes a single task template with column placeholders in double braces, for example: log into {{portal}} and download last month's statement for {{account}}. Show the detected column names next to the editor so the user knows what they can reference, and flag any placeholder in the template that does not match a real column.

Before anything runs, render the first three rows through the template and show them as a preview, so the user sees the exact task text those records will receive. Nothing dispatches until the user has reviewed the preview and pressed Run.

Above the Run button, show a pre-flight bar with the account credit balance from Get Account Billing next to an estimated batch cost, calculated as the row count multiplied by the per task maximum cost. The user sets that per task maximum and the app passes it as maxCostUsd on every dispatched task, so a stuck agent cannot quietly burn the account. Money fields such as totalCostUsd and maxCostUsd come back as decimal strings in USD, so parse them before doing arithmetic and format them consistently. If the estimated batch cost exceeds the remaining balance, warn the user before letting them start.

Throttling is the most important part of this app. Browser Use caps concurrent active sessions by plan and returns a 429 whose detail reads Too many concurrent active sessions once you go over. Give the user a configurable concurrency limit, default it to something conservative like 3, and run the batch through a queue that never has more than that many tasks in flight. As each task finishes, pull the next queued row and dispatch it. If a dispatch still comes back 429, do not fail the row: put it back on the queue and retry with exponential backoff. The per account request rate limit is visible as rateLimit in Get Account Billing, so read it at launch and keep polling within it.

Once running, the main view is a live grid with one row per record showing the source record, its rendered task, a status, the running cost and the output. Agent tasks are asynchronous: dispatch each row with Run Agent Task, then poll Get Session for that row until its status leaves running, and read output and isTaskSuccessful once it settles. Map the session lifecycle of created, idle, running, stopped, timed_out and error onto clear status labels, and give queued rows their own state so the user can see what has not started yet. Each running row gets a live view link from Get Browser Session so the user can watch the browser work, and a Stop button backed by Stop Session for anything that has clearly gone off the rails.

Partial failure is normal in browser automation, so failed rows stay in the grid with the agent's error text visible rather than disappearing. The user can select failed rows and retry only those, either one at a time or with a Retry all failed button, and retries go back through the same concurrency queue. Never make the user re-run a whole batch to recover a handful of rows, since that wastes both time and credits.

A Write results back button pushes each row's output into the sheet. Let the user choose between writing into a column beside the source rows with Update Values, or appending the results as new rows with Append Values. When updating in place, match each result to its original row so no output ever lands on the wrong record.

When a batch finishes, optionally post a summary to Slack using the slackbot Send a Message action, covering how many rows succeeded, how many failed and the total cost. Persist each batch so the user can reopen the app and find past runs with their grids intact, and reconcile against List Sessions if the app reconnects while a batch is still in flight.