Static and reactive
Your eQMS is holding the review date that passed in April and the twelve people who never acknowledged the revision. It will show you both, accurately, the moment you think to ask. Nothing starts until a person starts it.
Agentic quality management · ISO 13485
You care about
product quality.
Your QMS should too.
Atlas reads your whole register overnight, without being asked. It follows the links between records, versions, forms and the procedures that govern them, looking for the things no single record is wrong about — the ones that only show up when they're read together.
By the time you're in, what it found is waiting as a drafted finding, with its evidence attached and an action proposed. Its agents can't change the register: the one tool they hold files a proposal, and you sign it or you don't. What it means is still your call.
- Built on
- ISO 13485 clause structure
- Audit trail
- Append-only, no exceptions
- Agent authority
- Propose only
1.
Accurate, late, and never read across
An eQMS is measured on whether the record exists and whether it is defensible. Nothing in that measure asks whether anyone read it, or read it next to the other three records that would have changed what it meant. So the register fills up with evidence that is complete, correct, and inert. It happens in four ways.
Fragmented
Linking a post-market complaint back to the design requirement or the manufacturing batch it came from is forensic work, and it is done by hand. The data exists. It's in four systems that were never introduced to each other.
Assembly, not analysis
CAPA investigation, audit preparation, regulatory impact assessment — all of it driven by human effort. Days of collection, and the expert thinking on top takes an afternoon.
Finished, and already out of date
By the time a record is complete it describes a device you have since changed. The file is in order and the thing it documents has moved. Nobody is doing anything wrong here; the latency is built into a system whose job is to close records rather than to read them.
2.
How it's built
An agent is only as good as what it can see and what it's allowed to do. Atlas is three layers and a signature: one register the agents can read end to end, a scheduler that decides what deserves looking at, the agents themselves, and a human who is the only thing on the system that can change anything.
Three layers, and the signature that closes them
Layer 1
One register
An agent that can only see part of the system will only ever find part of the problem.
How it works
A single relational register. Documents, versions, forms, records and products, with the links enforced by the database rather than by a naming convention — a record knows the procedure that governs it and the form revision it was filed on.
Layer 2
The scheduler
Something has to decide what deserves looking at, on a schedule rather than on a click.
How it works
Sentinel reads the register on a schedule and routes what it finds. Most of what it catches needs no model at all — an overdue review is a date comparison, and it's better done by a query that cannot hallucinate.
Layer 3
Specialised agents
Design control, CAPA, post-market surveillance, audit, regulatory intelligence — each running continually.
How it works
Four available now, two in development, three on the roadmap. Section 4 lists which is which, so what you would be buying is separable from what you would be waiting for.
And throughout
Human in the loop
Agents produce reviewable artifacts. A human expert reviews, modifies, and approves.
How it works
Approval isn't the last step in the chain here — it's the only step that writes anything. Everything above it produces a draft and stops. Section 5 is what that costs an agent in authority, and it's the part we took furthest.
3.
One register, read every morning
Atlas isn't a chat window bolted onto a document store. The register, the agents and the approval flow are one system, which is the only arrangement in which letting software near a controlled document is defensible.
-
01
The register
Documents, versions, forms, records and products in one store, properly linked. A record knows which procedure governs it and which revision of which form it was filed on.
-
02
Sentinel
A scan on a schedule rather than on a click. Reviews coming due, publications nobody acknowledged, records on superseded forms, clause changes with something downstream.
-
03
The agents
Each picks up a finding and does the assembly — the evidence, the precedent from the last time this happened, the draft. They hold one write tool between them, and it files a proposal.
-
04
You
Proposals queue up with their working shown. Approve one and it executes under your signature. Reject it and the rejection is recorded against the finding.
4.
What the agents cover
The last three are the ones that close the loop between what a device does in the field and what the file says about it, and they are the reason the rest exists. They are also the three that need a body of real complaint data underneath them, which is why they are marked roadmap rather than shipped. Statuses below are the real ones.
Document control
AvailableRegister, versioning, controlled reader, approval routing, TOTP e-signature, acknowledgement fan-out and chasing.
Sentinel
AvailableThe morning scan. Reviews falling due, unacknowledged publications, records on superseded forms, downstream clause impact.
Audit preparation
AvailableAssembles the data room on request, and tells you which records are incomplete before the auditor asks for them.
Design control
AvailableTraces requirements through the medical device file, and reports what a proposed design change touches.
Regulatory intelligence
In developmentWatches the guidance documents already sitting in your register for revisions, and works out what each one affects.
Assistant
In developmentAnswers questions against your own procedures, with the clause cited. Can turn an answer into a proposal.
CAPA
RoadmapFull lifecycle through the effectiveness check, which is where most CAPAs quietly stall. Root cause drafted against prior closures.
Post-market surveillance
RoadmapTrends across complaints, including the ones still sitting in an inbox because nobody has filed them yet.
Risk management
RoadmapISO 14971 file per device family, flagging hazards that turn up in the evidence but never made it into the file.
5.
What it isn't allowed to do
Letting software read a controlled register and draft against it is only sensible if the limits are structural. Each of these is enforced in the database, not in the instructions given to a model — an instruction can be talked around and a foreign key cannot.
-
Agents never write to the register
They hold a single write tool and it files a proposal. Every path into a controlled document goes through a person.
-
Published versions are immutable
Not editable by an agent, an admin, or us. Correcting one means re-issuing it, which is what the standard asks for anyway.
-
The audit trail only grows
Events reject updates and deletes outright, and each one is written in the same transaction as the change it describes.
-
Signing requires you, present
A TOTP re-authentication from the signer, every time. There's no code path that produces a signature on an agent's behalf.
-
No date gets invented
Imported documents keep the effective dates from their signed renditions, or show none at all. A plausible date on a compliance record is worse than a blank one.
-
Nothing is drafted anonymously
Model, prompt version, source records and approver are recorded permanently against anything an agent touched.
6.
Version history
Atlas is developed under its own quality system, so this is a controlled record rather than a roadmap graphic. Its software validation file was routed through Atlas. The order is deliberate: an agent cannot correlate a complaint against a design change until both are in one register, under version control, with the links enforced. That is the first group below, and it is built.
| Rev. | Change description | Status |
|---|---|---|
| The register the agents read | ||
| P0 | Register, controlled reader, versioning, records, bulk import of an existing corpus | Released |
| P1 | Approval workflow, TOTP e-signatures, acknowledgements, proposal queue | Released |
| P1.5 | Sentinel — scheduled register scanning | Released |
| P2 | Native forms and in-system record fill | In development |
| P3 | Internal audits and training records | In development |
| P4 | Assistant with clause-level citation | In development |
| What it was all for | ||
| P6 | CAPA and non-conformance lifecycle | Planned |
| P7 | Post-market surveillance and complaint intake | Planned |
| P8 | Risk management to ISO 14971 | Planned |
Request a demo
We'll walk you through it.
Half an hour on a call. We'll show you the working system — how a document gets approved and signed, what Atlas finds when it reads through everything overnight, and what happens when you approve or reject what it puts in front of you. Bring the awkward questions; we'd rather answer them now than after you've moved anything across.