Insurance work on both sides of the industry funnels into portals. In healthcare, providers live in payer portals such as Availity, the UnitedHealthcare provider portal, and eviCore for eligibility, claim status, and prior authorization. At agencies and brokerages, service teams live in carrier portals for policy lookups, billing status, claims status, and the policy detail behind certificate issuance. Almost none of that work has an API; the portal is the interface. A browser agent automates it by operating the portal the way a person does: it signs in under an account you provision, reads the screen, completes the task, and writes the result back to the system of record. Unlike an RPA script, it adapts when the portal changes and hands off to a person when a case falls outside its scope.
Why does so much insurance work run through portals?
Because the portal is where carriers and payers put the work they did not build transactions for. Healthcare has standard EDI transactions, the 270/271 for eligibility and the 276/277 for claim status, but they return summaries, and the detail that decides real questions lives behind the portal login: visit-type copays, remaining deductibles, authorization forms, denial context. On the property and casualty side there is even less standardization. Each carrier runs its own portal with its own layout, login, and session rules, and an agency servicing a book across a dozen carriers holds a dozen sets of credentials. The work is not hard; it is navigation, reading, and re-keying. It consumes service time precisely because it must be done by hand, one login at a time, in systems the organization does not control.
Want this mapped against your own call and claim volume? Book a 30-minute audit
What does a browser agent actually do in a portal?
It runs a loop a person would recognize. The agent signs in with a service account, navigates to the member, policy, or claim in question, reads what is on the screen, and decides the next step against the task it was given: verify this coverage, pull this declarations page, check this claim. When the task ends, the result is written back to the system the team already works in, the EHR or practice management system in healthcare, the agency management system at a brokerage, together with a log of each action taken. The model underneath reads the page rather than a stored recording of the page, which is the property that makes the rest work. Anthropic's computer use work showed frontier models operating a screen directly (Anthropic), and portal agents are that capability pointed at a narrow, repeatable class of work.
See what AI can run at your facility. In a 30-minute audit we map the calls, eligibility, and follow-ups Flexbone can take off your team first.
Book an auditWhat portal work runs in healthcare?
The provider side is the more mature case. Eligibility verification beyond the 270/271: the agent opens the payer portal and captures the benefit detail the transaction does not return, posting it to the chart before the visit. Claim status beyond the 276/277: line-level detail and the reason a payment stalled, matched back to the account. Prior authorization: form submission, document upload, and status checks on the pended queue. Remittance pulls: retrieving documents the payer never sent electronically. Flexbone runs these workflows in production in Availity, the UnitedHealthcare provider portal, eviCore, and payer-specific portals, with no partnership with those platforms; the agents operate the portals' web interfaces under credentials each practice provisions and controls.
What portal work runs at an insurance agency?
The same mechanism against carrier portals. Policy lookups when a client calls about coverage or renewal terms. Billing and payment status checks that today interrupt a CSR mid-task. Claims status checks across the carriers holding the book. Document retrieval, declarations pages and policy forms, filed to the agency management system. And the lookup work behind certificate issuance: confirming the policy detail a certificate depends on before it goes out. The portal work pairs naturally with the phone work, because the calls that drive portal lookups are themselves automatable; that side is covered on voice AI for insurance. What stays with licensed staff is advice, coverage judgment, and anything the agent was not scoped to decide.
Why not just script it with RPA?
Because portals are hostile territory for recorded scripts. RPA binds to specific screen elements, and carriers and payers redesign their portals on their own schedule, so the script that worked in March fails in April (UiPath describes the recorded-recipe model). MFA prompts, session timeouts, and interstitial notices interrupt flows in ways a replay cannot answer. A browser agent reads the page before each action, so a moved field or a new notice is handled in the moment, and an interrupted session is re-established and resumed. The honest boundary runs the other way too: a fixed, high-volume flow on a stable internal system your own team controls is still a reasonable RPA target. The deeper treatment is in browser agents without APIs.
How should a team start with portal agents?
Start where the hours are, and start read-only. Pick the two or three portals that consume the most service time and one workflow, eligibility checks, claims status, or policy lookups, and run the agent unattended on read-only work first while anything that writes or submits queues for human review. Measure against your own baseline: tasks completed, exceptions raised, and what staff did with the time. Widen the unattended boundary only as measured accuracy earns it. Insist on the operational basics from any vendor: named revocable credentials, a per-action audit log, and escalation rules you define. If you want to see this on your own portals rather than in the abstract, talk to our team and we will start with an audit of where your portal hours actually go.