Browser agents that operate the systems your work lives in
A browser agent is software that operates a web application through the same interface a person uses. It reads the screen, fills in forms, navigates multi-step flows, and writes the result back to the system of record. Flexbone runs browser agents in production against payer portals, EHR web interfaces, and clearinghouses: eligibility checks, claim status, and prior authorization submission under credentialed, audited access.
What is a browser agent?
A browser agent pairs a language model with a control loop. The loop reads the current page, decides the next action against the goal it was given, executes the click or keystroke, and checks the outcome before moving on. The goal is stated in operational terms, verify this patient's coverage, submit this authorization request, pull this remittance, and the agent works the interface until the task is complete or a rule tells it to stop and hand off.
Because the agent perceives the page rather than replaying a recording, the interface itself is the integration. A system a person can operate through a login page is a system an agent can be scoped to operate: current SaaS portals, vendor sites that predate the term, and internal web tools with no documentation and no roadmap.
How are browser agents different from RPA?
Both operate software through its interface, and that surface similarity hides a structural difference: what the automation does when the software changes.
How RPA works
A developer records a script bound to specific screen elements: this selector, that field, this button. The bot replays the recipe exactly. That makes it fast and predictable while the page stays as it was recorded, and it fails when the page does not: a renamed field, a moved button, an unexpected popup, or an MFA prompt the script has never met.
How a browser agent works
The agent is given the goal, not the recipe. It reads the page as it is today, decides the next step, and checks the outcome. When a layout shifts, a dialog appears, or a login adds a verification step, it re-reads the page and continues. When it cannot continue safely, it stops and escalates to a person rather than failing silently.
RPA still fits a specific shape of work: fixed, high-volume flows on stable internal systems your own team controls, where the interface changes on your schedule rather than a vendor's. The economics turn when the target is a portal you do not control. The full comparison is in browser agents vs RPA, and AI agents vs RPA vs workflow automation places both next to workflow tools like Zapier.
How do browser agents work when there is no API?
The systems that hold day-to-day operational work often expose no API for the part that matters. Payer portals show benefit detail the standard transactions do not carry. Vendor sites and government portals assume a person at a keyboard. Legacy web applications inside the firewall predate the integration budget. The usual choices are manual work or a long interface project with the vendor's roadmap sitting in the critical path.
A browser agent takes a third path: it uses the interface the vendor already ships. There is nothing to procure from the vendor and no certification project, because the agent signs in the way a staff member does, under an account you provision and can revoke. The mechanics, and the limits, are covered in browser agents without APIs.
What about work outside the browser?
Some of the work is not in a browser at all. Claims editors, terminal emulators, thick-client practice management systems, and Citrix-published applications live on the desktop, and they are often the oldest systems in the building and the least likely to grow an API. Desktop agents extend the same model to that surface: the agent perceives the application window, operates keyboard and mouse, and follows the same rules for logging and escalation.
The split between browser and desktop is practical rather than architectural. The workflow decides the surface, and one task can cross both: a lookup in a desktop application feeding a submission in a web portal.
Where does Flexbone run browser agents in production?
Generic claims about agents are cheap, so here is the specific answer: the systems Flexbone operates today and the workflows that run in them. Flexbone holds no partnership with the platforms named below. The agents operate in the portals' web interfaces under credentials each customer provisions and controls.
Availity, UnitedHealthcare, eviCore
Eligibility verification, claim status, and prior authorization submission and status in Availity, the UnitedHealthcare provider portal, eviCore, and payer-specific portals. Portal detail regularly goes past what the 270/271 and 276/277 transactions return, which is what makes the portal worth operating. The dedicated page is payer portal automation.
eClinicalWorks, athenahealth, NextGen
Reading schedules, pulling documentation for an authorization, and writing results back to the chart in the web interfaces of eClinicalWorks, athenahealth, NextGen, and other systems, without an interface build. The list is on EHR integrations.
Claim status and remittance pulls
Claim status checks and remittance retrieval in clearinghouse portals, matched back to the practice management system so the record of what was checked, and what was found, lives where staff already work.
Results land in the system of record
An agent that finds an answer and leaves it in a spreadsheet has moved the work rather than removed it. Results post to the EHR or PM system with the source captured, and exceptions route to staff with the context attached.
How is agent access secured?
Agents hold credentials and touch protected health information, so the security model is the deployment, not a feature bolted onto it. The full model is documented on the security page.
Least privilege
Each agent runs under a named service account you provision, scoped to the portals and functions its workflow requires. Access is revocable the way a staff account is.
Audit trail per action
Each step is logged: the page, the action, the data read or written, and the time. Reviews replay what happened instead of reconstructing it.
Human escalation
Rules define what the agent must not decide. On low confidence, an unexpected state, or a case outside scope, it stops and hands the case to staff with context.
HIPAA experience
Flexbone deploys under signed BAAs, with encryption in transit and at rest and role-based access to PHI in workflows that handle patient data.
How should you evaluate a browser agent?
Four questions separate an agent from a script with a language model attached. Ask each vendor, including us, for the mechanism rather than the assurance.
What happens when the page changes?
How does the system detect that a portal changed, what does it do in the moment, and what does recovery look like? A vendor whose honest answer is a maintenance ticket is describing RPA.
How are credentials held?
Where do portal credentials live, who can read them, how are they rotated, and can you revoke a single agent's access without touching the rest? The answer should sound like your own access policy.
What does the audit trail show?
Ask to see the log of one completed task. If it does not show each action with the data read and written, you cannot review the work, and in a payer dispute that log is the evidence.
What runs attended, and what runs unattended?
Which steps execute without review, which queue for a person, and who decides? The boundary should be a configuration you own, starting conservative and widening as measured accuracy earns it.
Go deeper on browser agents
The guides below cover the definitions, the comparisons, and the healthcare-specific mechanics in more detail.
What Is a Browser Agent?
The definition, the perception-decision-action loop, and where the technology stands.
Browser Agents vs RPA
The full comparison: how each handles change, and when to use which.
AI Agents vs RPA vs Workflow Automation
All three automation models side by side, with the decision criteria.
Browser Agents Without APIs
Why the interface is the integration, and the limits of the approach.
What Is an EHR Browser Agent?
How agents operate the web interfaces of EHR systems safely.
What Is a Website Navigation Agent?
The navigation problem: multi-step flows, session state, and recovery.
The Four Types of AI Agents
Voice, browser, document, and email agents, and how they combine in one operation.
Frequently asked questions
A browser agent is software that operates a web application through the same interface a person uses. It reads the screen, decides the next action against a stated goal, executes clicks and keystrokes, and writes the result back to the system of record. It automates work in systems that expose no API for that work.
RPA replays a recorded script bound to specific screen elements, so it breaks when the page changes. A browser agent perceives the page as it is and pursues the goal, so it recovers from layout changes, popups, and added verification steps, and escalates to a person when it cannot proceed safely. RPA still fits fixed, high-volume flows on stable internal systems you control.
No. The web interface is the integration surface. The agent signs in under an account you provision, the way a staff member does, so there is nothing to procure from the portal vendor and no interface project. Where a system does offer a reliable transaction, such as a 270/271 eligibility check, Flexbone uses it and reserves the agent for what the transaction does not cover.
The agent reads the page on each step rather than replaying a recording, so a moved button or a renamed field is handled in the moment. A change that alters the meaning of the workflow, such as a new required field or a changed consent step, stops the agent, and the case routes to a person while the workflow definition is updated.
Each agent runs under a named, revocable service account with access scoped to its workflow. Credentials are stored encrypted and are not exposed in logs. Flexbone deploys under signed BAAs with encryption in transit and at rest, role-based access to PHI, and a per-action audit log.
That boundary is configuration you control. Deployments start conservative: read-only work such as eligibility and status checks runs unattended first, while submissions queue for review. Steps move to unattended as accuracy is measured on your own volume, and defined exceptions route to staff throughout.
See an agent on your own workflow
We start by auditing the portal work your team does by hand, then run an agent on one workflow and measure it against your own baseline before anything expands.