Analysis / 001

Evaluation and Validation of Agentic Processes in Healthcare: What I Look for Before Anyone Calls It Safe

A physician-executive perspective on how to evaluate agentic AI in hospitals, with a practical framework for validation, governance, and failure detection before deployment. The real test is not whether the agent looks smart in a demo, but whether it survives clinical workflow, safety review, and regulatory scrutiny.

Author

Dr. Sina Bari, MD

Physician-Technologist | Healthcare AI Executive | Stanford Medicine

Published

October 10, 2026

Reviewed

October 10, 2026

Last Tuesday, I watched a vendor demo an agent that could draft a discharge summary, queue follow-up labs, and message a care coordinator in under a minute. The room liked the speed. I kept thinking about the patient who would be discharged at 6:40 p.m. with a new anticoagulant, a borderline creatinine, and three handoffs still unfinished. One wrong tool call in that chain is not a software quirk. It becomes a night call, a readmission, or a complaint that starts with, “Nobody told me.”

The right way to evaluate agentic healthcare AI is to test the full clinical process, not isolated model outputs. A hospital should validate task completion, escalation behavior, security boundaries, and workflow fit under realistic conditions, then map the system to FDA pathways such as 510(k), De Novo, or PMA, with NIST AI RMF and WHO governance layered on top for internal risk control.

In practice, the most important question is whether the agent behaves safely when the chart is messy, the clinician disagrees, the patient is ambiguous, and the workflow is interrupted. That is where most failures hide.

I used to think the cleanest benchmark was the most useful benchmark. Then I spent enough time around clinical deployments to see how brittle that idea is. A model can ace a scripted conversation and still fail the moment the medication list is duplicated, the triage note is incomplete, or a nurse asks it to repeat itself in plain language. Now I think evaluation has to look like care delivery, including interruption, disagreement, uncertainty, and the consequences of delay.

That matters because the literature is moving fast, but the evidence base is still young. Zhao et al. in npj Artificial Intelligence (2026) surveyed healthcare AI agents and highlighted the same bottlenecks I see in practice: hallucination, accountability ambiguity, bias, and weak validation. A broader 2026 review in the Journal of Biomedical Informatics described a field concentrated in 2022 to 2026, which is another way of saying we are still early enough to make expensive mistakes if we confuse demonstration with deployment.

What I actually validate first

When I evaluate an agentic process in healthcare, I start with the process boundary. What can the agent do, what can it not do, and where does it have authority to act? If it can place orders, message staff, retrieve chart data, or trigger patient outreach, I want those powers typed, limited, logged, and reversible. A useful architecture is closer to typed planning and governed execution than to a free-running assistant. POLARIS, a 2026 framework for governed execution, is relevant here because healthcare teams need explicit constraints, not clever improvisation.

I also want to know who owns the failure when the agent is wrong. In hospital governance meetings, I ask a blunt question: if this tool sends the wrong instruction at 2:10 a.m., who is on the hook, clinically and operationally? CLEAR-AI, the clinician-led governance framework described in 2026, points in the right direction by treating governance as a bedside issue, not a procurement appendix. That aligns with the way I practice. I do not treat AI approval as an IT checkbox. I treat it as a patient-safety decision.

For the regulatory layer, the vocabulary matters. In the United States, I think in FDA terms first, then governance terms. If the system is software as a medical device, the pathway may be 510(k), De Novo, or PMA depending on novelty and risk. FDA’s AI-enabled device materials emphasize lifecycle management and predetermined change control plans, which is exactly where agentic systems get tricky. An agent that changes prompts, tools, or execution behavior after launch can drift in ways a static device never could.

That is why I like the framing in NIST AI RMF and WHO guidance. NIST gives me a way to map, measure, manage, and govern risk. WHO gives me a health-system lens for accountability, fairness, and safety. Neither one replaces regulatory clearance, but both help me decide whether the operational design is mature enough to survive contact with clinicians.

How I test an agent beyond the demo

The demo is the easy part. The hard part is the failure injection. I want the agent tested with ambiguous symptoms, missing labs, contradictory medication lists, and a patient who changes the story halfway through. I want to see what happens when the patient says, “No, that is not what I meant,” because that is daily life in medicine.

One benchmark that points in the right direction is HealthAgentBench, which reported 54 tasks across 7 categories and only about 42 percent success for the strongest cost-effective agent in the reported results. That number is sobering for anyone who assumes an agent that can talk fluently can also complete multi-step work. Another 2026 evaluation, PatientAgentBench, used six dimensions and over 100 clinician-grounded criteria, with clinician validation showing 79 to 93 percent adjacent agreement with expert raters. I find that kind of design more credible because it treats assessment as a clinical judgment problem, not just a language problem.

Security belongs in the same conversation. Caging the Agents, a 2026 arXiv paper on zero trust architecture for autonomous AI in healthcare, and the survey on trustworthy agentic AI both make a point I agree with: if the agent can call tools, then the tools are part of the attack surface. In a hospital, that means identity boundaries, retrieval boundaries, and write permissions matter as much as model quality. I would not greenlight a system that can pull from a chart and write back without strict per-action authorization, logging, and rollback. I would not deploy a broad autonomous messaging agent for patients without a clinician review queue, because that is how minor hallucinations become real-world harm.

There is also a clinical nuance many engineers miss. A bad recommendation is not always the worst failure. Sometimes the worse failure is a confident non-action. An agent that notices deterioration but never escalates because its threshold is too conservative can look safe in a benchmark and still miss the one patient who needed a human ten minutes sooner. That is a workflow failure, and workflow failures are where hospitals get hurt.

What I would not do

I would not validate an agent only against retrospective chart review and call it ready. Retrospective agreement can hide the exact issues that matter in live care, especially turn-taking, escalation, tool timing, and interrupted cognition. I would not accept a vendor’s claim that “human oversight” exists unless the oversight is operationalized with response times, stop conditions, and named responsibility.

I would also not let a pilot run without defining success metrics before go-live. If the team only measures usage or clinician satisfaction, the tool can look popular while quietly increasing friction, alert fatigue, or documentation drift. In my experience, the best hospital pilots track a small set of concrete outcomes: task completion rate, escalation latency, exception rate, override rate, and downstream chart correction burden. If those numbers are not available, the pilot is still a prototype.

This is where the physician-executive lens helps. I care about model accuracy, but I care more about whether the agent makes the unit faster, safer, and less dependent on heroics. A good hospital agent should reduce the number of things a clinician has to remember at 9 p.m. on a bad shift. If it adds one more pane, one more workflow, and one more inbox, it is noise, not progress.

My practical validation checklist

When I brief a leadership team, I reduce agentic validation to a few questions. Can the system explain what it is doing in language clinicians understand? Can it fail closed? Can we audit every tool action? Can we shut it off without breaking care? Can it be updated without changing its risk profile beyond what we have approved?

Those are not abstract questions. They are the difference between an assistant and an operational dependency. The more autonomy you give a healthcare agent, the more it deserves the same discipline we already apply to devices, order sets, and escalation pathways. No hospital should treat agentic software as a clever experiment once it can influence care.

And the evidence says we are not done. A 2026 systematic review of agentic AI in healthcare screened 443 records and included 25 studies, which tells me the field is still small enough that bad habits can harden quickly. That is why I prefer conservative adoption, explicit governance, and boring documentation over flashy claims. Boring is good when the system touches patients.

Back to that discharge summary

After the demo, I asked the vendor what would happen if the agent drafted a discharge plan for a patient with conflicting home med lists and a late lab result. The answer was technically fluent and operationally thin. That was the moment the room got quiet.

The lesson was not that agentic AI has no place in healthcare. It does. The lesson was that validation has to be about the whole chain, not the prettiest link. If a system can draft, route, summarize, and message, then it needs to be tested where medicine actually lives, in messy handoffs, interrupted attention, and incomplete information. That is the standard I use now, and it is the standard I want hospitals to use before they let an agent anywhere near a patient.

FAQ

How do hospitals validate an agentic AI workflow before go-live?

Hospitals should validate the full workflow, not just the model output. That means testing task completion, escalation behavior, auditability, failure handling, and workflow timing in realistic scenarios with clinician review. A pilot that cannot show those measures is still a demo.

What happens if an AI agent can place orders or send patient messages?

The risk profile changes immediately, because the agent is no longer only generating text. Every action needs typed permissions, logging, rollback, and a named human owner for review and escalation. Without that, the hospital has created a new clinical operator without a credentialing process.

Which regulatory framework matters most for healthcare AI agents?

In the United States, I start with FDA pathway thinking, especially 510(k), De Novo, or PMA depending on the product’s risk and novelty. Then I layer NIST AI RMF for internal risk governance and WHO guidance for health-system accountability and safety. The right framework depends on whether the system is a device, a workflow tool, or both.

What is Dr. Sina Bari's approach to evaluating agentic AI in hospitals?

I look for the failure mode first. If an agent can act, I want to know how it fails, how quickly staff can detect it, how the action is audited, and whether a clinician can reverse it without chaos. If those answers are fuzzy, I am not ready to call the tool safe.

Why do agentic AI benchmarks often miss real clinical risk?

Benchmarks often reward isolated correctness, but hospital work is multi-step, interrupted, and full of ambiguity. A system can score well on scripted tasks and still fail when the chart is messy, the patient contradicts the note, or a nurse needs a clear escalation path. Real validation has to include those messier conditions.