AI agents for healthcare denials and appeals: working the 835 without inventing a diagnosis

A denied claim is money a provider already earned and now has to fight to keep. Roughly one in ten claims is denied on first submission across the industry, the large majority of those denials are preventable or overturnable, and the process of overturning one is a slow, manual, deeply unglamorous grind: read the remittance, decode why the payer said no, decide whether to correct-and-resubmit or appeal, assemble the clinical evidence, write the letter, submit it, and then chase the payer for weeks to find out what happened. Teams routinely quote appeal cycles measured in dozens of days per claim. Multiply that by the denial volume of a mid-sized health system and you have a revenue-cycle department drowning, and a pile of small-dollar denials nobody ever works because the labor cost exceeds the recovery.

This is a near-perfect problem for an AI agent, and a dangerous one to get wrong. It’s high-volume, rules-heavy, and text-generating. Exactly what agents are good at. It’s also clinical and regulated, where a fabricated fact isn’t an embarrassing hallucination, it’s a compliance incident and possibly fraud. The difference between an agent that recovers real revenue and one that gets a health system in trouble is entirely in the architecture: what the agent is allowed to read, what it’s allowed to assert, and where a human still signs. This is the post-service counterpart to our piece on prior authorization agents: same discipline, later in the revenue cycle, higher stakes on getting the facts exactly right.

Denials are a different problem than prior auth

It’s worth being precise, because the two get lumped together and they aren’t the same workflow. Prior authorization happens before the service, the fight to get a procedure approved. Denial management happens after the claim is adjudicated: the payer has already said no to a service that in many cases was already delivered, and the job is to recover payment. The data is different (a submitted claim and a remittance, not a pre-service request), the clock is different (appeal deadlines, timely-filing limits), and the failure mode is different: here you’re arguing with a payer’s stated reason, in that payer’s own coded language.

That coded language is the thing the agent absolutely must read correctly. When a payer processes a claim, it returns an 835 Electronic Remittance Advice: the EDI transaction that says, line by line, what was paid, denied, adjusted, or shifted to patient responsibility. The “why” lives in two code sets: Claim Adjustment Reason Codes (CARC) state why a service was adjudicated differently than billed, and Remittance Advice Remark Codes (RARC) add supplemental explanation. Each adjustment also carries a group code (CO (contractual obligation), PR (patient responsibility), OA (other adjustment), or PI (payer initiated)) that changes who owes the balance and whether it’s even appealable. A CO-97 (service bundled/included in another service) is a coding argument; a PR-1 (deductible) isn’t a denial to appeal at all, it’s patient responsibility. An agent that can’t tell those apart will “appeal” things that were never denied and miss the ones worth fighting.

The agent’s job is not to decide whether a claim should have been paid. That’s a clinical and contractual judgment. Its job is to read the 835 correctly, sort denials by why-and-how-recoverable, draft the response grounded in real records, and put a defensible package in front of a human. Triage and draft, not adjudicate.

One current detail worth building for: the industry runs on the CAQH CORE 360 rule governing which CARC / RARC / group-code combinations are valid together on an 835, and CMS has a refreshed combination set taking effect in late 2026. Whatever maps codes to denial categories in your system has to track that combinations list rather than a hard-coded lookup someone typed in two years ago, because a mapping that’s silently stale will misroute denials the day the rule changes.

The architecture: unify the data, then let the agent triage and draft

The pattern that works separates three things cleanly (the data foundation, the agent’s reasoning and drafting, and the human control points) and it maps directly onto Salesforce with Health Cloud, Data 360, and Agentforce.

1. Unify the claim, the remittance, and the record. The agent cannot reason about a denial it can only half-see. It needs the submitted 837 claim, the 835 remittance with its CARC/RARC codes, the patient’s coverage and eligibility, the relevant clinical documentation, and the payer’s own medical-policy rules, and in most health systems those live in four different systems. This is a data-unification problem before it’s an AI problem, and it’s exactly what Data 360 identity resolution and a unified profile are for: one governed view that ties the claim to the encounter to the patient to the coverage. Skip this and you get an agent that drafts appeals against a partial picture, which is worse than no agent. As we argue in data quality for AI, the grounding data is the product; the model is a commodity on top of it.

2. Classify and prioritize. Give the agent one scoped, deterministic job first: parse the 835, translate the CARC/RARC/group-code combination into a denial category (eligibility, missing information, coding/bundling, medical necessity, timely filing, non-covered), and rank the resulting worklist by recovery likelihood and dollar impact. This is where the economics change: the agent surfaces the small-dollar denials that were never worth manual triage and stops humans from opening claims that were never appealable in the first place. Keep this classification as a governed action, not a vibe: it’s a decision with money attached, and it should behave the same way every time, the way we describe for deterministic control in agents.

