The most important shift in quality management software is not adding a conversational interface to the deviation form.

It is changing the unit of work.

Traditional QMS software starts with a human opening a form:

Human identifies issue
  -> human enters data
  -> human investigates
  -> human drafts the CAPA
  -> workflow routes approvals
  -> database stores the result

An agent-first QMS starts with an event:

MES alarm / LIMS result / supplier CoA / complaint / audit finding
  -> agents collect evidence
  -> agents reconcile relationships
  -> agents draft the investigation
  -> policy engine evaluates the risk
  -> human reviews the decision packet
  -> qualified person authorizes and signs

That is more than a UX improvement. It is a change in where the system’s intelligence lives.

The opportunity is especially timely for medical devices. The FDA Quality Management System Regulation (QMSR) became effective February 2, 2026, amending the device CGMP requirements in 21 CFR Part 820 primarily through incorporating the ISO 13485:2016 quality management system requirements by reference. [1] The result is not an instruction to automate quality decisions. It is a stronger requirement that quality processes, records, risk management, and evidence remain coherent as the organization changes.

An agent-first QMS can make that coherence continuous. But only if the agents are designed as bounded workers inside a regulated control plane.

Our thesis: Agents do the quality work of evidence collection, reconciliation, investigation, and preparation. Humans retain the quality authority of judgment, risk acceptance, authorization, and electronic signature.

The Core Flip: Event-First, Not Document-First

A document-first QMS waits for a person to notice that something is wrong and translate it into a controlled record.

An event-first QMS starts with the signals that already exist:

  • an out-of-specification result from a LIMS;
  • a temperature excursion from a monitored freezer;
  • a process alarm in a MES;
  • a material lot change in an ERP or PLM;
  • a supplier Certificate of Analysis that does not match the approved specification;
  • a complaint received by email, CRM, or customer-service system;
  • an overdue calibration or an audit finding in another controlled system.

The event becomes a durable Quality Case, not a blank form. A Quality Case is the common work object across deviations, CAPAs, complaints, OOS events, supplier issues, audit findings, change controls, and risk events.

That abstraction matters. A CAPA is not merely a module; it is a lifecycle that links the original event, evidence, investigation, root-cause assessment, action plan, implementation, effectiveness evidence, and final disposition. A deviation is not a collection of fields; it is a stateful chain of facts and decisions.

The QMS should preserve that chain. The agent should help construct it.

The Agent Portfolio

The architecture uses a shared portfolio of specialized task workers, not independent authorities. Each agent owns one bounded outcome and hands controlled artifacts to the next layer.

Agent Primary outcome Human boundary
Sentinel Detects, normalizes, and prioritizes quality signals Cannot create a final regulated record or decide severity alone
NC / Deviation Drafts event scope, chronology, containment, and evidence gaps Quality owner confirms classification, impact, and disposition
CAPA Builds hypotheses, recurrence analysis, and proposed action plan Investigator validates root cause; Quality approves CAPA and effectiveness
Complaint Extracts intake facts, checks duplicates, drafts response and reportability questions Medical, safety, legal, and Regulatory reviewers decide reportability
Document Traces dependencies and drafts controlled redlines SME and document owner approve semantic content and effective date
Change Control Maps affected products, SOPs, validation, suppliers, and filings Cross-functional board approves risk and change initiation
Risk Updates FMEA and risk-register candidates from live evidence Risk owner accepts residual risk
Audit Samples records, assembles evidence, and drafts findings Internal auditor confirms findings and approves the report
Supplier Parses CoAs, scores trends, drafts SCARs and requalification questions Procurement/Quality approve disqualification and notification
Training Identifies affected populations and drafts just-in-time learning Trainer approves content; manager qualifies personnel
Validation Drafts URS, test cases, traceability maps, and validation summaries Validation owner approves protocol, deviations, and final report
Reg Intel Watches approved official sources and drafts impact maps Regulatory and Quality SMEs confirm interpretation and policy change

The portfolio is intentionally broader than the MVP. It is a target operating model.

Every agent must share the same services:

  • a canonical event envelope;
  • an evidence graph and controlled RAG index;
  • a structured work packet;
  • a policy engine;
  • a tool and MCP gateway;
  • an evaluation and observability service;
  • a deterministic QMS state machine;
  • an append-only audit trail.

An agent cannot become more authoritative by being renamed “Sentinel,” “Risk,” or “Validation.” Its authority comes from the capability and policy contract assigned to it.

The Killer Workflow: A Freezer Excursion Becomes a Quality Case

