AI Agents vs RPA vs Rules: What to Automate in a Practice
The three things people mean by “automation”
When a vendor says their product automates eligibility checks, they could mean any of three fundamentally different technologies. Knowing which one you’re buying tells you how it will fail, and failure mode is the thing that costs you money.
Deterministic rules are the plumbing already inside most practice management systems: send a text 48 hours before the visit; flag any claim missing a referring provider NPI; auto-post an ERA when the adjustment code matches a known contract term. Rules are cheap, auditable, and boring. They do exactly what you wrote, forever, and they do nothing sensible when the input doesn’t match the pattern.
RPA (robotic process automation) is a script driving a user interface — logging into a payer portal, tabbing through fields, copying a benefit response into a note. RPA exists because payer portals and older systems lack usable APIs. It works until the portal redesigns a page, adds a CAPTCHA, or changes a dropdown, at which point the bot silently does the wrong thing or stops.
AI agents use a language model to interpret unstructured input (a faxed referral, a voicemail transcript, a denial remark), decide what to do, and then call tools to actually do it — look up a patient, draft a message, open a task, post a note. The difference from a chatbot is that an agent takes actions across several steps rather than answering a question. The tradeoff is that agents are probabilistic, and their failures are the least visible of the three. A low-quality fax with a smudged member ID doesn’t produce an error — it produces a confidently wrong extraction that looks exactly like a correct one. A skill edited by one person to fix an edge case can quietly change output for every other case, and nobody notices for weeks because nothing broke. And an agent with write access that resolves “Maria Garcia” to the wrong chart will take a real action on a real patient’s record. Rules fail loudly; agents fail plausibly.
Sorting real practice jobs into the three buckets
Appointment reminder cadences. Recall lists by procedure date. Claim edits with fixed logic (missing modifier, invalid POS, taxonomy mismatch). Balance statements at day 30/60/90. Waitlist eligibility filters. These have finite inputs and one right answer. An LLM adds cost, latency, and a new failure mode for zero benefit.
Reading an inbound fax referral and extracting patient, insurance, referring provider, and reason for visit. Triaging a denial batch by grouping remark codes into likely root causes. Turning a patient voicemail into a structured callback task. Assembling a prior-auth packet from scattered chart sections. All of these start with messy, variable human artifacts.
Most practices should be running a hybrid. A realistic denial workflow, for example: deterministic scrubbing rules catch the mechanical errors before submission, an agent reads the remaining denials and drafts a triage summary with a proposed next action, and a biller approves or overrides in a worklist. We walked through the underlying billing mechanics in automating medical claims and billing; the point here is that the AI layer belongs on the interpretation step, not the arithmetic.
There is no single best AI for a practice — only best-for-the-job
Asking which AI is best for a medical practice is like asking which piece of equipment is best. The honest answer is job-by-job: an ambient scribe for documentation, a phone agent or an answering service for after-hours calls, a claims tool for revenue cycle, a general assistant like Claude or ChatGPT for administrative drafting inside a HIPAA-appropriate configuration. Our job-by-job buyer’s map breaks that down. It’s worth being precise about categories, too: ChatGPT is a general-purpose large language model — a text-in, text-out generative system — not a healthcare product, and whether you can put protected health information into it depends entirely on the plan, the contract, and whether a business associate agreement is in place.
The EHR vendors are entering this market directly. Epic has publicly described an agent platform and Cosmos-powered predictive features, and trade press including Fierce Healthcare has covered the expansion; verify the current scope against Epic’s own announcements rather than secondhand summaries, since roadmaps move quarterly. For independent practices, native agents are mostly good news — they inherit your existing access controls — but it also means you should stop buying point tools for anything your EHR roadmap covers in the next twelve months. Ask your vendor directly and in writing.
The autonomy threshold nobody actually agrees on
You’ll see a “30% rule” cited in AI discussions. It is not a standard from any regulator or standards body, and it gets used to mean at least three different things depending on who’s writing. Treat it as folklore, not guidance.
The useful version is one you set yourself: pick the share of volume an agent may complete without human review, start it low, and raise it only on evidence from your own audit log. Practically, the agent proposes and a person disposes for the first several weeks, you sample its output, and you promote specific categories of task to full autonomy — not the agent as a whole. The American Medical Association’s commentary that AI is moving fast and health systems need guardrails applies just as much at five providers as at five hundred.
Promote tasks to autonomy, not agents. “The agent is reliable” is not a finding. A finding looks like: across N reviewed eligibility summaries (say, your first 200), we found zero coverage errors — with the number and the review method written down.
Where MCP and skills change the build-vs-buy math
Two building blocks are worth understanding as of 2026. MCP (Model Context Protocol) is an open standard for giving an AI assistant governed access to a specific system’s data and tools — a controlled doorway between an assistant and your scheduling or practice-management data, with the ability to scope exactly which records and actions are exposed. Skills are packaged, reusable instructions that teach an assistant to perform one job the same way every time — a referral packet skill, a denial triage skill — so output doesn’t drift with whoever is prompting.
The combination makes a custom build plausible at mid-size scale: instead of a six-month integration project, you expose a minimum-necessary slice of data through a custom MCP server under a business associate agreement and write skills against it. We cover the mechanics in connecting Claude to your EHR via MCP.
But owning a server is owning software forever. Someone has to version it, re-review access scopes when staff or vendors change, and fix it when your EHR alters a field, a schema, or an API version — which happens on the vendor’s schedule, not yours. Before you build, name the person who is on call when the server fails at 8:40am on a Monday, and budget their time as a permanent line item, not a launch cost. If your EHR already ships an eligibility agent that works, building your own is a hobby, not a project. Custom earns its cost when the workflow is specific to your specialty, spans systems no vendor connects, or sits on your differentiated revenue.
Modeling the payoff without inventing a number
Skip vendor ROI headlines and build your own:
-
Count the volume
Pull one month of actual counts: eligibility checks run, denials worked, referrals received, reschedule calls handled. -
Time one instance honestly
Stopwatch three of each, end to end, including the portal login and the interruption. Use the median, not the best case. -
Apply your loaded rate
Wage plus taxes plus benefits, per hour, for the person actually doing it. -
Estimate the deflection share
What fraction can plausibly complete without a human touch? Be conservative — assume review stays on everything for phase one. -
Add the revenue side
Recovered hours only pay off if they’re reallocated: more claims worked, more open slots filled, faster patient callbacks. Name where the hours go, or the savings are theoretical. -
Subtract the failure cost
Assume some error rate and price the cleanup: a wrongly posted ERA takes reconciliation time, a missed prior auth can mean a written-off visit, a mis-triaged denial can age past a payer’s filing limit. Estimated errors × hours to fix × rate, plus any revenue you’d expect not to recover.
Subtract subscription cost, build cost amortized, oversight hours, and expected rework. If what’s left is small, the correct answer may be a better rule in software you already own — or nothing at all.
Which roles this actually changes
The roles most exposed are pure transcription between systems: retyping a fax into an intake form, re-keying benefit data, turning voicemails into tasks. The roles that get more valuable require judgment, relationship, and accountability — the biller who knows which payer rep to call, the office manager who reads a schedule and knows which patient will no-show, the clinical staff whose work agents are not permitted to perform. Every agent deployment also creates supervision work: someone audits output, tunes skills, and owns exceptions.
If you want a starting point rather than a shopping list, run an automation audit on a single workflow: sort each step into rule, RPA, or agent, write down what happens when each one fails, and ship the smallest version a human still checks.
Not sure where to start?
Get a free automation audit: we map your scheduling, intake, insurance, billing, and patient communication and show you what's worth automating — before you spend a dollar.
Get a free automation audit