What agentic delivery changes in medtech
Device software is the one domain where the documentation is not overhead around the work: it is a regulated deliverable in its own right. That inverts the usual argument about what automation is for.
In most of software, documentation is a cost. It is the thing that slips, the thing nobody updates, the thing a team apologises for in a retrospective. Every argument for automating it starts from the premise that it is overhead you would rather not pay.
Device software inverts this. The design history, the traceability from requirement to verification, the risk analysis and its linkage to controls: these are not a description of the work. They are a regulated deliverable, and their absence is not untidiness, it is a finding.
That inversion is the whole reason agentic delivery is interesting here, and it is a completely different argument from the one made in unregulated software.
Traceability is the deliverable
The central obligation in device software is that you can show a connected chain: this requirement exists because of this user need, it is implemented by this design element, it is verified by this test, this test passed on this version, and this risk control addresses this hazard.
Maintaining that chain by hand is a substantial fraction of what a medtech engineering organisation does. It is done in spreadsheets, in requirements management tools, in matrices assembled before a submission, and it is perpetually slightly out of date because software moves and the matrix is a copy.
An agentic pipeline that derives its record from source control produces most of that chain as a by-product. The link from a requirement to the change that implemented it, to the criteria evaluated, to the result, exists as data rather than as a maintained artefact. That is not a productivity improvement. It is the deliverable arriving for free.
Traceability as a maintained copy
- A matrix assembled by hand
- Always slightly behind the code
- Rebuilt under pressure before a submission
- Gaps discovered late, by an auditor
- Cost scales with change volume
Traceability as a derivation
- Computed from the work itself
- Cannot drift, because nothing is copied
- Available continuously, not at submission
- Gaps visible as they appear
- Cost roughly flat in change volume
The part that does not automate
I have just made the optimistic argument, so let me immediately bound it, because the gap between what derives automatically and what does not is where teams get into trouble.
What derives: the mechanical links. Which change implemented which requirement, what was verified, when, by whom, on what version.
What does not derive: the judgement. Whether the verification was adequate for the risk. Whether a hazard analysis identified the right hazards. Whether a change to one subsystem invalidates the risk assessment of another. Whether a mitigation actually mitigates.
That second list is the intellectual content of the safety file, and no amount of pipeline sophistication produces it. What the pipeline does is stop that judgement from being buried under clerical work, which is worth a great deal given that the people qualified to make those judgements are few and currently spend a large share of their time maintaining matrices.
Change impact is the hard problem
The specific thing that gets harder with volume, and the one I would watch most closely, is impact assessment.
In device software, a change is not just a change. It potentially affects the risk analysis, the verification status of adjacent functionality, and possibly the regulatory position of the product itself. Somebody has to decide how far the ripple goes.
Under a slow cadence this is tractable: a handful of changes, each considered. Multiply throughput and impact assessment becomes the constraint, and it is a judgement-heavy activity performed by exactly the people you have least of.
There is a partial mechanical answer worth building. If requirements, risk controls and code are linked, then a change touching a module can surface the requirements and hazards associated with that module automatically. That does not assess the impact. It tells the assessor where to look, which converts an open-ended analysis into a bounded one.
Where to start, and what to keep away from
The useful split in a medtech organisation is not by risk class, it is by whether the software is part of the device.
Manufacturing systems, quality tooling, internal data platforms, the clinical operations stack, customer portals: substantial engineering estates, real value, and outside the device software regime. This is where an agentic pipeline pays off immediately with ordinary verification and ordinary governance.
Device software itself moves slowly and should. Within it, the useful early targets are verification-adjacent rather than functional: generating test cases from requirements for human review, characterising existing behaviour, producing the traceability artefacts, and drafting documentation that a qualified person then approves. All of these are places where a competent draft saves real time and a human remains accountable for the content.
Where this breaks down
Approving a generated document is not authoring it. A qualified person accepting a drafted hazard analysis has evaluated plausibility, which is a weaker act than having reasoned through the hazards. In this domain that difference can matter enormously, and the mitigation is procedural rather than technical: require the reviewer to have changed something, or to have confirmed specific decisions, rather than accepting wholesale.
Regulators may have views on tooling in the process. If a tool contributes to the design or verification of device software, questions about its validation are reasonable and you should expect them. That is a conversation for your quality organisation, and the answer is not “the vendor says it is fine.”
A derived traceability chain is only as complete as the linking discipline. If a third of your changes do not reference a requirement, the derivation is confidently partial. In this domain a partial chain presented as complete is considerably worse than an acknowledged manual process.
Nothing here shortens the regulatory path. Submission timelines, clinical evidence and approval cycles dominate the schedule, and delivery throughput is not what is limiting most medtech products. Anyone promising a faster route to market through developer tooling is selling something.
And the guidance moves. Regulatory expectations for software, and specifically for AI in the development process, are actively evolving. Any position taken today should be treated as current rather than settled, and confirmed with people whose job it is to track it.
The takeaway
Medtech inverts the usual argument. Documentation and traceability are not overhead to be minimised; they are regulated deliverables, and a pipeline that derives them from the work rather than maintaining a parallel copy addresses the actual cost centre.
What derives is the mechanical chain. What does not is every safety judgement, and impact assessment becomes your constraint the moment throughput rises. Build the linking so that a change can surface the requirements and hazards it touches, which bounds the assessment without pretending to make it.
Start with everything that is not device software, because most organisations have more of it than they realise and all of it is governed by ordinary rules.
If you take one thing into next week: measure what fraction of your changes carry a resolvable link to a requirement. That number is your real traceability coverage, and it is almost never the number in the matrix.