Consider a temperature excursion in freezer FZ-102.

The human should not begin with a blank deviation form. The QMS should begin by assembling the case.

1. Sentinel receives the source event

The event envelope identifies the source system, original record ID, timestamp, payload hash, tenant, site, product context, and correlation ID. The connector is idempotent so a retried alarm does not create a second case.

2. The evidence agent retrieves the relevant world

The evidence graph can connect the excursion to:

  • the temperature trend and alarm acknowledgement history;
  • equipment FZ-102;
  • calibration and maintenance records;
  • the affected materials and inventory transactions;
  • batch genealogy;
  • the approved storage specification;
  • SOP-ENV-042;
  • prior excursions involving the same freezer;
  • training records for personnel who retrieved materials;
  • open deviations and CAPAs in the same process area.

The result is not one giant prompt. It is a versioned set of evidence objects with exact locators.

3. The deviation agent drafts a structured case

The draft contains:

Event summary
- 42-minute temperature excursion in FZ-102
- Source: temperature historian, record TEMP-8812
- Time window: 2026-08-17 14:21–15:03 PDT

Potentially affected scope
- 17 material records identified by inventory transaction IT-18492
- Highest-risk material: MAT-221, storage requirement <= -70 C

Proposed containment
- Quarantine potentially affected inventory pending a documented assessment
- Confirm freezer status and calibration validity
- Verify whether the excursion is still active

Uncertainties
- Door-open data was not available for 11 minutes
- Sensor response time is still being verified

Historical patterns
- 7 prior excursions involving FZ-102
- 5 occurred during material retrieval

Recommended investigation
- Compare retrieval activity, door status, alarm acknowledgement, and sensor history

The draft is useful because it is specific, bounded, and inspectable.

4. The human reviews claims, not paragraphs

The reviewer sees a packet with:

  • every material claim;
  • the exact evidence supporting or contradicting it;
  • the source location and record revision;
  • the confidence and uncertainty;
  • alternative explanations;
  • proposed containment and the next decision required.

The reviewer can accept, edit, reject, investigate, or escalate. The QMS does not treat acceptance as a blank check. The final disposition is a separate controlled decision with a signature meaning and timestamp.

The Key Tension: Probabilistic Drafts, Deterministic Decisions

The central engineering problem is not getting an LLM to write a polished report. It is placing probabilistic output into a deterministic system without losing accountability.

The 21 CFR Part 11 controls for closed systems are explicit. Section 11.10 includes system validation, accurate and complete record copies, record protection, access limitation, secure computer-generated time-stamped audit trails, operational checks, authority checks, and change control for system documentation. [2]

That means an agent’s “decision” cannot be a free-form text string that silently becomes a QMS state.

Instead, the system separates:

LLM output
  -> structured draft artifact
  -> schema and evidence validation
  -> deterministic policy evaluation
  -> human authorization
  -> state transition
  -> audit event

The LLM may suggest that a containment action is appropriate. The policy engine determines whether the action is permitted, which role must authorize it, and what evidence is required. The human identity—not the model identity—must be attached to the electronic signature.

EU GMP Annex 11 supports the same broad direction: the application should be validated, IT infrastructure should be qualified, and the extent of validation and data-integrity controls should be based on a justified and documented risk assessment. [3] The risk assessment is not a page added after the architecture is built. It is the architecture.

Confidence Is Not the Same as Safety

Several proposed autonomy models use universal thresholds: for example, “above 95% confidence, auto-execute.” We would reject that as a control strategy.

A confidence score measures the model’s estimate of its output, not the damage caused by a wrong output. It is also not the same as:

  • evidence completeness;
  • data integrity;
  • product criticality;
  • severity of the impact;
  • reversibility of the action;
  • recency of the source record;
  • regulatory reportability;
  • the presence of contradictory evidence;
  • the reviewer’s authority and qualification.

The correct decision function is closer to:

action_class
+ impact_severity
+ evidence_quality
+ reversibility
+ product_criticality
+ policy_constraints
+ human_role

Use confidence as a routing signal. It should be able to force abstention, but it should never be the only basis for authorization.

A high-confidence wrong disposition for a critical-to-quality attribute is worse than a low-confidence draft that correctly escalates for human judgment. Conservative abstention is a successful agent outcome when the risk policy calls for a review.

The Human Role: Reviewer, Governor, Signer

The phrase “HITL second” is useful only if it does not mean “humans are the last rubber stamp.”

