Failure Mode Taxonomy for Clinical GUI Agents
GUI agents fail at healthcare tasks despite nailing individual steps.

Healthcare administration accounts for over $1 trillion a year in annual spending across the US, and a growing share of that money now moves through software agents that read screens, click buttons, and fill out forms the way a staff member would. That scale is why the failure patterns in these agents matter now, not in some future rollout nobody's built yet. The honest accounting of where these systems break down is overdue, and most vendor pitches skip straight past it.
A GUI agent doesn't call an API or run a script against a known schema. It looks at a screen, works out what it's seeing, and acts, moving through EHRs, payer portals, fax queues, and third-party tools the way a new hire fumbles through their first week. That's a different failure profile than robotic process automation, which breaks when a scripted rule gets violated, or API integration, which breaks when a schema changes underneath it. GUI agents fail for a third reason: they misjudge what's on the screen in front of them, or they lose track of where they are in a process spanning multiple systems. Healthcare piles its own constraints on top of that: gated portal access, thin documentation, session timeouts, CAPTCHAs, and payer portals that behave differently from one insurer to the next.
Most benchmarking work on computer-use agents comes out of web navigation tasks or general office software, and none of it was built to capture those constraints. What follows works through the failure modes a systematic evaluation of healthcare GUI agents actually found, and ends with the one workflow, prior authorization, where all five of them occur together.
How HealthAdminBench measured agent performance and the reliability gap it revealed
HealthAdminBench (arXiv 2604.09937, April 2026) is the first systematic evaluation of computer-use agents across realistic healthcare GUI environments. Four environments: an EHR, two payer portals, and a fax system, running 135 expert-defined tasks across prior authorization, appeals and denials management, and durable medical equipment order processing. That produced 1,698 discrete evaluation points, enough to trust the pattern instead of writing it off as noise.
The headline number is stark. The best end-to-end task success rate among tested agents, Claude Opus 4.6 CUA, came in at 36.3%. The best subtask success rate, from GPT-5.4 CUA, hit 82.8%. An agent can get four out of five individual steps right and still fail to produce a usable outcome in nearly two out of every three full tasks it attempts.
That gap should put to rest a comparison that keeps getting made anyway. A Mount Sinai systematic review (Gorenshtein, Omar et al., medRxiv 2025) found agent systems built on LLMs beating baseline language models by a median of 53 percentage points on discrete clinical tasks. Those tasks were structured and API-accessible, nothing like the screen-by-screen improvisation a GUI agent does inside a payer portal. Subtask accuracy is not operational reliability. Administrative workflows are exactly where that substitution falls apart, because they demand coordination across systems that were never built to talk to each other, and no amount of per-step precision papers over that.
Failure mode 1: the subtask illusion, agents that complete steps but not tasks
An agent can execute every discrete action correctly and still never reach a valid end state. The task looks like it's progressing. The outcome is zero.
A prior authorization form gets filled out completely and accurately, then submitted to the wrong payer portal. An appeals packet gets assembled correctly, then abandoned when a session timeout interrupts the submission step. Claim fields get populated without error, but the agent stops short of confirming receipt, and the claim sits in limbo until a denial letter arrives weeks later.
Multi-step administrative work is especially exposed to this, since prior authorization, appeals, and DME processing all depend on handoffs across payer portals, external systems, and document exchange. Every handoff is a spot where a technically successful subtask produces zero downstream value. Research on general-purpose GUI agents has found the same pattern: failures in multi-step tasks trace back to brittle perception-action grounding and a failure to recover once something goes wrong, because the agent has no reliable way to tell that its last action didn't produce the screen state it expected.
Benchmarks built around structured API calls, like MedAgentBench's work on FHIR endpoints, don't predict how an agent behaves inside a real GUI. Organizations evaluating vendors against that kind of benchmark are measuring the wrong thing, then wondering why the deployment doesn't look anything like the demo.
A deeper problem predates any agent and produces this one: healthcare administration got digitized without getting modernized. Paper became PDFs. Broken processes got a login screen bolted onto them. If an agent is dropped into a workflow that was already flawed, it doesn't fix the flaw. It just runs it faster, with less friction to catch anyone's attention that something's wrong. The tell to watch for is plain enough: if an agent's activity log shows high task-completion counts but the revenue numbers aren't moving, check the subtask illusion first, before blaming the payer or the staff.
Failure mode 2: misread UI states and perceptual grounding errors
An agent can also fail by seeing the screen wrong. It clicks a submit button that's disabled. It reads a loading spinner as a finished state. It treats an error modal as a confirmation.
Healthcare GUI environments make this worse than general enterprise software does, for a few concrete reasons. Payer portals differ wildly in design from one insurer to the next, and they change without warning: a relabeled field, a reordered step, a new required attachment. EHR screens run dense and field-heavy, so a misidentified dropdown or an overlapping modal produces a wrong entry that reads as correct in the agent's own log. Fax-based document intake adds another layer of noise on top, since low-fidelity scans degrade whatever text-recognition pipeline the agent depends on to parse what it's looking at.
The same pattern applies here. Brittle perception-action grounding, the fragile link between what the agent sees and what it does about it, breaks down the moment visual conditions shift even slightly, and that is a recognized failure pattern in multimodal agents operating across real GUI environments. Because payer rules and interfaces change on their own schedule, an agent trained against last month's UI will misread this month's screen with total confidence, making perceptual errors a recurring rather than incidental risk.
That confidence is the dangerous part. Perceptual grounding errors throw no error message. The agent logs the action as successful because, as far as it can tell, it was. The mistake becomes visible only later, when a denial letter arrives or a claim comes back unprocessable, and by then the trail back to the actual cause has gone cold. Agents need monitoring of the environment itself, not just a log of actions taken, because the two can drift apart without either one raising a flag.
Failure mode 3: context loss across multi-step and multi-system workflows
Some failures come from losing the thread of the whole task. They're about losing the thread of the whole task.
An agent crosses a system boundary, resumes after an interruption, or re-enters a long-running workflow, and proceeds as though earlier steps are done when they aren't, or as though earlier context still holds when it's since changed. A single prior authorization can touch an EHR, a payer portal, a fax queue, and an internal tracking system, each running its own session and its own login, each keeping its own version of where things stand. When session timeouts interrupt a task mid-flow, an agent re-authenticating may resume at the wrong stage without detecting the discontinuity. Multi-day tasks compound the problem: a PA that needs supporting documentation pulled the following day requires the agent to hold context across a gap, and persistent memory across sessions remains a widely noted weak point in deployed agent architectures.
Agent design usually breaks into four components: planning, action, reflection, and memory. Context loss lives almost entirely in that last one. HealthAdminBench's design reflects this directly, since coordination across payer portals, external systems, and document exchange is what prior benchmarks never modeled, and it's a large part of why end-to-end success rates land so far below subtask rates.
A related variant appears when an agent marks a task done after finishing its own steps in one system, without ever confirming the downstream system received and accepted the handoff. That's a stalled handoff, not completion, and it's a context failure dressed up as one. A PA that stalls invisibly between two systems ends up functionally identical to a PA that was never submitted, except now it costs staff time just to notice, because the agent's own log insists something happened.
Failure mode 4: hallucination and data fidelity errors that propagate into clinical records
Then there's the failure mode with the highest stakes: an agent generating content that's fabricated but plausible, and writing it into a record where it doesn't just sit, it compounds.
Asgari et al. (2025) put a number on the hallucination rate: 1.47% across a large set of clinician-annotated sentences of LLM-generated medical text. Under 2% sounds close to negligible, until it gets multiplied against the sheer volume of documentation an agent can produce, at which point sub-2% turns into thousands of erroneous entries. Once inaccurate information lands in a patient record, it doesn't stay contained. It shapes how the next provider reads the chart, and a fabricated detail, left unchallenged across a few encounters, has a way of calcifying into accepted clinical history. The longer it sits, the harder it gets to spot.
The MEDIC framework (Kanithi et al., 2024) highlights that knowing the right answer and writing the right note aren't the same skill, and an agent can have one without the other. Separately, research has found that LLMs can fail to flag pharmaceuticals that have been withdrawn or banned, a narrow but serious category of error with obvious patient safety consequences.
Better prompting doesn't fix any of this. If an agent generates an erroneous note, the provider who signs off on it typically still carries the legal responsibility for what's in the chart, which makes this a governance problem as much as a technical one. Human review of agent-generated documentation is mandatory. It's the only thing standing between an agent's mistake and a patient's permanent record.
Failure mode 5: automating the wrong metric in revenue cycle workflows
An agent can do everything it was configured to do, correctly, and still make things worse, if it was configured to chase the wrong number.
MedEvolve's research names the problem directly: automation measured by tasks completed rather than payment outcomes achieved can scale administrative waste instead of eliminating it. That scaling is not hypothetical. Survey data from HFMA and FinThrive found that 63% of health systems had already integrated AI-powered revenue cycle automation. Only 15% reported a positive return on investment. That gap turns on what organizations told the AI to optimize for, not on whether they deployed it at all.
Payers aren't standing still either. Kodiak Solutions reported that insurers denied more claims on clinical grounds than the year before, contributing to a 25% jump in net revenue leakage at hospitals. Survey data from the NAIC found 84% of large health insurers already using AI for operational purposes, with 44% applying it to claims adjudication and 56% to utilization management. Payer-side AI is speeding up the volume and precision of denials. An agent tuned to maximize submission volume, running into a payer system tuned to maximize denial accuracy, loses that exchange more often than a human biller who knew, from years of instinct, which claims weren't worth submitting yet.
The counter-example matters just as much as the warning. Mercyhealth automated high-volume claims processing across ten specialties and saw a 5.1% revenue increase alongside a 50% reduction in accounts receivable days. What separates that result from the failure pattern is the metric being optimized. It's that the metric being optimized was financial outcome, not raw activity. AI-based claim-scrubbing tools have cut denial rates by as much as 35%, but only when they're configured against denial reduction as the target, not submission throughput. Pick the metric before deployment: agents need workflow-specific KPIs agreed on up front.
How prior authorization workflows concentrate every failure mode at once
Prior authorization is where all five failure modes stop being separate case studies and start happening together, sometimes in the same afternoon.
The stakes alone justify the attention. According to the KFF Health Tracking Poll, 29% of physicians report having seen a PA lead to a serious adverse event, 78% say patients sometimes or often abandon recommended treatment because of PA barriers, and 58% of insured adults needing specialized care hit a delay or denial tied to prior authorization. This isn't an administrative nuisance sitting off to the side of clinical care. It sits directly in the path of it.
Run the failure modes through PA one at a time. The subtask illusion appears when an agent fills out a form correctly but submits it against outdated criteria, or stalls silently when a CAPTCHA interrupts the flow, leaving the log looking active while the payer never receives anything at all. Perceptual grounding errors happen because payer portals change their interfaces without notice, relabeling a field or adding a new attachment requirement, and a static agent reads the new screen as though it's still the old one. Context loss appears in the multi-day documentation-gathering steps PA often demands, and again, more damagingly, in the most common PA failure of all: a denial that never gets appealed because the agent never carried that denial forward into a follow-up workflow. Hallucination happens when an agent generates supporting clinical documentation and introduces the exact inaccuracy that gets the request denied, and missing or incorrect data accounts for a substantial share of claim denials industry-wide. The wrong-metric failure hits when an agent optimized for submission volume runs into a payer system using AI to batch-deny claims at scale, in at least one disclosed case fast enough for a medical director to deny fifty claims in ten seconds, about 1.2 seconds per case. Pushing submission counts higher against that kind of adversary leaves approval rates flat or worse, not better.
None of this argues against automating PA. An automated transaction can cost as little as five cents against more than $10 in labor for the manual equivalent, and that efficiency case holds up on its own. It holds only when the agent produces valid authorizations rather than activity that resembles them. Activity versus outcome is the thread running through every failure mode here, and it's the one question that has to get asked before any of these systems get anywhere near a patient's care.