The front office, the exam room, the billing department — agents are being built for all three. Here’s what they can realistically do today, where they break, and why they all depend on the same missing layer.

Ramani Narayan · May 2026 · 6 min read

Every AI vendor in healthcare right now is pitching an agent. Front office agents that handle scheduling and intake. Clinical agents that prep the physician before the encounter. Back-office agents that chase prior authorizations and submit claims. The demos are compelling. The category is real.

But most practices that deploy these agents will hit a wall. Not because the agents are poorly built, but because the agents are built on incomplete data, they cannot reconcile across systems and cannot be trusted enough to act without constant human correction.

The agent problem in healthcare is not an AI problem. It is a data foundation problem. And until the industry is honest about that, the gap between what agents promise and what they deliver will keep widening. Healthcare is in a unique position among all the verticals where AI can have an impact. On the one hand, it generates more data than any other vertical (30% of all data), and on the other hand it uses less of that data than any other vertical (3%, yes, three percent).

This post looks at what agents are doing today across three areas — front office, clinical, and back office — what they need to work reliably, and what breaks when that data foundation isn’t there.

The agents are not the hard part. Every major AI lab can build an agent. The hard part is giving the agent something trustworthy to act on.

One Pattern Across Three Problems

Front office, clinical, and back-office workflows are very different from each other for a variety of reasons. Scheduling is not the same problem as prior authorization. A clinical pre-visit brief is not the same as a claim submission. However, when you strip each one down, the failure mode is identical: the agent needs to know something true about the patient — their insurance, their history, their current medications, their diagnosis codes. The challenge is that the data agents need to access is fragmented, inconsistently coded, and split across systems that were never designed to talk to each other.

A scheduling agent that can’t verify eligibility in real time books appointments that can’t be honored, or makes patients go through unnecessary hoops. A clinical agent working from one EHR’s view misses the relevant hospitalization or an ER visit in another system blind-siding the clinician. A prior authorization agent reads the wrong diagnosis code or misses sending historical procedures needed for prior authorization approval because they happened elsewhere also wastes more time than it saves.

The common prerequisite is integrated, normalized, ontology-grounded patient data — the layer that sits beneath every agent and determines whether it operates reliably or just confidently.

1 · Front Office What Agents Are Doing in Scheduling and Access

Front office agents are the most mature in deployment today. The tasks — eligibility verification, self-scheduling, referral coordination, inbound call handling, waitlist management — are well-defined, rule-heavy, and don’t require clinical judgment. That makes them well suited to automation.

Vendors operating here include Luma Health and Klara (patient communication and self-scheduling), Artera (automated outreach and referral coordination), and Hyro (AI voice agents for inbound call handling). On the eligibility side, Waystar and Availity have layered AI-assisted verification on top of their existing clearinghouse infrastructure. These are production deployments, not pilots — practices using them are processing hundreds of eligibility checks and scheduling interactions daily without staff involvement.

In practices using agent-assisted scheduling today, the real gains are specific. Eligibility checks that used to require a staff member to log into a payer portal now run automatically at booking. Self-scheduling links send patients directly to available slots matched to their insurance and visit type. Inbound call volume drops when a voice agent can handle appointment changes, prescription refill routing, and address updates without a human on the line.

These are real efficiency gains. They are also narrow. The front office agent succeeds when the task is bounded: check this patient against this payer, book into this slot, route this call type. It fails — or creates downstream work — when the underlying data is wrong.

WHERE IT BREAKS TODAY: An eligibility agent that confirms coverage at booking cannot catch a mid-month insurance change. A self-scheduling agent that doesn’t know a referral requires pre-authorization books an appointment the patient can’t use. A registration agent working from an outdated problem list sends the wrong intake forms. In each case, the agent executes correctly on bad data — and the correction lands on a human.

The fix is a data layer that maintains a current, reconciled view of the patient’s insurance, demographics, and referral status that provides the right context for the front office agent.

2 · Clinical What Agents Are Doing at the Point of Care

Clinical agents are the most discussed and the least understood category. The marketing language — “clinical copilot,” “ambient intelligence,” “AI scribe” — covers a wide range of capabilities and conflating them creates unrealistic expectations.