The human role is to:

  • challenge the evidence;
  • resolve ambiguity that the data cannot resolve;
  • add context that is not in the system;
  • accept or reject residual risk;
  • decide when a predicted trend warrants action;
  • authorize a regulated transition;
  • sign with a specific meaning;
  • record an override and the reason for it.

A “skeptic” or red-team agent can be useful here. It can ask:

  • What evidence would falsify this claim?
  • Which source contradicts it?
  • Is the proposed action reversible?
  • Does it conflict with SOP-042 revision 3?
  • Is the cited document the current approved version?
  • Is the human being asked to decide a question the policy has already resolved?

But a second model is not a second accountable human. Its review is a structured piece of evidence. It cannot create an electronic signature or transfer the organization’s accountability to an agent network.

The review interface should therefore show a diff and a decision, not a 20-page generated report. The system should make it easy to expand a claim to its exact evidence, edit a targeted redline, and record a rationale without forcing the reviewer to re-enter boilerplate.

The Reference Architecture

+------------------------------------------------------------------+
| MES / LIMS / ERP / IoT / CoA / Email / CRM / PLM / Audit Logs  |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
| Connector & Event Ingestion                                      |
| Idempotent adapters + event IDs + raw payload hashes             |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
| Event Bus + Immutable Raw Evidence Store                         |
| Kafka / Redpanda / object storage / retention controls             |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
| Evidence Graph + Vector RAG                                      |
| entities | claims | citations | source revisions | index versions  |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
| Agent Control Plane                                               |
| task router | agent/model registry | tools/MCP | policy | eval   |
| work packets | retrieval | red-team | observability | kill switch |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
| Deterministic QMS Core                                            |
| Quality Case state machine | RBAC/ABAC | approvals | e-signature |
| record versioning | audit trail | retention | export              |
+------------------------------------------------------------------+
                                |
                                v
+------------------------------------------------------------------+
| Human Control Plane                                               |
| exception inbox | Slack/Teams/web | accept/edit/reject/escalate    |
+------------------------------------------------------------------+

The most important boundary in this diagram is the one between the Agent Control Plane and the Deterministic QMS Core.

The agent control plane can be changed rapidly. The QMS core cannot. The core is where state, authority, evidence, and signatures live. That separation is what permits a model provider or agent implementation to evolve without turning every model update into an uncontrolled change to the quality system.

MCP: Useful, but Not a Compliance Feature

MCP is attractive because it lets a QMS expose business-level capabilities rather than raw database CRUD:

search_quality_events()
get_quality_case(case_id)
find_similar_events(case_id)
draft_deviation(evidence_ids)
draft_capa(case_id)
draft_change_impact(change_id)
get_audit_evidence(audit_scope)
request_human_review(case_id, packet_id)

But MCP is a protocol, not a magic trust layer.

Every tool still needs:

  • authenticated and authorized callers;
  • tenant, site, product, and data-classification scope;
  • versioned schemas and controlled arguments;
  • validation before execution;
  • rate limits and idempotency;
  • audit logs for the request and result;
  • a defined blast radius;
  • a human signature boundary for controlled actions.

The safe external-agent pattern is:

External agent
  -- read --> governed tools / customer-owned data lake
  -- draft --> staging or draft-record service
  -- review --> qualified human + electronic signature
  -- commit --> QMS workflow API under the human's authority

Read fast. Draft to staging. Human signs. Write slow.

This is the architecture we would use even if a QMS vendor later exposes a genuine MCP endpoint. The related market analysis is available in our 2026 QMS market read on closed APIs and external agents.

What Belongs in the Audit Trail — and What Does Not

The agent layer should record a decision lineage, not a supposed transcript of a model’s hidden reasoning.

Record:

  • source events and content hashes;
  • evidence objects, revisions, timestamps, and locations;
  • agent, model, prompt, retriever, tool, and policy versions;
  • input and output hashes;
  • retrieved documents and relevance scores;
  • structured work packets;
  • claims, alternatives, uncertainty, and missing evidence;
  • tool calls and their results;
  • deterministic policy outcomes;
  • human edits, overrides, rationale, approvals, and signatures;
  • the final record version and export identifier.

Do not make “we stored the chain of thought” a product claim. Private model reasoning may be unavailable, incomplete, or misleading. A human-readable explanation generated from the structured lineage is useful, but the evidence behind the decision must be the authoritative record.

A hash proves that a stored artifact did not change after the hash was created. It does not prove that the artifact was correct when created. The system needs both integrity controls and documented validation.

The MVP: One Event, One Closed Loop

The agent portfolio proposes many valuable features. We would not build all of them.

The first product should make one painful loop defensible:

