What a governed claims agent actually automates (and what it deliberately doesn't)

A useful way to scope a claims-automation build: separate the repetitive-but-safe work from the judgment work, and design the interrupt boundary between them explicitly.

What the agent owns:

• Claim-status polling. Continuous, high-volume, zero judgment required. (Smilist's public case runs 3,000+/day this way.)
• Eligibility re-verification. Check coverage against the current plan before submission, not after a denial.
• First-pass appeal drafting. Grounded to the specific denial reason and the payer's policy language — draft only, not send.

What stays behind a human gate:

• Anything genuinely ambiguous — conflicting policy language, an edge-case denial reason, a low-confidence match.
• The actual submission of an appeal or a request — the agent drafts, a person approves.

The industry context: 80% of health systems were piloting or implementing gen AI for RCM work in 2025 (up from 58% two years prior), and 46% already have it live. The design lesson from that adoption curve: the wins are in the repetitive 80%, not in removing the human from the loop. That's the architecture behind governed AI agents at IntelliBooks Studio — more at intellibooks.ai/overview.