What a Regulatory Design Agent Must Do

01Introduction

For the past year, we have worked closely with scientists and engineers developing products at the frontier of innovation, from medical implants and novel cell therapies to autonomous robotics. Despite the differences in their fields, these teams face a common challenge: building products that work technically while satisfying complex regulatory requirements.

Engineering decisions in regulated industries cannot be made in isolation. Teams must identify applicable standards, interpret requirements, implement design controls, and establish evidence of compliance, often while the underlying technology is still evolving. A requirement buried in a standard, an exception in an annex, or a regulatory precedent can materially change the course of a development program.

We believe regulation-aware, decision-grade AI agents can make this work substantially easier. By bringing regulatory knowledge into the design process, they can reduce the time spent searching and reconciling requirements and help experts focus on the underlying engineering decisions.

This is the first of two papers. Here we examine the challenge and describe, with a worked example, the capabilities a regulatory design agent needs. The second paper, Benchmarking Regulatory Reasoning, introduces a benchmark for measuring that reasoning and reports how Eureka, our regulatory assistant at Frontier Instruments, performs relative to general-purpose agents given access to the same documents.

02The status quo: regulation as an engineering bottleneck

Regulated product development remains highly manual. Scientists and engineers navigate standards, guidance, and precedents, then translate them into concrete product requirements. The difficulty is not merely locating documents. Obligations are distributed across the R&D lifecycle, and their relevance is not always obvious at the time a design decision is made.

The consequences range from extra verification work to delayed approvals and recalls. Three public cases show how these challenges arise in practice.

Medical devices: Dexcom

Dexcom’s G6 and G7 continuous glucose monitoring systems are subject to FDA special controls, including those in 21 CFR 862.1355(b). These controls need to be expressed as design inputs, including manufacturing acceptance criteria and sensitivity requirements over the device lifetime.

In a March 4, 2025 warning letter, the FDA found that Dexcom had not clearly defined all applicable special-control requirements in its design inputs. The letter identified missing or inadequate requirements related to manufacturing controls, acceptance criteria, and sensor sensitivity across the expected device lifetime. It also raised concerns that a single upper accuracy limit could permit commercial sensors to cluster near borderline performance rather than reflect the distribution demonstrated in clinical studies.

Dexcom committed to developing traceability matrices connecting applicable special controls to design inputs. The case illustrates why a high-level performance target is not enough: regulatory obligations must become precise, traceable engineering specifications.

Cell therapy: Abeona’s Zevaskyn

Abeona developed Zevaskyn, an autologous cell sheet-based gene therapy for wounds caused by recessive dystrophic epidermolysis bullosa. Its release-testing strategy needed to establish the identity of the finished biological product.

The FDA’s summary basis for regulatory action states that an absent final-drug-product identity assay was among several chemistry, manufacturing, and controls deficiencies leading to an April 16, 2024 complete response letter. Following resubmission in October 2024, the FDA approved Zevaskyn on April 28, 2025.

The identity assay was one of several cited deficiencies, not the sole cause of the delay. The lesson is that an overlooked product-specific verification requirement can become an approval bottleneck late in development.

Battery systems: Mercedes-Benz

Certain Mercedes-Benz vehicles used battery-management software to monitor high-voltage battery health and warn drivers of faults. Compliance with FMVSS 305 depended in part on the software’s ability to activate the required warning.

In NHTSA recall 23V-309, filed in May 2023, Mercedes-Benz reported that a software fault could prevent the battery warning from activating. The recall initially covered 3,823 vehicles and prescribed a software update. This was a compliance-driven recall, illustrating that regulatory obligations may depend on system-level software behavior, not simply physical hardware design.

These cases span distinct sectors, but their underlying pattern is consistent: a requirement must be discovered, interpreted in product context, and translated into a concrete design or verification action.

03What a regulatory design agent must actually do

