Browser Agent
An agent that signs in to a supplier portal with no API, reorders low-stock parts, swaps an out-of-stock item for the suggested substitute, and stops at checkout for approval.
- Agent Lab · sample data for Meridian Facilities Co.
- Design & Engineering
- Agent Lab · 2026
Overview
Plenty of suppliers still only offer a web portal, so someone reorders by hand every week. This agent drives a real headless Chrome through a B2B portal: it signs in, searches the catalog, handles an out-of-stock part by choosing the substitute the portal suggests, fills in the buyer's PO number and shipping, and stops on the review page. Code reads the order off the page and checks it against the low-stock list before asking a person. Only after approval does it place the order.
The Problem
Browser automation scripts break whenever a page changes, and LLM browser agents are hard to trust with a login and a checkout button. The task needs flexibility and hard guarantees at the same time.
- ▸Fixed scripts can't cope with an out-of-stock item or a changed layout.
- ▸A model with a password and a Place order button can do real damage.
- ▸Nobody should approve an order they can't verify against what was asked for.
The Solution
The model decides the next step; code decides what is allowed. Each step is a single validated action on an element that must exist in the current snapshot, executed under a policy the model can't change.
- ✓Compact page snapshots with short element ids, plus a live screenshot of every step.
- ✓One zod-validated action per step: click, type, select, goto, request approval or done, each with a reason.
- ✓An origin allowlist at the network layer, and a commit gate on the Place order button and on the order request itself.
- ✓The model types a placeholder; code fills in the real password, only into a password field.
Architecture
Observe, decide, execute under policy, check, approve: a step loop around a headless Chrome session.
Snapshot
Visible controls tagged with ids, their labels, values, options and table row, plus the page's visible text; secrets redacted.
Decision
Structured output against an action schema, with one repair for invalid answers and a 30-step budget.
Executor & policy
Grounding checks, request interception, secret filling and the commit gate, all in code.
Order checks & approval
Code reads the review page, checks items, quantities, substitutes, PO number, ship-to and delivery, then pauses for a person.
Key Features
Live browser view
Watch every step's screenshot and the agent's reason for each action as it works.
Handles surprises
An out-of-stock capacitor is replaced by the portal's suggested substitute, and the change is reported.
Secrets never shown
The password is filled in by code; snapshots, traces and the model only ever see a placeholder.
Checked before approval
The order on the page is verified against the low-stock list before a person is asked to approve it.
Technology Stack
Design & Engineering
Designed the action model, safety policy and approval flow on the shared Agent Lab runtime, and directed the build.
- ▪Specified the action schema, grounding rules, allowlist and commit gate.
- ▪Designed the mock supplier portal with deliberate look-alike parts and an out-of-stock item.
- ▪Defined the order checks that must pass before a person is asked to approve.
- ▪Reviewed the live browser view so each step reads clearly on screen.
Product UI
Technical Challenges
Grounding actions in the real page
Challenge: Models refer to elements that don't exist or type into the wrong field.
Solution: Actions reference ids from the current snapshot only; type goes only into text fields and select only picks existing options. Mistakes return to the model as context.
A checkout the model can't press
Challenge: A single wrong click on Place order would create a real purchase.
Solution: The commit gate blocks the button and the order request at the network layer until a person approves, whatever the model does.
Staying on the portal
Challenge: Pages link out to manufacturers and other sites.
Solution: Every request passes an allowlist interceptor; anything off the portal is blocked and reported to the model.
Outcomes & Highlights
The agent completes the reorder end to end: four parts, one substitution, the right PO and shipping, verified against the list, and ordered only after approval.
- ✓Full reorder in about 20 to 25 browser steps.
- ✓Out-of-stock item replaced by the portal's substitute and reported.
- ✓Order total $696.59 matched and all six pre-approval checks passed.
- ✓Tests drive the real portal in Chrome: grounding, blocked navigation, the commit gate, approve and reject runs.
- 4
- Parts reordered
- 6/6
- Checks before approval
- 0
- Passwords shown to the model
One out-of-stock substitution
Items, quantities, PO, ship-to
Filled in by code