3. Draft the response (grounded, never invented. For an appealable denial, the agent assembles the response: the correct appeal or reconsideration path for that payer, the argument tied to the specific denial reason, and) this is the whole ballgame: a citation to the actual clinical documentation and payer policy that supports payment. The single hard rule: every clinical assertion in the draft must trace to a real document in the record. The agent quotes and cites; it does not characterize a diagnosis, a procedure, or a lab value that isn’t there. Grounding the drafting on retrieved records rather than the model’s parametric memory is what keeps it safe: the same grounding and retrieval discipline that separates a trustworthy service agent from a confident liar, applied where a fabrication is a regulatory event.

4. Follow up without a human on hold. A large slice of denial-management labor is pure status-chasing: calling the payer, navigating the IVR, asking “what’s the status of claim X.” Increasingly this is handled by AI voice agents that place the call, work through the phone tree, capture the answer, and log it with a full transcript and audit trail, or by automated 276/277 claim-status EDI checks where the payer supports them. It’s the same voice-agent capability pointed at the payer instead of the patient, and it reclaims hours of staff time that were never clinical judgment to begin with.

Where the human still signs, and why that’s not a limitation

The instinct with a working agent is to push for full automation and measure success by how few humans touch a claim. In denials, that instinct is a liability. Draw the human control points deliberately:

• Medical-necessity appeals need clinical sign-off. When a denial turns on whether care was medically necessary, the argument is a clinical judgment. The agent assembles the evidence and drafts the letter; a clinician or a qualified appeals specialist reviews and owns the assertion. This is textbook human-in-the-loop: the agent does the assembly, the human makes the call that carries clinical and legal weight.
• Submission is a gated action, not an autonomous one. Filing an appeal with a payer is an outbound, hard-to-reverse action against a deadline. It runs behind an explicit approval, the way any consequential agent action should, the agent prepares, a human releases.
• PHI never leaves the trust boundary. This is healthcare data under HIPAA. The agent operates inside a governed boundary where prompts and responses are subject to masking, logging, and access control, the Einstein Trust Layer discipline is non-negotiable here, not a nice-to-have. An agent that ships PHI to an ungoverned endpoint is a breach, full stop.
• Everything is audited. Every classification, every draft, every citation, every submission is logged. When a payer, a compliance officer, or an auditor asks why a claim was appealed and on what basis, the answer is a record, not a shrug.

Framing these as constraints misreads them. They’re what makes the agent deployable in a regulated setting at all, the reason it can touch real claims instead of living forever in a sandbox demo.

What to do

Start with the data, not the model. If you can’t put the 837, the 835, the coverage, and the clinical documentation into one governed view, you don’t have a denials agent, you have a text generator guessing at a partial record, so unify first. Then give the agent the narrowest valuable job: parse the remittance, classify the denial by its CARC/RARC/group-code combination, and rank the worklist, and prove that classification is correct and stable before you let it draft anything. Add drafting only with a hard grounding rule that every clinical claim traces to a real document, and keep submission and medical-necessity judgment behind a human. Point voice and EDI automation at the status-chasing that was never clinical work in the first place. Do it in that order and the agent recovers revenue the health system already earned, including the long tail of small-dollar denials that were previously left on the floor, without ever putting a fabricated fact in front of a payer.

Understanding the basics

How is a denials-management agent different from a prior-authorization agent?

Prior authorization is a pre-service workflow, getting a procedure approved before it happens. Denial management is post-service: a claim has already been adjudicated and denied, often for care already delivered, and the job is to recover the payment. A denials agent works from a submitted 837 claim and the payer’s 835 remittance, reasons about the specific CARC/RARC denial codes, and drafts a correction or appeal against a deadline. The data, the clock, and the argument are all different, even though both live in the healthcare revenue cycle and demand the same no-fabrication discipline.

What data does an AI denials agent need to be accurate?

It needs a unified view tying together the submitted 837 claim, the 835 remittance advice with its CARC/RARC and group codes, the patient’s coverage and eligibility, the relevant clinical documentation, and the payer’s medical-policy rules. In most health systems those sit in separate systems, so the first step is data unification: a governed profile (via Data 360 identity resolution and Health Cloud) that connects the claim to the encounter to the patient. Without it, the agent drafts appeals against a partial picture. Every clinical assertion the agent makes in an appeal must trace to a real document in that record, never to the model’s memory.

Can an AI agent submit an appeal to a payer on its own?

It shouldn’t submit autonomously. Filing an appeal is an outbound, hard-to-reverse action against a deadline, and medical-necessity appeals turn on clinical judgment, so the safe pattern is human-in-the-loop: the agent classifies the denial, assembles the evidence, and drafts the appeal grounded in real documentation, then a clinician or qualified appeals specialist reviews, owns the clinical assertion, and releases the submission. Automated voice and EDI status checks can chase claim status without a human, because that work carries no clinical judgment, but the appeal decision and submission stay gated.

---

Watching denials pile up faster than your team can work them, and wary of pointing AI at claims data? Talk to us, building a grounded, auditable denials agent that recovers revenue without ever inventing a clinical fact is exactly the work we do.