Using Browser Agents for Data Entry in Legacy Web Portals

Two screens and a very patient person

Every sector has its portals. Carrier booking sites in logistics. Local authority and regulator submission forms. Insurer and lender broker portals. Supplier ordering sites in construction and hospitality. They are web-based, which sounds modern, but many were built fifteen years ago, offer no API, no bulk upload and no export beyond a PDF.

So a person keeps the spreadsheet open on one screen and the portal on the other, and types. A lettings agency registering tenancy deposits, a builders' merchant placing orders across six supplier sites, a care provider submitting returns: each can easily lose a day a week to this. Browser agents are the first tool that tackles the long tail of these portals at a sensible price.

What a browser agent does differently from a script

Automated browsers are not new. Testing tools and scrapers have driven browsers for years. The difference is who writes the steps. A traditional script hard-codes every selector and click, so it breaks when a field is renamed. A browser agent reads the page structure and visible text, works out which field is which, and adapts when a label moves or a new optional field appears.

In practice the best builds are a mixture. Stable steps such as logging in and navigating to the form are scripted, because that is faster and cheaper. The agent handles the form itself, the dropdowns whose options vary, and the confirmation page. For the technical side of building one, see our guide on building an AI agent that browses the web.

Tasks that suit browser agents, and tasks that do not

If you are on the left-hand side of that table for most of your portal work, a browser agent is worth a proper look. If you are mostly on the right, the answer is usually to push the vendor for a file import or accept that a person stays involved.

Accuracy: verify, do not trust

The central risk with data entry is not a crash. It is a record entered slightly wrong, such as a date in US format or the wrong item from a long dropdown, which nobody notices until weeks later. A browser agent has to be designed around catching that.

1. Validate the source record before the agent starts, with plain code: required fields present, dates valid, codes recognised
2. Let the agent fill the form, then read back every field value from the page before submitting
3. Compare the read-back against the source with code, not with the model's opinion
4. Submit, capture the confirmation reference and a screenshot
5. Where the portal allows, search for the submitted record and check it once more
6. Anything that fails a check goes to an exceptions list with the screenshot attached

That sounds slow, and it is slower than blind entry. It is also the difference between a system you trust and one somebody has to recheck by hand, which saves nothing.

Credentials, access and the terms of use

Portals usually require a named login, and many forbid sharing it. Before building anything, check the portal's terms on automated access. Some explicitly allow account holders to automate their own submissions, some are silent, and some prohibit it. Where there is doubt, ask the vendor. We have seen vendors offer a hidden bulk upload as soon as someone asks.

• Use a dedicated account for the agent where the portal allows one
• Store credentials in a secrets manager, never in a prompt or a script file
• Handle multi-factor authentication through an approved method, not by forwarding codes from someone's phone
• Restrict the agent's browser to the portal's domains
• Log every session so any submission can be traced back to its source record

Older portals are also a security consideration in their own right. Our post on connecting legacy systems safely covers the wider set of precautions.

What it costs to run

Running costs come from model usage during the agent-driven steps and from hosting the browsers. Because login and navigation can be scripted, model usage per record is usually modest. A typical illustration: a merchant entering 120 orders a day across supplier portals, at roughly five minutes each by hand, is spending ten hours a day. An agent taking two or three minutes per order, with a person reviewing a handful of exceptions, returns most of that time.

The build cost depends mostly on the number of distinct portals and how awkward each one is. One portal with one form is a small project. Twelve portals with different logins, layouts and quirks is several, and it is worth starting with the one that consumes the most hours.

Before you build, ask for the export

The cheapest browser agent is the one you never need. At SpiderHunts, the first week of any portal project goes on finding a better route: a file import the vendor has not advertised, a partner API, an EDI feed, or an arrangement where the vendor accepts a spreadsheet. If one exists, we build a normal integration through our automation work and the agent is not needed.

When no route exists, a browser agent with the verification steps above is a sensible answer, and it can be retired the day the vendor finally ships an API.

Frequently asked questions