Multi-Tab and Multi-Window Workflow Coordination in Clinical Agents

A prior authorization request rarely fails because one step is hard. It fails because the step that works happens on a different system than the step before it, and nothing connects the two automatically. Most administrative software marketed as "automation" handles exactly one such step. A practice administrator still has to carry the output of one tool into the input of the next by hand. This piece examines the gap between automating a task and automating a workflow, the reason so many automation tools stall out at the first system boundary they meet.

Why single-task automation falls short of end-to-end administrative work

Consider what a single prior authorization actually requires. Someone has to pull clinical data out of the EHR, check the payer's specific coverage rules for that procedure, upload supporting documentation to the payer's portal, and then write the resulting authorization number back into the patient's chart. That is four systems, four logins, and four separate interfaces, each built by a different vendor with no shared session between them. A tool that fills out a payer portal form well has solved one of those four problems. It has not solved prior authorization.

This is why so many practices end up with a drawer full of point solutions that each do one thing competently and still leave staff doing the connective work: copying a value out of one screen, pasting it into another, remembering which step comes next. An agent that can only operate one system at a time runs into the same wall. At every boundary between systems, it either has to stop and hand the task to a person, erasing most of the time savings that justified building it, or it has to guess at what the next system needs without knowing it, producing silent failures that are often worse than no automation.

What matters here is architectural: automating an isolated task, filling a form, reading a lab value off a screen, is a problem that has largely been solved. Keeping workflow state coherent while an agent operates across every system a complete task actually touches is a different and much harder problem, and it separates an administrative workflow that gets done end to end from one that stalls partway.

How computer-use agents perceive and act across multiple interfaces

Knowing how a computer-use agent operates software in the first place helps explain why that harder problem is hard. These agents work through a loop: they look at the screen, decide what to do next, and act, then look again. That loop runs on pixels and screen elements rather than on an API call, and that single fact lets an agent operate a payer portal, a legacy web form, or an EHR screen the same way a staff member would, without requiring the software behind it to expose a programmatic interface.

There are a few different ways an agent can "see" what's on screen, and each comes with real tradeoffs. One approach reads a raw screenshot and works out coordinates to click, which works on virtually any interface but costs a model call for every single step and can miss small or crowded targets. Another approach reads the underlying structure of a web page, the DOM or the accessibility tree, and targets elements by reference. That method is fast and precise inside a browser, but it goes blind the moment it hits a canvas element or an application that doesn't expose accessibility data, which describes a fair number of legacy healthcare systems. A third approach has the model write code that drives the interface directly, so a task that repeats, like checking the same payer portal every morning, can run as a script that fixes itself when something changes slightly, instead of re-examining the whole screen from scratch every time.

What matters for healthcare settings specifically is that none of these approaches requires the target software to expose an API. The agent reads the payer portal, the legacy intake form, or the EHR screen exactly as a human staff member would, by looking at what's there and issuing clicks and keystrokes. That's a meaningful fact given how much of the healthcare software stack, especially on the payer side, was never built with integration in mind.

But the loop described here is sequential by design: look, decide, act, look again, one step after another. A single agent running that loop can move through one interface at a time, start to finish. The moment a real workflow needs two systems touched at once, or needs information fetched in window one before window two can proceed, that simple loop runs out of road. Something else has to manage the relationship between what's happening in each window.

What multi-window coordination means at the architecture level

That "something else" is not a feature bolted onto a single agent. It calls for a different architecture altogether, one where multiple specialized agents share state with each other, sequence their actions against one another, and avoid stepping on the same resource at the same time.

Picture five agents that all need to touch the same patient record, the same payer portal, and the same revenue cycle system, each with its own partial view of where the workflow currently stands. Without a coordination layer managing that, the result is chaos: duplicated work, conflicting writes, and steps run out of order.

Three specific problems have to be solved for coordination to work. The first is state: each agent needs to know what the others have already retrieved, written, or changed, without re-reading the entire patient record from the top every time it takes another action. Picture the prior authorization example again. Once one agent has confirmed from the payer's coverage rules that authorization is required, a second agent gathering clinical documentation shouldn't need to re-derive that fact on its own. It should simply know it.

Some steps in a workflow are strictly ordered. Clinical documentation has to be gathered before the payer's questionnaire can be filled out with cited evidence, and an authorization number has to be written back to the order before a claim referencing it can be submitted. Other steps don't depend on each other. An eligibility check and the assembly of supporting documentation can run side by side with no conflict. An architecture that treats every step as if it must happen in strict sequence wastes time; one that treats everything as parallel risks acting on information that doesn't exist yet.

A third, easily overlooked problem is concurrent access to the same system. Payer portals frequently enforce session limits or multi-factor authentication in ways that make it technically or even legally fraught for two agents to log into the same portal account at the same time. The coordination layer has to manage which credentials go where and when, injecting the right login at the right moment and isolating sessions so that one agent's work doesn't knock another agent out mid-task.