LIMS OOS or MES excursion
  -> Sentinel detects and creates a signal
  -> NC agent assembles the case and drafts the investigation
  -> human confirms severity, scope, and containment
  -> CAPA agent drafts hypotheses and action plan
  -> human approves the CAPA
  -> system monitors recurrence and effectiveness evidence
  -> human decides closure or reopening

This one loop exercises nearly every architectural control that matters:

  • event ingestion;
  • identity and correlation;
  • evidence grounding;
  • RAG;
  • structured outputs;
  • citations;
  • state transitions;
  • permissions;
  • human review;
  • electronic signature;
  • audit lineage;
  • model evaluation;
  • effectiveness monitoring.

After that foundation is proven, add the other agents. Do not build a swarm of disconnected copilots and call it an agent-first QMS.

What We Would Measure

The right KPI is not “number of documents generated.” It is whether the organization can reach a better decision faster without losing control.

Track:

  • median time from source event to qualified review packet;
  • percentage of material claims backed by exact evidence;
  • first-pass evidence completeness;
  • false-positive and false-negative rates by risk class;
  • abstention and escalation precision;
  • human override rate and reason codes;
  • recurrence after approved CAPA;
  • time to reconstruct a decision from raw event to signature;
  • audit-export completeness;
  • stale retrieval-index rate;
  • tool authorization failures;
  • model/prompt release cycle time and eval pass rate;
  • time saved on evidence gathering;
  • quality of the final human decision, not just draft length.

Claims such as “80% less administrative burden” should be treated as hypotheses. Instrument the workflow, define the baseline, and measure the result in a design-partner environment.

The Open Questions

The architecture is now practical. The unresolved issues are governance and evidence problems:

  1. How does the organization identify the canonical record when a batch, material, equipment, or person has different IDs in every source system?
  2. How do we prevent automation bias when a fluent draft makes a weak claim look settled?
  3. How do we prove that a retrieval search covered the relevant evidence universe, including records that were not retrieved?
  4. How do we use human overrides for model improvement without silently changing the live model?
  5. How do we validate long-lived workflows spanning days, model updates, vendor outages, and partial tool failures?
  6. How do we demonstrate that a model change did not alter the intended behavior of a high-risk workflow?
  7. How do we maintain a regulatory baseline across FDA QMSR, ISO 13485, EU Annex 11, GAMP 5, ISO 42001, and other jurisdictional requirements without treating them as interchangeable? The GAMP 5 Second Edition is useful here because it emphasizes critical thinking and risk-based approaches for computerized systems, including AI/ML. [4]

These questions are not arguments against agentic QMS. They are the validation work the product must make visible.

The Bottom Line

The AI-agent-first QMS is not a database with a chat box. It is not a swarm of autonomous employees. It is not a case for replacing quality leaders with confidence scores.

It is a regulated quality intelligence and control plane:

  • operational events start the work;
  • agents gather, reconcile, investigate, and prepare;
  • evidence claims remain inspectable;
  • deterministic policy governs action and escalation;
  • humans review, challenge, authorize, and sign;
  • the QMS preserves the complete decision lineage.

That division of responsibility is not a concession. It is the product.

The right product thesis is not “AI runs the QMS.” It is:

AI performs the quality work that can be evidenced and governed; humans retain the quality authority that must be accountable.

That is how an agent-first QMS becomes genuinely audit-ready in a QMSR-era, Part 11, Annex 11, and GAMP 5 world.

This synthesis builds on our prior work:

The full architecture brief covers the evidence graph, agent boundaries, validation controls, and the deviation-to-CAPA implementation sequence in more detail.

We build GxP-compliant open-source developer tools and agentic interfaces at GxPSoft AI. If you are evaluating an AI harness for a regulated environment, designing an event-first QMS, or building a governed agent workflow around Part 11, Annex 11, and GAMP 5, we would like to hear from you: duke.lee@saram.io.

Sources

[1] Federal Register, Medical Devices; Quality System Regulation Amendments, 89 FR 7496, published February 2, 2024; effective February 2, 2026: https://www.federalregister.gov/documents/2024/02/02/2024-01709/medical-devices-quality-system-regulation-amendments

[2] Electronic Code of Federal Regulations, 21 CFR Part 11 — Electronic Records; Electronic Signatures, §11.10: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11

[3] European Commission, EudraLex Volume 4, Annex 11: Computerised Systems: https://health.ec.europa.eu/system/files/2016-11/annex11_01-2011_en_0.pdf

[4] ISPE, GAMP 5 Guide, Second Edition: https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition