Blog

Resources

FDA
Regulatory
AI
Machine Learning
SaMD
Medical device
Strategy

ARPA-H ADVOCATE: The First Bid for FDA-Authorized Autonomous Clinical AI and What It Means for Developers

ARPA-H ADVOCATE: the first bid for FDA-authorized autonomous clinical AI

September 9, 2026
cosm logo
Cosm
ARPA-H ADVOCATE program architecture
Share this

On September 9, 2026, ARPA-H announced the performer teams for ADVOCATE (Agentic AI-EnableD CardioVascular CAre TransfOrmation), a four-year, $62.7 million program whose stated goal is to build the world's first reliable, FDA-authorized clinical agentic AI system: a patient-facing agent that manages heart failure patients between visits, acts autonomously where it can, and escalates to the human care team when it should. ARPA-H is committing up to $33.7 million in the first year. The program is run by Haider Warraich, M.D., a practicing cardiologist, and FDA is engaged throughout the program lifecycle to develop the regulatory framework for what ARPA-H calls a new class of patient-facing clinical AI.

For regulatory, quality, and product leads working on AI-enabled devices, this is the most concrete signal to date of how FDA and a federal funder expect autonomous clinical AI to be built, supervised, and evidenced. Below is what the announcement says and what it means if you are developing something in this category.

What ADVOCATE is

The program is organized around three technical areas that, taken together, describe a complete system for putting an autonomous agent into clinical care and keeping it safe once it is there.

TA1: Patient-facing clinical AI agent

Three teams will each build an agentic system that supports heart failure patients between visits and escalates to the clinical team as a new autonomous member of that team:

Atman Health: an evidence-based clinical decision engine paired with large language models and a voice-first interface, where the system adapts its diagnostic questions to each patient in real time.

Tempus AI: an extension of the existing Olivia patient health app, adding continuous monitoring and deeper clinical analysis when a meaningful change in the patient's status is detected.

Updoc: a system whose conversational intelligence is deliberately separated from clinical authority by a clinician-built rules layer that validates every proposed action against approved protocols before it executes.

The TA1 teams must submit a first-of-its-kind FDA authorization package for their product within 24 months of contract award.

TA2: Supervisory AI agent

Stanford University will build a disease-agnostic supervisory system that continuously monitors the TA1 agents after deployment, detecting unsafe recommendations and out-of-distribution behavior in real time. The design is a three-stage, compute-escalating pipeline (outlier filtering, rule-based screening, then a deep-research auditing agent) that produces inspectable per-claim rationales. ARPA-H describes this as an ongoing assurance layer that FDA, health systems, patients, and clinicians can trust.

TA3: Scalable implementation in health systems

Two health-system-anchored teams will design and execute the real-world deployment strategy, with a focus on rural and underserved communities:

Duke University: a multi-site validation platform across five health systems and rural sites on both Epic and Cerner/Oracle EHRs, with the American Heart Association's national reach.

Kaiser Permanente: enterprise-scale deployment across 21 medical centers and more than 260 clinics, embedding the agents into Epic workflows for heart failure patients and producing reusable deployment blueprints via shadow-mode deployments and pragmatic randomized clinical trials.

ARPA-H has also contracted the Johns Hopkins University Applied Physics Laboratory as external evaluation partner, providing independent assessment of technical performance and clinical outcomes. Performers across the technical areas will jointly develop technical interfaces, safety benchmarks, evaluation protocols, interoperability requirements, and reimbursement pathways.

Why FDA's involvement is the headline

The clinical ambition is real, but for device developers the important sentence in the announcement is that ADVOCATE will engage FDA throughout the program lifecycle to develop the regulatory framework for this class of patient-facing clinical AI. Rick Abramson, M.D., Director of FDA's Digital Health Center of Excellence, is quoted describing patient-facing agentic AI as one of the most consequential frontiers in digital health, noting that getting the framework right requires close, iterative collaboration between developers, clinicians, and FDA, and pointing specifically to continuous, ongoing monitoring of autonomous clinical AI for both safety and effectiveness.

Read that alongside the program structure and a pattern emerges. The framework being worked out here is not just "how do we review one agent." It is "what does a premarket package plus a postmarket assurance system look like for software that acts on patients without a clinician in the loop on every decision." That is a question FDA's existing AI/ML guidance (the AI-enabled device software functions guidance, the PCCP guidance, and the 2026 updates to the CDS and General Wellness guidances) does not fully answer, and ADVOCATE is the vehicle for answering it in public, on a 24-month clock.