Regulatory questions rarely arrive as clean requests to summarize a clause. Engineers describe the product they are building, the decision they face, and the constraints they think apply. They may not know the relevant standard or how its provisions interact.

A capable regulatory design agent must connect the engineering question to its governing requirements and provide an answer the team can act on. We think of this as five linked capabilities, shown in Figure 2.

1. Understand the engineering context. Identify product characteristics, relevant parameters, and the actual decision to be made.
2. Identify applicable requirements. Find the governing documents and provisions, even when the engineer does not name them.
3. Interpret and reconcile requirements. Connect clauses, definitions, conditional rules, and exceptions.
4. Translate requirements into design decisions. Perform calculations, apply conditions, and derive acceptance criteria or constraints.
5. Produce a defensible answer. Explain the result, support it with source evidence, and identify qualifications or documentation obligations.

These stages reinforce one another. An omitted provision can invalidate a correct calculation. An accurate quote can still lead to a wrong decision if its conditions are misunderstood. A technically plausible answer is not decision-grade unless its rationale is clear.

04A running example: dose accuracy in an injection pen

Consider this question, drawn from the benchmark described in the second paper:

Our variable-dose pen dials in 0.01 mL steps, and the doses we plan to verify are 0.05 mL, 0.10 mL and 0.60 mL. QA has written every acceptance limit as ±5% of the set dose. Separately, our clinical lead wants us to declare our own tighter limits dose by dose instead of using a formula. What should the limits actually be, and are we free to set our own?

1. Understand the problem. The agent must recognize a dose-accuracy question involving a variable-dose device, a dialling resolution of 0.01 mL, three verification doses, and two competing proposals for acceptance limits. The resolution is not incidental: it determines how the applicable acceptance rule is evaluated.

2. Find the governing provisions. The agent must retrieve the relevant dose-accuracy requirements, including the rules for absolute and relative limits and the conditions for individually specified limits. Retrieving only the percentage rule could lead to the incorrect recommendation to use ±5% for every dose.

3. Reconcile the rules. In the reference interpretation, the transition occurs where an absolute error of 0.01 mL equals 5% of the set dose:

At or below this threshold, the reference answer uses an absolute limit equal to the dialling resolution. Above it, the limit is relative.

4. Derive the engineering decision. Applying that rule yields the limits in Table 1:

The agent therefore needs to reject QA’s uniform ±5% interpretation. It must also address the conditions associated with the smaller-dose tolerance and the clinical lead’s proposed alternative. Under the reference rubric, individually specified limits require justification and documentation and must not exceed the applicable dialling-resolution constraint.

5. Present a defensible answer. A useful response explains the calculation, the limits for each dose, why the uniform percentage proposal fails, and which qualifications must be documented. It should reference the applicable provisions so the team can trace the outcome into its design inputs and verification plan.

This worked example summarizes the reference answer used in the benchmark. Teams should check the governing standard, its edition, product applicability, and their own risk analysis before using these limits in an actual verification protocol.

This is the distinction between a document-search assistant and a regulatory design agent: the latter must combine discovery, interpretation, calculation, and traceable explanation into one coherent decision.

05What high-precision regulatory analysis unlocks

Regulation-driven development is not just a document-search problem. It is the ongoing translation of complex, interconnected requirements into engineering decisions.

A capable agent must understand the product context, find governing requirements, interpret their conditions, apply them correctly, and show its reasoning in a form that engineers and quality teams can verify. Whether an agent actually does this reliably is an empirical question, and the second paper in this series, Benchmarking Regulatory Reasoning, sets out how we measure it.

The larger opportunity is to make regulatory intelligence part of day-to-day engineering, helping teams identify constraints earlier, create more defensible design inputs, and reduce the friction of navigating long technical documents. These systems do not replace engineering judgment or regulatory responsibility. They give the people who hold that responsibility better access to relevant evidence.

The goal is not simply to read standards faster. It is to make regulatory reasoning more precise, accessible, and actionable throughout product development.