Each of these credential relationships is its own small negotiation, and healthcare systems multiply the number of them. EHR actions attributed to a specific clinician call for SMART user-context authorization. System-level batch jobs, the kind that run without a person attached to them, use SMART Backend Services instead. Payer portals, many of which still have no modern API at all, require a vaulted login: an encrypted username, password, and MFA credential injected at the moment the agent needs it. Clearinghouses add per-payer client credentials or mutual TLS on top of that. Each of these is a distinct authorization domain, and a multi-agent system has to manage all of them at once, not sequentially and not as an afterthought.

This network of specialized agents, one reading EHR data, another checking payer rules, another updating the scheduling system, coordinating with each other in real time, is what converts a single perceive-plan-act loop into something that can finish an entire administrative workflow. Getting that coordination layer right, the state tracking, the sequencing logic, and the credential management working together, is what separates an agent that can start a prior authorization from one that can actually finish it.

Long-horizon task performance: measurement and current agent standing

None of this is theoretical. Benchmarks built specifically to test long-horizon, multi-step computer use show that holding coherent state across hundreds of sequential actions is a distinct skill, separate from how accurately an agent performs any single isolated task, and it remains genuinely difficult.

The OSWorld 2.0 benchmark is a useful illustration of why. It includes tasks long enough that a skilled human needs many hours to finish one, and agents working the same tasks need an average of more than 300 tool calls to get through them. That makes OSWorld 2.0 a far closer stand-in for something like a prior authorization or a denial appeal than any benchmark built around short, single-step tasks. It also draws a distinction that matters a great deal in a clinical setting: a partial score, measuring how much of the task got done correctly, against a binary score, measuring whether the task fully succeeded or not. An agent that completes nearly all of a prior authorization and then fails at the final submission step has produced nothing of value to the practice waiting on that authorization, no matter how good its partial score looks.

Benchmarking in this space is also moving toward tests built around the specific demands of healthcare. PatientAgentBench, for instance, offers a framework built specifically for evaluating patient-facing health AI agents. That direction says something important on its own: generic accuracy on a generic task is not a reliable stand-in for whether an agent can be trusted with a healthcare workflow, and the field is starting to build evaluation methods that reflect that.

Taken together, these benchmarks confirm what the architecture argument predicts. Sustaining state and sequencing correctly across a long, multi-system task is a harder and still-unsettled problem, and it is precisely the problem that separates agents capable of finishing administrative work from agents that can only perform well on a short demo.

Operational gains from multi-system coordination

Prior authorization and denial management show this coordination capability most visibly in practice, because both workflows require pulling data from the EHR, the payer portal, and supporting documentation systems in a specific order, and both carry real costs, financial and clinical, when that order breaks down.

Prior authorization remains the clearest example of why. The workflow starts with detecting a trigger inside the EHR, a new order or a scheduled procedure, then checking whether that procedure requires authorization under the payer's specific coverage rules, then gathering clinical documentation from the chart, filling out payer-specific questionnaires with the right evidence cited, drafting a narrative establishing medical necessity, and finally writing the resulting authorization number back into the original order. None of those systems share a login or a data model with each other. Several companies are building specifically in this space on the provider side, including Latent Health, Develop Health, and Silna Health. Epic has also built coordination directly into its own platform: Penny, Epic's tool for billing and denial avoidance, handles automated coding, denial appeal letters, and medical necessity appeals from inside the EHR itself, which shows that the coordination layer doesn't have to sit outside the record system. It can be built into it.

Denial management follows a similar shape. An agent handling a denial has to classify why the claim was denied, pull the chart documentation needed to support an appeal, draft the appeal packet itself, and track the follow-up, and every one of those steps touches a different system under a real deadline, since payers impose fixed windows for appeals. Orchestration across the EHR, the payer, and scheduling systems also makes other use cases work without a human re-triggering each step individually: checking eligibility before a visit is scheduled, or having a denial classification automatically generate an appeal draft.

The pattern across all of these cases is consistent. The value isn't created by any single agent action in isolation. It comes from the handoff, data pulled from one system becoming the direct input for an action on the next system, with no person in between to copy a value, paste it somewhere else, and hope nothing got mistyped along the way.

Authentication and session management as the practical bottleneck in multi-window workflows

The biggest obstacle to making any of this work in practice has less to do with how capable the underlying model is and more to do with something far less glamorous: credentials. Every system in a healthcare administrative workflow authenticates differently, and managing all of those credentials securely while an agent is actually running is where a lot of otherwise sound deployments run into trouble.

Session isolation is one concrete version of the problem. Payer portals often allow only a single active session, or a small, fixed number of them, so two agents trying to log into the same portal account at the same time can knock each other's sessions offline. That means the coordination layer has to deliberately serialize access to that one portal, even in cases where every other part of the workflow could otherwise run in parallel without any conflict.

The regulatory landscape adds another layer to this. Through the 2026-2027 period, agents are operating in what amounts to a dual-stack environment. CMS-regulated payers are required to have FHIR-based prior authorization APIs in place by January 1, 2027, but until that deadline, and in many cases after it for payers outside that mandate, agents still need to handle legacy channels alongside whatever FHIR access exists: X12 transactions, direct portal logins, and in some cases still fax. Keeping state, sequencing actions correctly, and managing access across systems that were never built to work together is the daily operating reality for any agent trying to finish, rather than merely start, a piece of administrative healthcare work.