DEV Community: Vishal Kumar

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

Vishal Kumar — Tue, 28 Jul 2026 08:52:25 +0000

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.

Healthcare automation ROI starts with the manual baseline

Vishal Kumar — Mon, 27 Jul 2026 09:17:58 +0000

Engineers often model the future system and under-model the system that already exists. In healthcare ops, that is a mistake. The manual baseline is the cost your automation project has to beat.

Four current inputs belong in the model:

Denial exposure. Experian Health's 2025 survey found 41% of providers reported that at least 10% of claims are denied. Treat that as a survey benchmark, not a universal rate.
Human rework. Experian reports that 90% of denials are reworked with at least some human review. If the automation architecture cannot show where human review begins and ends, it is not really modeling the current workflow.
Prior-auth load. AMA reports roughly 40 prior authorizations per physician per week and about 13 hours of physician/staff time. That is a measurable labor baseline.
Adoption gap. 67% of providers believe AI can improve the claims process, but only 14% report using AI to reduce denials. The opportunity is not hypothetical; the implementation gap is real.
The architecture consequence is important: optimize for prevention + evidence + human gating, not just throughput. Catch missing information before submission, ground actions in payer or policy material, explain why the system took an action, and route ambiguous cases to people.

CMS is also pushing the workflow toward structured electronic prior authorization. Operational requirements started in 2026, while major Prior Authorization API requirements generally begin January 1, 2027. That makes interoperability and auditability part of the architecture, not an afterthought.

That's what we mean by governed AI agents at IntelliBooks Studio --- more at intellibooks.ai/overview.

The cost of doing nothing is a real line item — model it before you build

Vishal Kumar — Sat, 25 Jul 2026 09:16:56 +0000

Engineers underweight the cost of the status quo because it's not in any ticket. But if you're scoping automation for healthcare ops, the do-nothing baseline is the number your ROI is measured against — so model it honestly first.

Four inputs worth putting in the model:

Rework unit cost. MGMA pegs reworking a denied claim at $25–$181. That's your per-event cost of a false-negative in the pipeline.
Abandonment rate. ~65% of denials are never reworked — so a big share of "recoverable" revenue is silently dropped. Your system's real job is often to prevent the denial, not just flag it.
Denial base rate. ~12% first-pass denials, trending up. This is the volume your automation has to move.
Manual load. ~13 physician-hours/week on prior auth (AMA). Labor you're spending whether or not it's on a dashboard.

The design consequence: optimize for prevention with a human gate, not just throughput. Catch eligibility/auth problems before submission, ground each decision in the payer policy, and make the whole path auditable — otherwise you've automated the denials too. That's what we mean by governed AI agents at IntelliBooks Studio — more at intellibooks.ai/overview.

Anatomy of a governed prior-auth agent: six steps, one human gate

Vishal Kumar — Thu, 23 Jul 2026 10:25:57 +0000

Prior authorization is a great test case for agent design because getting it wrong has real consequences. Most 2026 vendors optimize for "no staff intervention." Here's the architecture I'd defend instead — six stages, with the human gate as a first-class step, not a callback.

Intake + PHI redaction on the input path. Redaction runs before prompt assembly, not after generation. Order matters: identifiers never reach the model.
Retrieval of live policy. Pull chart facts and the payer's current medical-necessity criteria at request time. Cached criteria go stale; read the live policy.
Match + draft with enforced citations. Each drafted element is grounded to the exact criterion it satisfies. No citation → flag the gap, don't paper over it.
Durable human interrupt before submission. The gate halts the run and waits for an approver — it's a state the workflow can't skip, not a "review later" flag. This is the step the category quietly drops.
Submit + track against SLA. File to the payer, track status against the CMS seven-day decision window (Jan 2026).
Append-only audit log. request → retrieval → draft → citations → approver → timestamp, exportable. "Who authorized this and why" must be answerable.

The design principle: autonomy is per-action metadata, and the consequential action (submission) is gated. That's what we mean by governed AI agents at IntelliBooks Studio — more at intellibooks.ai/overview.

7 red flags an engineer should catch in a healthcare AI vendor

Vishal Kumar — Wed, 22 Jul 2026 09:01:01 +0000

You're the one who has to make it safe in production, so you're also the one who should catch these. Seven technical red flags in a healthcare AI pitch.