What clinical agents reliably do today: ambient documentation. The scribe category — Abridge, Nuance DAX, Suki, and Nabla among others — listens to the physician-patient conversation and drafts a structured clinical note. Abridge is live across UPMC and several large health systems; Nuance DAX is embedded in Epic workflows at scale; Suki has deployments in independent and specialty practices. The task is bounded — capture the encounter, structure the note — and when the model is well-tuned to clinical vocabulary, the output is genuinely useful. Physicians using these tools consistently report 30–45 minutes of documentation time returned per day.

What clinical agents do less reliably: pre-visit preparation and HIE-backed context. An agent that synthesizes a patient’s longitudinal record before the encounter depending on the patient and the provider — pulling together notes, labs, specialist correspondence, and problem lists from multiple systems into a coherent pre-visit brief — is the right idea.. But that capability only works when the underlying record is normalized and deduplicated across systems. An agent working from a single EHR’s data prepares a brief from a partial chart.

What clinical agents do not reliably do yet: proactive clinical reasoning. Flagging the missed follow-up, detecting the drug interaction across prescriptions written by different providers, surfacing the symptom pattern that has appeared three times in nursing notes. These capabilities are being built. They are not broadly deployed at the reliability threshold clinical care requires.

WHERE IT BREAKS TODAY: A clinical agent that drafts a note from the encounter cannot catch what the physician didn’t know to discuss — because it had no pre-visit context. A pre-visit brief built from one EHR misses the specialist note, the external hospitalization, the prescription filled at the out-of-network pharmacy. The agent produces output that looks complete. The physician trusts it. The gap is invisible until it isn’t.

The distinction that matters here is between documentation agents and context agents. Documentation agents — scribes — work well on single-encounter data. Context agents require cross-system, normalized, ontology-grounded records to do anything more than restate what the primary EHR already shows. That’s the infrastructure gap RISA was built to close.

3 · Back Office What Agents Are Doing in Revenue Cycle

Back-office automation has the longest deployment history of the three. Rules-based RPA — robotic process automation — has been running in revenue cycle for years: claim submission, remittance posting, denial queuing. What AI agents add is the ability to handle variability. RPA breaks when a payer changes a form field. An AI agent adapts.

The active vendors here include Cohere Health and Rhyme (prior authorization), Fathom and Nym Health (AI-assisted medical coding), and Waystar’s denial management suite. On the CDI side, Artifact Health and Solventum (formerly 3M Health Information Systems) use AI to flag under-coded HCC conditions during and after the encounter. These are not fringe deployments — Fathom processes millions of clinical notes for coding annually, and Waystar handles a significant share of US claim volume. The category is mature enough that the question is no longer whether AI can do this work but whether it is reading data clean enough to do it accurately.

In practice, revenue cycle agents today handle three tasks with reasonable reliability. Prior authorization submission: the agent reads the clinical record, identifies the relevant diagnosis and procedure codes, populates the payer’s portal, and submits. Coding and CDI support: the agent reviews the documented encounter and flags missing or under-coded diagnoses — particularly HCC conditions that affect risk adjustment. Denial management: the agent reads the denial reason, identifies the correction, and queues the appeal with the relevant supporting documentation attached.

The efficiency gains are real. Prior auth that used to take a staff member twenty minutes per case now takes two, with the agent handling the portal navigation and documentation assembly. Coding reviews that caught 60% of under-coded HCC conditions now catch closer to 85% when the agent has access to the full structured record.

WHERE IT BREAKS TODAY: A prior auth agent that reads the wrong diagnosis code from an unreconciled problem list submits a request that gets denied — and now someone must fix it manually. A coding agent that can’t see the specialist’s documentation misses the HCC condition the specialist identified. A denial management agent working from incomplete records builds an appeal on partial evidence. In each case, the agent’s output is only as accurate as the record it read from.

Revenue cycle agents are the clearest demonstration of data dependency. The output — a prior auth, a claim, an appeal — is a formal document with real financial and compliance consequences. An agent that gets the diagnosis code wrong because it reads from a fragmented record does not save time. It creates a denial that costs more to fix than it would have cost to do manually. This problem is compounded by the fact that the prior authorization requirements often depend on payor specific policies in addition to the specific plan, clinical procedure involved in addition to patient history.

