Medical device software development is entering a new phase, one where autonomous AI agents no longer only power a diagnostic feature inside a finished product but increasingly help design, test, document, and monitor the software itself. For device manufacturers, Software as a Medical Device (SaMD) startups, and the investors tracking digital health, this shift is more than a technology trend. It touches the two priorities every regulated software team lives by: speed to clearance and defensible safety. Getting the balance right is becoming a competitive advantage, and getting it wrong is becoming a liability.

The short version is straightforward. AI agents are software systems that can plan, decide, and act toward a goal with limited human prompting. In clinical practice, AI is already supporting faster and more accurate diagnostics, and the agents discussed here extend that same arc. In a regulated device setting they now appear in two distinct places: inside the product that reaches the patient, and inside the engineering process that produces it. Both carry real promise, and both carry real regulatory weight. Understanding the difference is the first step toward using them well.

What counts as medical device software

The Role of AI Agents in Medical Device Software

Before talking about agents, it helps to be precise about what medical device software means, because the label drives everything that follows. Regulators recognize three broad categories. Software as a Medical Device (SaMD) is standalone software with a medical purpose that runs on a general platform such as a phone, tablet, or server, for example a diagnostic image viewer or a clinical decision support tool. Software in a Medical Device (SiMD) is firmware or code embedded in a physical device and required for it to function, such as the control software inside an infusion pump or a continuous glucose monitor. A third category covers the software used to manufacture or maintain a device.

The International Medical Device Regulators Forum and the FDA both define SaMD as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. The key word is purpose. A step counter is not a regulated device; software that analyzes a scan to flag a suspected stroke is. Intended use, not the underlying technology, determines whether a product falls under regulatory oversight, and that principle applies just as firmly to anything driven by AI.

Why the regulatory bar is different

Medical device software is not an app with extra paperwork. It is a safety discipline. A consumer app can ship, break, and be patched next sprint. A regulated device cannot. Every requirement has to trace to a test, every risk to a control, and every release to an auditable record before the software reaches a patient.

That expectation is codified in standards that predate the current AI wave and still govern it. IEC 62304 defines the software lifecycle, classifying software into safety classes A, B, and C by the severity of harm a failure could cause. ISO 14971 governs risk management, requiring a living file that links hazards to controls and to verification evidence. ISO 13485 defines the quality management system, and in 2026 the FDA harmonized the United States framework with ISO 13485 through its Quality Management System Regulation. On top of these sit market-specific rules: the FDA classifies devices as Class I, II, or III and clears them through the 510(k), De Novo, or PMA pathways, while the European Union Medical Device Regulation, through Rule 11, pulls most clinical software into higher risk classes than developers expect.

None of this disappears when a team adds AI. If anything, it intensifies. For software in higher-risk devices, verification, validation, and regulatory documentation often take more effort than writing the code, which is precisely why the arrival of capable AI agents is drawing so much attention. A snapshot of the framework:

Agents inside the device

Regulators have been preparing for AI in the product for years. The FDA published its AI/ML-Based Software as a Medical Device Action Plan in 2021, released its Good Machine Learning Practice guiding principles the same year, issued draft guidance on predetermined change control plans in 2023, and in January 2025 proposed guidance on lifecycle management and marketing submissions for AI-enabled device software functions. The direction is unmistakable: adaptive and increasingly autonomous features are expected, but they must be governed across the full product lifecycle.

The FDA’s overview of artificial intelligence in Software as a Medical Device is the reference point most teams should start from.

Inside the product, agents show up in familiar forms that are quietly growing more capable. Clinical decision support triages cases and surfaces the ones that need attention first. Imaging software highlights a suspected finding for a radiologist to confirm or overrule, the pattern behind recent milestones such as Aidoc’s FDA Breakthrough Device Designation for AI that drafts radiology reports. Remote monitoring watches a stream of vitals and escalates a dangerous trend before a clinician would have caught it manually. What separates these from a consumer chatbot is a single, load-bearing design principle: the agent surfaces a recommendation for human review rather than replacing the clinician. That rule shapes classification, defines validation, and determines how a reviewer reads intended use. Software framed as time-critical, meant to be relied on without independent clinical judgment, faces a far higher regulatory bar than software positioned as support.

Agents inside the engineering process

This is the quieter change, and for delivery timelines it may be the larger one. Because documentation and testing so often outweigh coding in a regulated build, AI agents are starting to carry parts of that load. They can generate test cases directly from requirements, maintain the requirement-to-test traceability matrix that auditors expect, draft sections of the ISO 14971 risk file, and keep specifications and the design history current as the code changes underneath them.

Done well, this compresses the paperwork that historically bottlenecks a submission and shortens the distance between a working build and a clearance-ready one. The important qualifier is done well. IEC 62304 and ISO 14971 still define what finished means, and an agent that produces a draft still needs a qualified engineer to own, review, and sign it. The value is not that the agent replaces judgment; it is that the agent removes the mechanical drag that keeps skilled engineers buried in documentation instead of design. Teams building this capability, whether internally or with an AI agent development partner, are effectively industrializing the evidence trail that clearance depends on, and treating that trail as a product rather than an afterthought.

Governing agents so they help rather than hurt

Three things separate a useful agent from a liability, and all three are about control rather than capability.

First, human oversight has to be designed in, not assumed. Every agent output that touches a clinical decision or a compliance artifact needs a named human owner who is accountable for it. Regulators do not accept that the model produced it as an answer.

Second, the audit trail has to hold. If an agent drafted a test, a requirement, or a risk control, that provenance belongs in the record a notified body or FDA reviewer will eventually read. An evidence trail that cannot explain how it was produced is worse than no automation at all.

Third, cybersecurity expands with every connection. Connected, adaptive software widens the attack surface, and United States law now reflects that. Section 524B of the Federal Food, Drug, and Cosmetic Act requires new device submissions to include a cybersecurity plan and a software bill of materials that lists third-party components, and recent FDA premarket guidance pushes teams to build security in from the first sprint rather than bolting it on before an audit. Agentic components, which may pull in external models or libraries, make a disciplined bill of materials more important, not less.

What it means for buyers and investors

For the executives and investors who follow this space, the practical implications are concrete. A device maker evaluating an AI feature should ask not only what the model can do but how its outputs are governed, logged, and validated. An investor assessing a SaMD startup should treat a mature, agent-assisted evidence pipeline as a genuine asset, because it shortens time to clearance and reduces the risk of a submission stalling. Conversely, a team using AI to move fast while neglecting traceability and risk management is accumulating regulatory debt that will surface at the worst possible moment, during review.

The organizations getting real value from agents are the ones that already treated traceability and risk management as first-class work rather than a last-mile scramble. Agents amplify whatever discipline already exists. They make a rigorous team faster and a sloppy team more confidently wrong.

The takeaway

Agentic AI is not a reason to loosen the controls a regulated device demands. It is a way to meet them faster, provided the lifecycle and the human checkpoints stay intact. Firms delivering medical device software development at scale, across hundreds of products and multiple markets, are converging on the same conclusion: the winners will pair AI-accelerated delivery with an IEC 62304 lifecycle and an ISO 14971 risk file that can withstand an audit. For device makers weighing where to invest next, the question is no longer whether to use AI agents in medical device software development, but how to govern them well enough to ship safely. The teams that answer it early will define the next generation of connected care.