Use caseBrowser automationAI agent
Automating portals and legacy systems that have no API, with a person approving the final click
A computer-use agent that fills insurer portals and legacy desktop screens with no API, uses APIs wherever they exist, and stops for a person before it submits.
A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .
The short version
A hybrid automation for work that ends in a system with no API: insurer and carrier portals, government sites, old desktop ERPs and terminal screens. Data is read through APIs or the database wherever possible, and a computer-use model operates only the screens with no alternative, in an isolated session with credentials injected from a vault. It reads every value back, screenshots each step, and waits for a person's approval before submitting. Stable steps can stay with existing RPA bots.
- Best for
- Brokers, forwarders and back offices that re-key the same data into several portals or an old desktop system every day, with no API covering it.
- Connects to
- Broker management system, Insurer and carrier portals, A legacy desktop ERP, Computer-use model (Copilot Studio, Claude or OpenAI), Outlook, UiPath or another existing RPA, A secrets vault
- The AI does
- Operates the screens that have no API: finds each field, types the value it was given, and copes with the moved buttons and pop-ups that break scripted bots.
- People do
- Complete MFA prompts and CAPTCHAs, approve each submission after comparing intended and entered values, and take over whatever the agent stops on.
- Built as
- AI Agent Development, usually $12K - $30K
Six portals, one set of facts, typed six times
Consider a commercial insurance broker with 30 staff, placing property and liability cover for small manufacturers with six insurers. At renewal, an account manager gathers updated figures from the client, then keys the same facts into six insurer portals to get terms: company details, turnover, sums insured, five years of claims. Each portal has its own login, field names and trade codes. One renewal costs an afternoon of typing, and in the autumn season there are dozens a week.
Two years ago the broker paid for RPA bots recorded against each portal. They worked until two insurers redesigned their forms; now a bot breaks every few weeks, the contractor bills per fix, and staff type by hand for the portals that change most. A forwarder keying bookings into a shipping line's portal knows the pattern, as does a wholesaler still feeding a 1990s text-terminal system through a SendKeys macro: no API, no clean exports, just screens.
Computer-use models change the arithmetic. They read the screen, find fields by their labels and keep working when a button moves; OpenAI's GPT-5.4 scored 75.0% on the OSWorld desktop benchmark against a 72.4% human baseline, and Microsoft made computer use in Copilot Studio generally available on 13 May 2026. But a benchmark is not your insurer's portal, and a model that is right most of the time should not submit a client's application unsupervised.
So the design is a hybrid with a person at the end. APIs and data standards come first wherever they exist, such as BiPRO interfaces with the German insurers that support them; scripts handle stable screens; the model gets only the screens with nothing better; and the final click belongs to the account manager. Where client documents arrive by email, insurance submission intake covers the extraction side.
One portal submission, from the inside
What the account manager sees is a request for approval. Behind it are the actions the model took, the checks code ran, and the point where it stopped.
Insurer D portal, renewal R-2231, Thursday 10:42
- session.start(portal: "insurer-d", user: "a.keller", browser: "isolated")login typed from the vault / MFA push sent to A. Keller
Agent · Approval app
Insurer D is asking for MFA on your login. Approve it on your phone and I will carry on.
- Confirmed at 10:43. The session continues under her named account.
- screen.find(label: "Sum insured, contents")page 3 of 5 / label moved since the last run / matched by text, not position
- screen.type(field: "Sum insured, contents", value: "1850000")typed
- screen.select(field: "Trade", value: "Machining, CNC (MW-114)")chosen from the insurer's own list, per the mapping
- readback(page: 3)12 of 12 fields match / portal notice: 'Claims history requires referral to underwriter'
- readback(all_pages: true)47 of 47 fields match / 0 mismatches / 1 notice carried forward
Agent · Approval app
Renewal R-2231, Insurer D: 47 fields entered and verified against the renewal record. The portal will refer it to an underwriter because of the claims history. Screenshots of all five pages attached. Approve submission?
A. Keller · Approval app
Approved. The referral is expected.
- screen.click("Submit application")reference ANF-7731204 / status: referred to underwriter
- broker_system.attach(renewal: "R-2231", reference: "ANF-7731204", files: 6)filed / approved by A. Keller at 10:51 / 38 model steps logged
Choosing the route for each system
Before a model touches a screen, each target gets the cheapest route that is reliable. Most builds combine three or four.
| What the target offers | Route | Why |
|---|---|---|
| An API or data standard, such as BiPRO or a carrier's booking API | Use it | Typed, fast, cheap per call, and immune to page redesigns |
| No API, but a readable database or a nightly export | Read from the data, write through the screens | Pulling data out of screens is the slowest, least reliable thing a model does |
| A stable, high-volume screen that rarely changes | A scripted bot: an existing UiPath process, or Playwright on the web | Deterministic and cheaper per run, until the screen changes |
| Screens that change, vary by case or need judgement | A computer-use model, with read-back and approval | Copes with moved fields and new pop-ups, at a price per step |
| A CAPTCHA, an MFA prompt, a legal declaration | A person | They exist to prove a human is present, so the agent stops and asks |
A renewal, from request to approved submission
The model operates portals and nothing else. What gets submitted is settled beforehand by code and the account manager; whether it is submitted is settled by a person at the end.
01 Trigger · Broker system, Outlook
Quotes are requested
The account manager picks a renewal and the insurers to approach, in the broker system or an Outlook add-in.
02 System · Database views or API
Assemble the risk record
Client details, sums insured and claims history come from the broker system's database or API as one record the account manager has checked. Nothing is typed from memory or from an email.
03 Plain code
Map the record to each insurer
A per-portal mapping converts the record to that insurer's fields and formats: its own trade codes, dates as DD.MM.YYYY, amounts without separators where required. An unmapped value stops the job before any portal opens.
04 AI model · Computer-use model
Fill the form
In a fresh, isolated browser session, the model navigates the portal and types each mapped value. The harness types passwords from the vault, and only allowlisted portal domains are reachable.
05 Plain code
Read back and compare
Entered values are read back (from the DOM on web portals, the accessibility tree or OCR on desktop apps) and compared with the record, field by field.
06 Decision
Does every field match?
Decided by code, never by the model's own account of what it did.
- All fields match and there is no new portal warning then request approval
- A mismatch, an unexpected field or a new warning then stop, keep the session, and hand the comparison to a person
- The session expired or the page changed shape then log in again, check the portal's open applications, and resume from the last completed page
07 Person
Approve the submission
The account manager sees each page's screenshot, the field-by-field comparison and the insurer's notices, then approves or takes over. Only an approval lets the agent press submit.
08 Result · Broker system
File the result
The quote reference, premium and any referral note are read from the confirmation page and filed on the renewal, with the screenshots and the approver's name.
The weak spots of screen automation
Real portals add what no benchmark includes: logins that expire, forms that change without notice, fields that look alike.
The portal changes its layout
Recorded bots fail when a field moves; a model usually copes, because it finds fields by their labels. It can also cope wrongly and type into a field that merely looks right, so every value is read back, and the first run after a page changes shape is flagged for a person to watch.
CAPTCHAs and MFA
Both exist to prove a person is there, so a person handles them. The agent never attempts a CAPTCHA and never holds an MFA seed; it pauses, pings the named user and continues in the same session. Portals that ask at every login shape the schedule, so runs are batched into windows when approvers are at their desks.
Sessions that time out
Portals log users out mid-form, and some hold a quote for only a fixed number of minutes. The agent saves drafts where it can and records completed pages; after a re-login it checks the portal's list of open applications first, so a timeout never creates a second application.
The right value in the wrong field
The most damaging failure is quiet: a sum insured in the deductible field, a date read in American order. Code checks each field's format, the read-back compares every field with the record, and the approval screen highlights anything the portal changed itself, such as rounding or a default.
Credentials
Many insurers issue portal accounts to named people, so each user's credentials sit in a vault and are typed by the harness, outside the model's context. Passwords never reach prompts, logs or screenshots, and a session runs under the account of the person who approves its result.
Proving what was submitted
Each step keeps a screenshot, the action and the model's stated reason, and each submission records its approver and what they saw. Screenshots hold policyholders' personal data, so they stay in the EU under a retention period agreed with the data protection officer, and any health details are special category data under Article 9 of the GDPR, with access restricted to match.
Who holds the mouse at each step
The model is trusted with one job: operating a screen. Text on a portal page is data, never instructions, the rule from prompt injection defense.
The AI model
Navigate the portal and enter the values
The one job a model does better than a script: finding fields on a changed screen.
Summarize insurer notices for the reviewer
Free text in each insurer's own style; two lines spare the reviewer five pages.
Plain code
Read the client and risk data
From the broker system's API or database, never from screens or emails.
Convert the record into each insurer's fields
Deterministic and testable; a model guessing a date format is how 03/04 goes wrong.
Log in and type passwords
Secrets go from the vault to the field without passing through the model.
Read back and compare every field
An independent check that shares none of the model's mistakes.
A person
MFA prompts and CAPTCHAs
They exist to prove a human is present.
Approve each submission
An application can commit the client, so the broker decides.
Choose insurers and advise the client
Regulated broker work, and no part of the portal task.
Unattended for some tasks, never for others
Autonomy is earned per task type and per portal, and some tasks never get it.
| Task | Starts as | Where it can end up |
|---|---|---|
| Downloading policy documents, claim statuses and statements | Supervised runs, checked against staff downloads | Unattended once a portal runs clean for several weeks, since the task only reads |
| A new portal, or one that just changed layout | Shadow mode: the agent fills a form it never submits while staff do the real entry | Supervised filling, once its read-backs match staff entries on real cases |
| A non-binding quote request | A person checks every field on every page | Approval from the comparison and screenshots, then the agent presses submit |
| An application, or anything that could bind cover | A person checks every field and submits | The same approval click, permanently, however good the numbers get |
Copilot Studio, your RPA vendor's agents, or a custom harness?
On Microsoft 365, with the work in Windows applications or websites, try Copilot Studio's computer use first. It runs on OpenAI's computer-using model or Claude Sonnet 4.5 (newer Claude models are marked experimental), keeps credentials in Power Platform or your Azure Key Vault, can be limited to allowlisted sites and apps, and bills 5 Copilot Credits per step, or 15 on a premium model; TechHQ put that at roughly US$0.04 per step on the standard prepaid pack. Microsoft's documentation adds two caveats: credential entry may not work in Citrix, Java or Electron apps, and its sample instructions submit forms with 'no confirmation needed'. For anything binding, design the approval in on purpose.
If you already run UiPath or Automation Anywhere, try their agentic features before replacing anything. UiPath's Maestro orchestrates agents, people and robots in one process, and a model for the exceptions inside a platform you already license is often cheaper than starting over. And if the insurer or carrier offers an API or data standard for the task, it beats every screen-based option.
A custom harness wins when the work spans systems none of those reach well: portals, a legacy ERP read through its database, the broker system, and an approval screen that shows a field-by-field comparison rather than a summary. It also gives control over which model runs, where screenshots live, how cost per step is capped and what happens on a timeout. That is AI agent development with a narrow brief; the approval pattern is covered in human-in-the-loop AI.
How you would know it is working
A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.
- First-pass match rate
- Submissions where every read-back matched the record before approval, per portal. A drop after a portal update is the early warning.
- Interventions per submission
- MFA prompts, mismatches, timeouts and take-overs, counted by cause, so effort goes where the friction is.
- Approver changes
- How often the reviewer corrects something or takes over. Weeks without changes mean a mapping is right; frequent edits show where it is not.
- Cost per completed submission
- Model steps or credits per job and portal, set against the scripted bot and the manual time for the same task.
- Duplicate applications
- Applications an insurer received twice for one renewal. The target is zero, and a single one triggers a review of timeout handling.
What a build like this costs
This is built as AI Agent Development, which runs $12K - $60K overall. A build like this one usually lands in the single-purpose agent tier: $12K - $30K, 2-5 weeks. The first working version runs on your real data well before the end of that window.
What it costs to run
The main running cost is per model step, and a form of forty to sixty fields can take several dozen steps. Copilot Studio bills that in credits; Claude or OpenAI models used directly cost tokens per screenshot and action, which the harness counts and caps per job. Scripted bots stay cheaper on stable screens, which is why the hybrid keeps them.
What moves the price
- How many portals or applications, and how different they are: each needs a field mapping, read-back rules and test cases
- Whether the source data is readable through an API or database, or must itself be pulled from screens or documents
- Login friction: MFA on every session, CAPTCHAs and named-account rules shape scheduling and approvals
- Web versus desktop: web portals allow read-back from the page, while desktop apps over Citrix or Remote Desktop need screenshot checks
- Working alongside an existing RPA estate, if stable bots stay and the model takes the exceptions
Who this is for
- Insurance brokers re-keying renewal and new-business data into several insurer portals
- Freight forwarders entering bookings and shipping instructions into carrier portals that offer no API for them
- Companies running an old desktop ERP or terminal application that only accepts data through its screens
- Teams whose RPA bots break every time a vendor redesigns a page, with a maintenance bill to match
- Microsoft 365 organizations weighing Copilot Studio computer use against a custom build
Questions people ask about this
Can AI agents automate a desktop application that has no API?
Yes. Computer-use models work from screenshots and can operate any application a person can, including older Windows programs and terminal screens. Stable screens with clear labels work well; Citrix sessions and custom-drawn controls are harder. Where the database or a scripting interface exists, it handles the reading, and the model drives only the screens with no alternative.
RPA vs AI agents: which is better for legacy systems?
Neither on its own. RPA bots are cheaper and more predictable on stable, high-volume screens, and they break when a screen changes. Computer-use agents cope with change but cost more per step and need verification. The practical answer is a hybrid: bots on the stable paths, the model on exceptions and changing screens, and a person before anything is submitted.
Should we use Claude or Power Automate to automate an old ERP with no API?
It depends where you already work. On Microsoft 365 with a Windows ERP, Power Automate desktop flows and Copilot Studio's computer use, which can run Claude or OpenAI models, are the natural start. If the ERP sits behind Citrix, the work spans other systems, or approval needs a field-by-field comparison, a custom harness gives more control. Either way, read from the database first.
Can an AI agent work in SAP GUI?
It can, since SAP GUI is a Windows application a computer-use model can operate, but it is rarely the best route. SAP systems expose BAPIs, IDocs and OData services, and SAP GUI Scripting lets code drive transactions deterministically. I would use those first and keep screen-level automation for custom transactions that none of them cover.
How much does a computer-use agent cost to run?
It is priced per step, not per task. Microsoft bills Copilot Studio computer use at 5 Copilot Credits per step on standard models, while Claude or OpenAI models used directly cost tokens per screenshot and action. A long form can take dozens of steps, so the build counts and caps steps per job and keeps cheaper scripted bots on stable screens.
Does the EU AI Act treat an agent that fills insurance forms as high-risk?
Not in itself. The Act's high-risk list covers risk assessment and pricing in life and health insurance for individuals, obligations now due from 2 December 2027 after the Digital Omnibus. An agent typing a broker's approved data into a portal does neither; pricing stays with the insurer. The GDPR applies in full, since screenshots hold policyholders' personal data.
Sources
- Microsoft Learn: computer use in Copilot Studio (models, credits per step, credential support)
- TechHQ: Copilot Studio computer use generally available, pricing and governance
- DataCamp: GPT-5.4 vs Claude Opus 4.6, including OSWorld scores
- UiPath agentic automation roadmap (Maestro)
- Gibson Dunn: EU AI Act Omnibus and the postponed high-risk deadlines