"Fully autonomous" as the headline — no per-action gating means no way to hold irreversible operations. Autonomy should be per-action metadata, not a global mode.
"HIPAA-certified" — a claim tell. Ask which controls map to which safeguard; a real answer is specific, not a badge.
No citation on decisions — if outputs aren't grounded with a source enforced at the output layer, you can't defend them.
HITL as a callback, not a durable interrupt — "review later" doesn't halt the action; a real gate does.
PHI handling described "at the end" — redaction belongs on the input path, before prompt assembly. Order matters.
No exportable audit log — request → retrieval → decision → approver, append-only, or "who decided this" is unanswerable.
Unsourced benchmarks — round-number automation claims with no methodology are noise.

Flip all seven and you have the spec for a governed healthcare AI agent. That's what we build at IntelliBooks Studio — more at intellibooks.ai/overview.

Eight healthcare AI myths engineers should stop repeating

Vishal Kumar — Tue, 21 Jul 2026 09:36:22 +0000

Myth: Bigger models solve everything

Reality:
Architecture usually matters more than model size.

Myth: Human review is inefficient

Reality:
Approval gates exist only for high-risk workflows.

Myth: AI doesn't need evidence

Reality:
Production systems retrieve source documents and attach citations whenever possible.

Myth: Governance slows deployment

Reality:
Governance reduces operational risk and accelerates enterprise adoption.

Myth: Chatbot = AI Agent

Reality:
Agents orchestrate workflows, tool use, retrieval, and escalation.

Healthcare AI becomes valuable when engineering prioritizes reliability over impressive demos.

Learn more about governed healthcare AI:
https://www.intellibooks.io/

Overview:
https://intellibooks.ai/overview

A healthcare-AI-agent glossary for engineers (what these terms mean in the code)

Vishal Kumar — Sat, 18 Jul 2026 08:39:48 +0000

Half of "agentic AI" vocabulary is marketing. Here's what the terms map to in an actual implementation.

Agent — a workflow with tool-use, retrieval, and a control plane, not a single prompt. It reads and acts; a chatbot just returns text.
Human-in-the-loop — a durable interrupt in the workflow: consequential actions halt, route to an approver, and resume after sign-off.
RAG / grounding — retrieval feeds the prompt and a citation is attached per claim; a decision without a source is rejected at the output layer.
PHI redaction — a detect/redact step on the input path, before prompt assembly — order matters, not the checkbox.
Audit trail — append-only event log: request → retrieval → decision → citation → approver; exportable.
Governed AI — the sum of the above enforced as invariants, not a wrapper.
On-prem / air-gapped — same governance model, deployed inside the customer network.
Escalation / confidence threshold — below-bar results short-circuit to needs_human with a structured reason.

Names aside, the architecture is the point. We ship it as governed healthcare AI agents at IntelliBooks Studio — more at intellibooks.ai/overview.

A 10-point technical checklist for evaluating a healthcare AI agent

Vishal Kumar — Fri, 17 Jul 2026 08:55:20 +0000

If you're the engineer who has to make a healthcare AI agent safe in production, marketing checklists are useless. Here's the technical version — what to actually verify.

Citations enforced at the output layer — a decision without a grounded source is rejected before it ships, not "usually cited."
Human gate as a durable interrupt — consequential actions halt and resume after sign-off, not a fire-and-forget callback.
PHI redaction on the input path — before the prompt is built; verify the order, not the checkbox.
Append-only audit log — request → retrieval → decision → citation → approver; exportable.
On-prem / air-gapped deploy — the governance model stays identical off-cloud.
Confidence-thresholded escalation — below-bar routes to needs_human with a structured reason.
Per-action autonomy metadata — reversible auto-executes; irreversible/compliance-bearing forces the gate.
Honest claims — "HIPAA-ready," and they can tell you exactly which controls map to which safeguard.
Real tool-use across systems — not a chat wrapper; it reads and acts via a control plane (MCP-style).
Inspect + override — you can see the reasoning, edit behavior, and kill a workflow.

One through five are non-negotiable. We build governed healthcare AI agents to this spec at IntelliBooks Studio — more at intellibooks.ai/overview.

A governed AI agent's shift, as seen from the execution logs

Vishal Kumar — Thu, 16 Jul 2026 08:45:38 +0000

Forget the marketing. Here's what a governed healthcare agent's day looks like from the workflow engine's point of view — the states it moves through, and where the gates are.

09:02 — ingest + draft. New task enters the queue. RAG over the encounter docs + coding guidance produces a proposed decision with a citation per line item. State: drafted. No side effects yet — the agent can't submit.

09:04 — human gate. The action is tagged irreversible/compliance-bearing, so the workflow halts at a durable interrupt and routes to a named approver (a certified coder). State: awaiting_attestation. It resumes only after sign-off.

midday — throughput. Routine tasks flow through the same path; the citation requirement is enforced at the output layer, so anything without a grounded source is rejected before it reaches the gate.

14:15 — escalation. Below-confidence or ambiguous cases short-circuit to needs_human with a structured note on what's unclear — not a silent best-guess.

17:00 — audit. Every transition is written append-only: input seen → retrieval → proposal → approver → outcome. "Who decided this" is a query.

The architecture is the product here. We ship it as governed healthcare AI agents at IntelliBooks Studio — more at intellibooks.ai/overview.

Healthcare AI agents: an engineer's FAQ (PHI, audit trails, and the human gate)

Vishal Kumar — Wed, 15 Jul 2026 08:50:10 +0000

The healthcare AI questions that matter to engineers aren't about the model — they're about everything wrapped around it. A quick FAQ from building this.

How do you keep PHI out of the model? Detection + redaction on the input path, before the prompt is built. The model reasons over de-identified text; raw identifiers never reach it.

How do you make decisions auditable? An append-only log capturing request → retrieval → decision → citation → sign-off. Every decision carries the policy clause it matched; "why did it decide this" is a query.

Where does the human fit? As a durable interrupt, not a callback. Consequential or below-confidence actions halt and route to a named approver; the workflow resumes after sign-off.

Autonomous vs governed? Tag each tool action with a blast radius. Reversible → auto-execute. Irreversible/compliance-bearing → force the gate. Autonomy is per-action metadata, not a global setting.

On-prem? The pipeline runs air-gapped when data can't leave the network; the control plane (MCP-style) and governance model stay identical.

The pattern: governance is the architecture, not a wrapper. We ship it as governed healthcare AI agents at IntelliBooks Studio — more at intellibooks.ai/overview.

Autonomous vs. governed AI agents: what actually changes in the build

Vishal Kumar — Tue, 14 Jul 2026 09:22:35 +0000

"Autonomous vs. governed" isn't a marketing distinction — it's a different architecture. Here's what actually changes when you build for governance instead of full autonomy.

1. Actions carry a blast radius. In a governed build, every tool/action is tagged reversible vs. irreversible. Autonomous execution is allowed only for the reversible set; the rest hit a gate. In a fully autonomous build, there's no such tag — everything just runs.

2. The human gate is a durable interrupt, not a callback. The workflow halts on a consequential action and can resume after approval (survives restarts). That means persisting agent state, not holding it in memory.

3. Decisions must carry a citation. Governed output is rejected at the output layer if it lacks a retrieved source. Autonomy without grounding will happily emit confident, unsourced decisions — fine for a summary, not for a claim.

4. The audit log is append-only and is a feature, not debug output. request → retrieval → decision → citation → approver. "Who decided this" becomes a query.

5. PHI redaction sits on the input path, before the prompt is built, in both — but a governed system treats it as a hard precondition, not a config toggle.

Net: governance is mostly plumbing (state, gates, provenance, logging), and it's the plumbing that makes an agent deployable in a regulated setting. We ship governed healthcare AI agents at IntelliBooks Studio — more at intellibooks.ai/overview.

How we decide which agent actions need a human gate (a 3-question rubric we encode in the workflow)

Vishal Kumar — Mon, 13 Jul 2026 09:00:37 +0000

"Add a human-in-the-loop" is easy to say and vague to implement. Which actions get a gate? We encode the decision as three checks per agent action, evaluated before the action runs.

1. Reversibility. Tag each action with a blast radius. Cheap-to-undo → can auto-execute. Irreversible or compliance-bearing (a submitted code, a denial) → force the gate. This is metadata on the tool, not a vibe.

2. Groundedness. The action must carry a citation from retrieval (policy clause, guideline). No source → the agent can't act, it can only draft. We enforce this at the output layer: a decision without a cited source is rejected before it reaches the gate.

3. Accountability. Every gated action resolves to a named approver (by role/queue), and the approval is written to an append-only audit log with the citation and the input it saw. "Who decided this" is a query, not a guess.

Implementation-wise: the gate is a durable interrupt (the workflow halts and can resume), PHI is redacted on the input path before any of this runs, and the whole thing sits behind a control plane (MCP-style) so the same rubric applies across agents.

The rubric is the point — it turns "be careful" into three testable conditions. We ship it as governed healthcare AI agents at IntelliBooks Studio — more at intellibooks.ai/overview.