Browser runs
A browser run is a task an agent does in a web browser, on a site that has no API or connector, while you watch it beside the conversation.
Some work only exists behind a sign-in: a vendor's portal, a government site, an old admin page. A browser run handles it like a person would. It signs in, gets past the cookie banner, reads the table, fills in the form, and brings back what it found. A browser run is a run, next to agent runs and engineering runs, so it keeps a record you can check later.
Ask for one
- In words. "Use the browser to find what we owe Fernhill Supply on their portal." It starts at once, because you asked.
- With
@browser. Type@browin the composer and pick Browser. The run starts with no guessing about what you meant. - When an agent suggests it. If the browser was the agent's idea, the run waits with a Start button until you press it.
- The practice task.
/dashboard/browserlists your runs and has Run the practice task: Fernhill Supply's supplier portal, with a sign-in, an invoice table and a payment form. It is served inside the browser and reaches nothing real.
What you see
The run opens in the pane beside the chat as it starts, with a chip and a live status under the answer. The pane shows:
- the browser as it works, a few frames a second, with the cursor moving to what it clicks;
- each step, with the reason for it;
- anything it is waiting on you for, with Approve and Decline;
- what it found, each output by name. A list comes back as a table, in the order the page showed it.
When the run is done, the same table sits under the answer that asked for it. A run that finishes after the agent has answered says its result in the conversation, and in the Slack or text thread the conversation lives in.
What it may and may not do
| Rule | How it is kept |
|---|---|
| Steps that change something wait for you | A click on a button that submits, sends, pays, saves, updates or deletes, or Enter in such a form, stops the run until you approve. Since 6.0 so does a button that creates, invites, enrolls, adds a user or member, archives, launches, activates or deactivates. The browser engine enforces it, so a page cannot talk the model past it. |
| Passwords stay out of the model | An input marked secret reaches the model as {{password}}. The browser types the real value, and it is never stored in plain text. |
| Public addresses only | Every request the page makes is checked. The server itself, private networks and the cloud metadata address are refused. |
| Each routine run has its own browser | A routine starts one browser run per row. Rows share no cookies or storage, and each browser closes when its run ends. |
| It runs apart from the app | On a deployed installation the browser runs in its own container, with none of the app's settings, keys or database login. |
| It survives a restart | After each step the run saves a sealed checkpoint. After a deploy or a crash, the next process picks it up where it was. A run waiting on you waits again, and an approval you gave meanwhile is used once. |
Limits
- One live run per person at a time. The browser stays open between your runs for 20 minutes, so a follow-up carries on signed in.
- A run takes up to 40 steps and 8 minutes of work, and waits up to 30 minutes for you.
- After three restarts in a row a run stops and says why.
- Routine runs have their own limits: up to 10 at once per workspace (
VOCION_ROUTINE_CONCURRENCY) and 60 steps each. The AWS compose file gives the browser container 4 GB and 2 CPUs to hold them.
Turn it on
| Variable | Default | Purpose |
|---|---|---|
VOCION_BROWSER_RUNS | off | on: every agent in a person's turn can start a browser run, and the composer offers @browser |
VOCION_BROWSER_ENDPOINT | — | The browser container's address. The AWS compose file sets it to the browser service |
VOCION_BROWSER_ALLOW_HOSTS | — | Private hosts a run may open, for a test or a demo (host or host:port, comma-separated) |
Without VOCION_BROWSER_RUNS, an agent gets browser runs with harness.grantTools: [browser_tasks] in its YAML. The agent's tools are browser_task, browser_task_check and browser_task_stop.
Next
- Routines: teach a task once and run it as a browser run for every row of a list.
- Runs and evidence: what every run records.
- Trust and learning: how approvals work across Vocion.
- Security: how actions and credentials are kept.