The announcement does not state which premarket pathway TA1 teams are expected to use. Our read: an agent that autonomously adjusts management for heart failure patients is well outside the CDS exemption in section 520(o)(1)(E) of the FD&C Act and has no obvious predicate, so a De Novo or PMA-type pathway is the realistic assumption. That is our assessment, not something ARPA-H or FDA has said.

What this means for developers

Even if you are nowhere near ARPA-H funding, the choices this program made are choices FDA reviewers will now have seen and discussed. They are worth building into your own strategy.

Separate conversation from clinical authority. The Updoc architecture is the clearest example: the LLM handles dialogue, and a deterministic, clinician-authored rules layer decides whether any proposed action is allowed to execute. Atman's evidence-based decision engine plays a similar role. If your product uses an LLM anywhere near a clinical action, expect to explain where the model's authority ends and where the validated logic begins, and to test that boundary explicitly. This is also the cleanest way to structure your ISO 14971 risk controls and your IEC 62304 software architecture so that the highest-risk items are traceable to deterministic components.

Plan for a supervisory assurance layer. ADVOCATE funded a separate, disease-agnostic monitor whose job is to catch unsafe recommendations and out-of-distribution behavior after deployment and to explain, per claim, why it flagged something. FDA's own language about continuous monitoring suggests this is heading toward an expectation, not a differentiator. Developers should think now about what their postmarket monitoring architecture is, what it detects, how fast, and how the output feeds complaint handling, CAPA, and any predetermined change control plan.

Treat shadow mode and pragmatic trials as the evidence bar for autonomy. The TA3 teams are deploying in shadow mode first (the agent runs, but its outputs are not acted on) and then in pragmatic randomized trials inside working health systems. If you are proposing autonomous behavior, a retrospective performance study on a curated dataset is unlikely to carry the claim. Build your clinical evidence plan around real workflows, real EHRs, and a comparator that reflects standard care.

Define escalation as a device function. Every TA1 description includes escalation to the human care team. When an agent hands off, on what triggers, with what information, and what happens if the human does not respond are all safety-critical design inputs. They belong in your requirements, your usability engineering file (IEC 62366-1), and your risk file, not in a workflow diagram in the appendix.

Interoperability is a regulatory question, not just an IT one. The program is deliberately validating on both Epic and Cerner/Oracle and is developing shared interoperability requirements. If your agent reads from and writes to the EHR, the integration boundary is part of the device and part of the hazard analysis.

Go to FDA early. The TA1 teams have 24 months and FDA at the table. You have neither by default. A Pre-Submission that lays out your intended use, your autonomy boundary, your supervisory approach, and your evidence plan is the practical way to get FDA's current thinking on a category that is being defined right now.

Caveats

This is a program launch announcement, not a guidance document. The performer descriptions are one paragraph each and the regulatory framework it references does not yet exist in written form. Program outcomes, including whether any team reaches authorization within the 24-month window, are uncertain. The statements above about pathway and about FDA expectations are Cosm's assessment based on the announcement and on existing guidance, and are subject to change as the program and FDA's thinking develop.

The bigger picture

FDA has spent the last several years building the scaffolding for adaptive and generative AI devices: lifecycle management, predetermined change control plans, transparency principles, and a Digital Health Advisory Committee that opened with generative AI. ADVOCATE is the first funded, FDA-engaged effort to take that scaffolding to a fully autonomous, patient-facing agent with a submission deadline attached. Whatever framework emerges will shape how autonomous SaMD is reviewed well beyond cardiology. For background on how FDA's lifecycle model already applies to AI-enabled devices, see our earlier post on the AI Lifecycle Management model, and for structuring risk controls around AI-specific hazards, see risk management for AI/ML medical devices.

The full ARPA-H announcement is available here, and the program page here.

How Cosm Can Help

Cosm helps developers of AI/ML-enabled and autonomous SaMD define a regulatory strategy that FDA can engage with: intended-use and autonomy-boundary definition, Pre-Submission preparation, predetermined change control plans, AI-specific risk management under ISO 14971, IEC 62304 and IEC 62366-1 documentation, and clinical evidence planning. If you are building an agentic or autonomous clinical AI and want to assess your regulatory position before your next FDA interaction, contact us or visit cosmhq.com.

Disclaimer - https://www.cosmhq.com/disclaimer