Your billing team spends half its day inside a browser. That part is automatable now.

The first tools recorded your mouse and played it back at the same screen coordinates. Move a button ten pixels and the whole thing broke. Then Selenium arrived in 2006 and drove the browser from outside through a separate driver program, which was more durable but slow and fragile. In 2017 Google shipped Puppeteer, which spoke Chrome's own internal protocol instead of knocking on the door from outside. In 2020 the same engineers left and built Playwright at Microsoft, which added the thing that actually mattered: it waits for the page by itself. Before Playwright, half of all automation code was sleep statements and retry loops.

Every one of those still needed a human to write down, in advance, exactly which element to click. That instruction is called a selector, and a selector is a promise about a page you do not control. Payers redesign portals. Selectors break. Somebody has to fix them. That maintenance burden is the real reason most billing teams gave up on automation after the second portal.

An AI model can now look at a page and decide what to do with it. There are two ways it looks, and the difference is the whole engineering decision.

It can read the page's structure. The browser hands over the underlying text and the accessibility tree, the same thing a screen reader uses. The model sees "button, Search Claims" and clicks it. This is fast, roughly a tenth of a second per step, and light. It works on most of the web.

Or it can look at a picture of the screen. A vision model gets a screenshot and returns coordinates to click, exactly like a person looking at a monitor. This is slower and much heavier per step. But it does not care what the page is made of. Canvas, an embedded Citrix session, a scanned image of a table: if a human can see it, the model can work it.

The rule we follow is read the structure first, look at the picture only when the structure is not there. Most teams get this backwards, reach for the vision model because the demos look impressive, and then wonder why their usage is enormous.

Here is the mistake we see most often.

A team wires up an AI agent, points it at a portal, and it works. So they run it on all two hundred claims. Now they are asking a language model to rediscover the same portal two hundred times, and every run is a fresh roll of the dice on whether it clicks the right thing.

The agent should run once. It explores the portal, works out the sequence, and writes an ordinary script. From then on the script runs, on a schedule, with no model involved at all. The intelligence goes into discovery. Execution is deterministic and repeatable.

That single change is the difference between automation that holds up and automation that quietly becomes your third-largest line item. When the payer redesigns the portal and the script breaks, you send the agent in again to rewrite it. That takes minutes, and it is the only moment a model is needed.

This is where healthcare stops being like every other industry, and it is worth being precise about it.

A vision model working a portal is looking at member IDs, dates of birth, diagnosis codes. The whole protected set, on screen, one screenshot after another. Every one of those screenshots has to go somewhere to be read. If that somewhere is a commercial API, you have just built a continuous export of patient data to a third party, and that is a conversation with your compliance officer you should not have to have.

So the model runs on hardware you control. We run our own language models on our own L40S GPUs for exactly this reason, and we are extending the same setup to the vision side. Two things follow.

Nothing leaves the building. There is no third party to sign an agreement with, because there is no third party.

And the second thing is quieter but changes more. Once the hardware is already yours, another look at a screen is free. That is what makes it reasonable to point a vision model at a portal that needs a thousand screenshots a day. Priced per call, you would never do it. On your own machine, you stop counting.

Some of this should not be automated, and pretending otherwise is how people get into trouble.

Logins with multi-factor authentication stay with a human. There is a tidy way to do this: the automation runs inside the browser the person is already signed into, so it inherits the session rather than handling any password. Nobody stores a credential.

Anything that commits money or changes a claim gets read by a person before it goes. Reading a status is safe. Filing an appeal is not the same category, and the speed you gain is not worth the thing you break.

And volume is the tell. Two hundred lookups spread across a working day looks like a busy biller. Two hundred in ninety seconds looks like exactly what it is, and gets you blocked. Slow it down.

Not with the biggest portal. Start with the one your team complains about most, where the work is genuinely repetitive and nothing is at stake if it goes wrong. Usually that is claim status lookups. Have an agent walk it once and produce a script. Run that script every morning before anyone logs in, and have the results already in the system when the team arrives.

Then do the second portal. The value is not in one clever automation. It is in the fifth one, when the pattern is boring and adding another payer takes an afternoon.

That is the whole thing. The browser is where your team's day goes, and for the first time the software can find its own way around it.