Where Agents Work Today vs. Where They Need Better Foundation

What All Three Have in Common

Every reliable agent deployment in the table above — the ones in the left column — operates on bounded, well-structured data. Eligibility verification works when the insurance data is current. Ambient scribing works when the task is single-encounter documentation. Prior auth submission works when the diagnosis codes are accurate.

Everything in the right column — the capabilities that need better foundation — requires something the agent doesn’t have by default: a normalized, deduplicated, ontology-grounded view of the patient’s complete record across every system where it lives.

This is the Integrate → Annotate → Expose stack. Integrate pulls data from EHRs, HIEs, labs, imaging, and patient-generated sources into a single provenance-tracked FHIR R4 record. Annotate grounds every clinical concept in SNOMED-CT, LOINC, RxNorm, and ICD — so the agent can query by drug class, body system, and indication rather than matching raw text strings. Expose wraps each use case in an agentic harness with tool-calling, guardrails, FHIR grounding, and write-back — so the agent’s actions are auditable, not just plausible.

Vendors competing in each of the three agent categories — front office, clinical, back-office — are building on top of this stack, whether they’ve built it themselves or rely on a platform to provide it. The ones who skipped it have products that demo cleanly on curated data and break in production on real records.

Assistants compete on the application. The platform powers all of them on the layer beneath. That’s not an infrastructure pitch. It’s a description of how agents actually work — or don’t.

What Honest Agent Deployment Looks Like Right Now

Practices deploying agents in 2026 should hold two things in tension. The first: these tools are real, the efficiency gains are measurable, and the practices that adopt them thoughtfully will have a structural advantage over those that wait. The second: most agent vendors are pitching capabilities that are six to eighteen months ahead of what their current data foundation can reliably support.

Honest deployment means starting with the tasks that are bounded and supporting data is clean. Eligibility checks. Ambient scribing. Remittance posting. Getting that right, measuring them rigorously, and building the data foundation that extends the agent’s reach into harder tasks.

It also means asking the right questions before signing a contract:

• What systems does your agent read from? If the answer is one EHR, the agent has a partial record. Every claim about cross-system capability should come with a specific list of integrations and a live demonstration of real patient data.
• How does your agent handle a diagnosis code that appears differently across two systems? The answer should describe ontology mapping, not text matching. If the vendor doesn’t know what SNOMED or LOINC is, the agent is string-matching against raw data.
• What is your audit trail? Every agentic action — every submission, every note draft, every scheduling decision — should be traceable to the source record it reads from. “The agent did it” is not an acceptable audit trail in a regulated environment.
• What happens when the agent is wrong? The failure mode matters as much as the success rate. An agent that fails silently — submitting a prior auth with the wrong code, generating a note missing a key detail — is more dangerous than one that fails loudly and routes to a human.

The Honest View of Where This Goes

AI agents will become standard infrastructure in healthcare practices over the next three years. Not because the technology is perfect — it is not — but because of the efficiency gap between practices that use them, and practices that don’t will become too wide to ignore.

The front office gains are already visible in practices that have deployed them carefully. The clinical documentation gains are real and measurable. The revenue cycle gains are significant when the underlying data is clean.

What will determine which practices capture those gains and which spend two years chasing failures is not which agent vendor they choose. It is whether the data foundation beneath the agent — integrated, normalized, ontology-grounded — is built before the agent is deployed or after the first production failure makes it unavoidable.

ThetaRho builds that foundation. RISA is the proof that it works on athenahealth — for the independent and specialty practices that need the same capability as the largest health systems but can’t wait for a three-year enterprise integration project to get there.

This post is part of The Clarity Protocol, ThetaRho’s ongoing series on AI, clinical workflow, and healthcare data. The next piece closes the RISA framework with Act — what it means for an AI system to move from assembling context to acting, the guardrails that make agentic action safe in a clinical setting, and why the Expose layer is where the platform argument becomes most consequential.

ThetaRho (thetarho.ai) builds clinical AI infrastructure for healthcare organizations. RISA is our clinical intelligence platform — HIPAA-compliant, AICPA SOC certified, and live on the athenahealth Marketplace.