Can you automate a supplier portal that has no API?

Yes, by driving the browser the way a person does. agent-browser opens the page, returns it as compact text with element refs, and acts on those refs from the shell, so no API is needed. The tradeoff is that the script depends on the portal's layout staying stable.

Is agent-browser an RFQ monitoring tool?

No. The repository describes it as a browser automation CLI for AI agents. RFQ monitoring is something you build on top of it, including the scheduling, the alerting and the rules about when it may act.

How do you keep portal logins safe in a browser agent?

The documentation linked from the repository lists an auth vault, domain allowlists, action policies and content boundaries. Use all four, give the agent its own portal account where the supplier allows it, and keep the raw output so every session can be reviewed.

Browser automation for supplier portals with no API

Most RFQ and supplier portals have no API, and that is usually where automation talk stops. It does not have to.

What agent-browser actually is

It is a browser automation CLI for AI agents, in the words of its own repository, not a monitoring product or an RFQ tool.

The README describes a native Rust CLI that gives an agent a browser it can drive one command at a time, with example commands including open, snapshot, click, get url and close. A snapshot returns compact text with refs such as @e1, and the agent acts on those refs and repeats.

That loop is the whole idea. No CSS selectors to reverse engineer, no vendor integration to wait for. Install is npm install -g agent-browser; the README also mentions a skills integration via npx skills add vercel-labs/agent-browser.

It is the same shape as CRM workflow automation with no API: drive the interface a human already uses instead of waiting for an endpoint nobody will build for you.

How to set up browser automation for supplier portals in about three hours

Six steps, about 180 minutes total, estimated from the documentation and not timed against a live portal.

Install and open one page (about 20 minutes). Install globally, open the portal login page, take a snapshot, read the refs that come back.
Map the path by hand (about 40 minutes). Log in yourself, reach the page that holds the status, and write down the ref at each step. This decides whether the rest works.
Write the check (about 45 minutes). Turn the mapped path into a script: open, log in, navigate, snapshot, pull out the status lines.
Lock the access down (about 30 minutes). The documentation linked from the repository lists an auth vault, domain allowlists, action policies and content boundaries. Use all four, not one.
Output and schedule (about 25 minutes). Write the snapshot to a file, diff it against yesterday, send the diff once a day. Keep the raw output so you can audit what the agent actually did.
Watch it for a week (about 20 minutes of attention). Read the output daily before you believe it.

Skip in week one: submitting a quote, changing a line item, acknowledging anything. Read only.

Act or alert: the decision table

This is the part that turns a script into something an office can live with.

What the check finds	Agent acts	Alert a human
Status unchanged	log it, say nothing	no
Status moved forward	log it	daily digest
New RFQ appeared	nothing	same hour
Login failed or layout changed	stop	same hour
Price or quantity field differs	nothing, ever	same hour

If you want the agent to eventually act on the top two rows, put the gate in before it does, not after. An approval layer before the agent acts is cheaper than an apology to a supplier.

How much time does this save

Run the arithmetic on your own numbers. If an estimator checks six portals twice a day at four minutes each, that is 48 minutes a day, about four hours a week.

The honest target is removing the checking, not the deciding. Get half of it back and that is about two hours a week, so a three-hour build pays for itself in under two weeks, assuming nothing breaks.

Limitations

The portal is the fragile part. A redesigned table, a new consent banner or an extra login step changes the refs and your script stops matching.
No vendor claim supports this use. The repository calls the project browser automation for AI agents; it says nothing about supplier portals, RFQ workflows or manufacturing.
Credentials are the real risk. A script that logs into a customer portal holds commercial access. The auth vault and allowlist exist for that reason, and sharing one login across a team undoes both.
Running a real browser on a schedule costs CPU and memory. The same tradeoff shows up in swapping Puppeteer for Lightpanda on one scraping bot.
I have not tested this against a supplier portal, and step 2 likely takes longer than 40 minutes on a portal with a multi-step login.

My take

Build the read-only version this month and leave it read only. The value is not the agent clicking things, it is that nobody has to open six tabs before the morning meeting. If the check survives a month of portal changes without hand holding, then talk about letting it act, with the alert rules above already written down.