Smart RPA: The Browser is the API Now

Automating insurance portals that weren’t built for AI

A lot of insurance work still lives behind a login and a web form. Many carrier portals have no API at all, while others expose only part of the functionality employees need.  Agency management systems often require employees to log in every morning to retrieve the same reports manually.  For those systems, the only real interface is the one a human uses: the browser.

That's an awkward fit for the way most automation gets built. Handwritten scripts break the first time the site shifts a button. An AI agent that relies entirely on an LLM to control the browser is adaptable but slow, expensive, and hard to trust on the hundredth run. Smart RPA (sRPA) is our attempt to keep the adaptability of a reasoning agent and the speed, cost, and consistency of traditional RPA, on trusted, familiar portals, running predictable workflows, with guardrails that matter in a regulated industry. It's live in production today across three use cases, triggered from our voice-agent workflows. This is how it works and what we've learned running it.

Why not just reason every time?

Building agentic workflows taught us one important lesson: When an AI model is given reliable browser actions, such as navigating pages, clicking buttons and entering information, it can use a website much like a person does. The Model Context Protocol, together with Playwright, an industry-standard browser automation framework that ships an MCP server, gave us exactly that: reliable browser actions (navigate, click, type, read the page) that a model can call.

The simplest approach is to ask AI to figure out the workflow from scratch every time. We deliberately didn't build that. That approach is slower, more expensive, and less predictable; three things you don't want when the same job runs thousands of times against a stable portal. So we split the problem in two. Learn a successful path once with the LLM. Replay it consistently on repeat runs. Fall back to full reasoning only when the web page has changed.

We were never going to bypass multi-factor authentication. Rather than automate around it, we built a human into the loop for exactly those moments. More on that below.

What we built

Workflows are written in plain language instead of code. An engineer describes a workflow as paired ACT and VERIFICATION steps. "Log into the carrier website," then "Verify we're logged in." "Navigate to the documents tab," then "Verify the documents tab is open." No hand-written browser script is produced. An AI engineer validates each step against the live site with Playwright MCP before deployment. Act-then-verify keeps the workflow aligned with the business process and stops it from wandering into unrelated pages.

The first run discovers the path. The agent reasons over a compact, text-based representation of the page, not screenshots by default, and drives the browser through MCP tools to accomplish each step. When a step succeeds, the exact sequence of actions gets recorded. Critically, it's stored with semantic selectors (role plus name) and a structural path, not the brittle one-time element IDs that make traditional RPA so fragile.

Repeat runs reuse the workflow. The recorded sequence replays consistently, re-resolving each element against the live page. In the good case, with stable UI and cache hits on the ACT steps, the agent completes work at almost no processing cost. Verification steps, non-cached steps, and drift fallbacks still require AI processing. That hybrid is the whole point: AI's adaptability where you need it, traditional RPA's economics where you don't.

Verification runs on every single pass. We validate the outcome in the browser rather than assuming a click worked. A replayed click that lands on the wrong page gets caught by the verification step that follows it, not three steps later when the run has already gone sideways.

Self-healing absorbs drift. If the page changed and a previously learned element can no longer be resolved, the agent falls back to the LLM: "I don't see the documents page, let me find and open it, then verify again." It completes the step, and for cache-enabled steps, updates the corrected sequence for next time. The portal changing is expected. Failing when it changes is not.

A human takes the wheel for MFA. When a step needs a person, the run pauses and a Liberate supervisor can open a secure, live, interactive view of the running browser session. The human completes the MFA challenge; control hands back to the agent; the run continues. This is the production path, and it's clear about what shouldn't be automated.

One login supports many automated tasks. Smart RPA securely reuses a single authenticated session across multiple workflows. This reduces repetitive logins, lowers the risk of triggering bot-detection systems and improves efficiency. When the session expires, new tasks pause until a supervisor completes another login, then automatically resume where they left off. 

Everything runs beyond the browser, too. Agents can call other Liberate workflow tools mid-run or after (email a downloaded policy PDF, for instance), and every run produces an audit trail: video, screenshots, and transcripts, stored securely, isolated for each customer and encrypted.

What we've found

Self-healing is solving real production problems, not just looking good in demos. About 60% of successful runs retried at least one step, showing that website changes and other variations happen frequently in real-world environments. Self-healing absorbs those changes so workflows can still complete successfully. Just as importantly, retry and failure patterns show us exactly where workflows need to be refined, helping the system become more reliable over time. 

The expected success rate is 70-80%, and the failure path is a feature. We don't run this at a number we can't defend. When a run fails, it automatically reroutes to the manual processing queue as a fail-safe. No request is dropped. That design choice is what lets us ship at 70-80% instead of waiting for a number that doesn't exist yet.

Consistency keeps costs low. On stable, cached flows, the agent acts with near-zero model cost. Reasoning becomes the exception the system uses, not the loop it lives in. That's what makes running the same portal job at scale sustainable.

The part that's still hard

Seventy to eighty percent means one in four or five runs still doesn't complete on its own. We're candid about that because the gap is exactly where the interesting engineering is. Portals drift in ways no one documents. Bot detection is an adversary, not a constant. Some flows genuinely need a human, and the best move is to route the task for human review rather than report a task as complete when it isn't. The fail-safe queue is the floor, not the ceiling. The work is closing the distance between them, and the retry data is the map for doing it.

Why it matters

A policyholder is on the phone at midnight and needs to know whether a coverage or payment went through before they can finish the call. That answer lives in a portal with no API. Someone has to log in, click through, and read it back. Today that means a customer service representative has to be online. Smart RPA lets that lookup happen synchronously, mid-conversation, with a clearly defined workflow, so the person gets their answer, and the CSR is freed for the call that actually needs judgment.

This is the core idea behind Smart RPA. 5% is the conversation. 95% is the orchestration behind it, and a surprising amount of that orchestration still happens in a browser, one login and one click at a time.

Smart RPA is how we do that part reliably now, while modern system integrations continue to evolve. That's some of the most interesting engineering work we're doing because it's solving a problem insurers face every day.