What Replaces the Incumbent

Summary

The software running regulated operations is failing at the seams rather than the centre: systems of record hold their data well, but they don't run the daily work, which is why so much of that work has drifted into spreadsheets and hand-built tools that were never designed to carry an operation this size. Two things now make this fixable. Compliance regimes have shifted from counting documents to judging design, which removes the main reason buyers had to stay put and exposes vendors whose real moat was the cost of revalidating them; and the architecture that replaces the established systems is now clear enough to specify and to test in a demo. Those systems will be displaced — but never by a cutover project. Replacement works when it happens one data field and one workflow at a time, each step small enough to validate and to reverse, so anyone selling a switchover weekend is selling the version that fails. How far automation can go then turns on two things. Where a human must decide is an architectural question with a real answer: some checkpoints move downstream as a system earns trust, while others are fixed by law or by ethics and never move. And "agentic AI as a service" is three different things, only two of which belong in a regulated plant or lab — the version marketed hardest, autonomy rented from a vendor with the decision logic inside their platform, is the one to refuse.

1. The problem isn't missing software

Walk into a QC lab, a manufacturing plant, or a utility control room and you'll usually find a validated system of record doing exactly what it was bought to do. Then you'll find the real operation running somewhere else: spreadsheets, shared lists, low-code flows, a mailbox, and dashboards built in-house.

The problem in these operations is not an absence of software. It's an accumulation of improvisation.

That improvisation isn't a training failure. It's evidence. The system of record models the data structure well and the day's work badly — it can tell you everything about a sample except what needs to happen to it before Friday. So people build the missing layer themselves. The real incumbent in most accounts isn't a rival vendor; it's a spreadsheet and the person who built it, and that person is usually in the room.

Give them their due. These tools exist because someone competent understood both the regulation and the gap, and many are formally assessed and approved — validating a spreadsheet is a real discipline, not a shortcut. The case against them isn't that they're rogue or that they don't work.

It's that validation freezes them. Once a spreadsheet or a flow is qualified, every change reopens the assessment, so the tool ossifies while the work moves on. They're person-dependent: load-bearing, thinly documented, one resignation from becoming a mystery. And each is assessed in isolation, so nothing covers the handoffs between them — which is where the work lives, and where inspectors look. They don't only read the procedure; they compare it to how the work really gets done.

Three structural facts make this worse than it looks.

Errors concentrate before the instrument, not inside it. In clinical laboratory testing, the pre-analytical phase — collection, identification, receipt, labelling, handling — accounts for roughly 62 to 68 per cent of all errors.¹ That's the reception bench and the loading dock: the ground the established systems model least well and the hand-built layer covers worst.

An audit trail is not data integrity. A peer-reviewed analysis of 1,766 FDA warning letters from 2016 to 2023 found violations relating to endurance, availability, and completeness rising after 2020.² Nearly every system involved had an audit trail. Logging a change is not the same as being able to trust the record.

Integration is a recurring cost dressed as a one-time cost. Point-to-point interfaces mean the next instrument, courier, or partner is a fresh project. Vendor guidance puts initial licences for a manufacturing execution system at $80,000 to $350,000, with implementation adding $50,000 to $200,000 over twelve to twenty-four months.³ Practitioner literature on laboratory implementations is blunter: scope creep and budget overruns are the normal case, not the failure case.⁴

None of this is one vendor's fault. It's what happens when software assumes the settings controlling your process live in the vendor's database, and that changing them is a services engagement.

2. Regulation stopped being the excuse

Here's the part most buyers haven't priced in. The compliance regime moved, and it moved in favour of better architecture.

For years the argument against replacing a validated system was that revalidation would cost more than the improvement was worth. That argument is weakening, because regulators and industry bodies have shifted from rewarding documentation volume to rewarding demonstrated thinking.

ISPE's GAMP 5 guide, second edition, is explicit about it. It requires qualified experts to judge how much rigour a system actually needs (Appendix M12), states that the lifecycle is not inherently linear, supports iterative and incremental development, and adds guidance on AI, cloud services, and supplier evidence.⁶ In the medical device sector, the FDA's final guidance on computer software assurance takes a risk-based approach, concentrating effort where patient safety and product quality actually depend on it.⁷ That guidance governs devices under 21 CFR Part 820, not drug manufacturing — but nobody reading it thinks the direction of travel stops there.

The commercial implication is the important one. Validation effort is no longer a flat tax favouring whoever is already installed. It's becoming a function of how clearly a system's design maps to the integrity principles it claims to uphold. A system whose configuration is readable and whose controls are structural is cheaper to assure than one whose compliance is an assertion buried in a services deliverable.

That's an architectural competition, and the vendors whose real advantage was the sunk cost of validating them are the ones it exposes.

3. Five shifts worth demanding

What follows is the architecture that competition selects for. Each shift comes with a way to test it in a demo, because a claim you can't test in an hour isn't a claim.

Compliance built into the design, not bolted on afterwards. The data-integrity principles regulators inspect against — ALCOA+, and increasingly its ten-principle successor ALCOA++ — are usually treated as a policy layer laid over a finished system. They read far better as an architecture specification. Each principle names a structural property whose mechanism either exists in the design or doesn't: contemporaneous means the record is created by the act itself rather than reconstructed afterwards; accurate means corrections append instead of overwriting. Build those in and you validate the mapping once, and adjacent workflows inherit it instead of each proving itself again. Appendix C maps all ten. The honest price is that writing those invariants down machine-readably is real overhead: a large body of rules and recorded decisions needs navigating, and it grows. Anyone who says it is free has not done it.

Two consequences. Compliance becomes something the system displays rather than something an operator performs, and the audit record can read as a narrative a human follows — received manifest at 14:23; twelve expected, eleven confirmed; discrepancy flagged; amendment recorded — rather than a table of old and new values that QA exports and translates by hand. And the principle set is still moving: ALCOA became ALCOA+, now becoming ALCOA++ with the addition of traceable, an unbroken thread from raw capture to final report.⁵ A system whose integrity is structural absorbs that as a mapping exercise; one whose compliance lives in documentation re-validates. Ask to see: an audit record read aloud, without anyone interpreting it for you — then ask which principle each line satisfies.

The settings that run your process should be readable files you keep. Not rows in a vendor's database. When the data model, permissions, workflow rules, and compliance mapping are versioned text you hold, three things follow. Your QA team can review the configuration directly, and that review is the evidence. A configuration change goes through the same approval path as a code change, so it's fast without being loose. And if the vendor is acquired or folds, you still have the thing that runs your operation. That's what "no lock-in" means as a technical property rather than a clause. Every product holds you somewhere — the data, the workflow engine, or the validation package. Asking a vendor to name theirs is revealing. Ask to see: the difference between last month's configuration and this month's, as a document.

Assemble the pieces a site needs instead of switching parts of one big product off. A site where one person does everything and a site with strict separation of duties should be the same software composed two ways, not two products or a forked codebase. That's the difference between a second deployment that takes weeks and one that repeats the first project. Ask to see: two live sites with different operating models, and what differs between them.

Say which system owns which piece of data. This is the most important idea in the paper. For every field, there should be an explicit statement of whether this system is the master or is subscribing from something else. It sounds like plumbing. It's the mechanism that makes replacement survivable.

Big-bang replacement of load-bearing operational systems has a well-earned reputation for failure, and most legacy estates lack the documentation such a project assumes. But that's an argument about the shape of the project, not about whether the old system eventually goes. When ownership is declared field by field, it can move field by field. Each move is small, individually validatable, and reversible. Run enough of them and the incumbent holds nothing that matters.

So the honest answer to "will this replace our system of record?" is yes. The honest answer to "how?" is: gradually, in governed increments, in the only way that has ever actually finished. Coexistence isn't the alternative to replacement. It's how replacement happens. Ask to see: the field-level ownership map, and one field that has already moved.

Show what needs doing today, not a list of records to hunt through. The established systems do ship worklists, task queues, and dashboards, so this is a difference of degree rather than a missing feature. But the organising spine is still the entity: you navigate to a record, read its properties, change its status, and the worklist is a saved view layered over that. It's a faithful reflection of the data model, which makes it good at managing data and weaker at orchestrating work.

The alternative organises around a small, fixed set of activities and answers one question on arrival: what needs to happen right now? Consumer tax software made the pattern legible to everyone — items are green and moving on their own, amber with a specific fixable problem, blue because they're waiting on capacity rather than information, or red and escalated with enough context that the next person doesn't start over. In operations that state becomes the dispatch mechanism, not a badge. Elapsed time drives it as much as events, so an approaching destruction date surfaces itself.

Several things follow. A barcode scan should be the status change, not a prompt to record one. And when the system has already verified everything, skip the review step entirely, so attention goes only to exceptions. Ask to see: the screen an operator opens at 8am, and how many clicks to the first decision.

What each shift buys you

4. Where a human still has to decide

Every regulated workflow has points where a person must act. Most discussions treat these as one category and then argue about whether AI can absorb them. Sort them by the kind of judgement involved and the answer stops being a matter of opinion.

Two things fall out of this.

First, "AI will take over the review step" is true for two of those five rows and false for the other three. A person judging whether a sample is still viable exercises domain expertise that may become automatable. A person signing as the accountable custodian is not doing something a model can inherit, however good the model gets.

Second, a checkpoint and its record of why a change was made are one object. Move the checkpoint and the record moves with it. So where the checkpoint sits should itself be a governed setting, changed through the same approval path as anything else — not welded into the code by whoever wrote that screen.

One more piece, easy to miss and load-bearing: a named machine identity is a legitimate actor in an audit record, provided the process it performs has been validated. That's what makes bounded automation compliant rather than a gap, and it's the boundary the next section turns on.

5. Three things called "agentic," only two of which belong here

Buyers are being offered "agentic AI as a service," and the term is doing too much work. The literature promoting it is clear enough about what it means: agents acting with minimal user intervention, low user effort, self-learning behaviour, and outcome-based pricing — summarised by one proponent as "SaaS automates tasks; AaaS automates outcomes."⁸ The same paper lists reliability, interpretability, and compliance among the risks, then offers "robust governance and explainable agent models" as the mitigation without saying what either would consist of.

That missing mechanism is the whole problem, and §4 supplies it. Three genuinely different things are bundled under one word.

Agentic development is AI used to specify, build, and verify the software itself. This is real, and it's why the economics in §6 have changed. It also moves where the hard part is. When producing code stops being the constraint, the constraint becomes stating what must always be true and verifying the system does it. In practice: invariants written down as a primary artefact rather than commentary, and every claim about what a system already does treated as a hypothesis until someone reads the code. One recent analysis calls the new role intent architect rather than code author, which is a fair description of where the work goes.⁹

Agentic operation is agents doing work inside the running system. Legitimate, but only within the limits §4 sets, under a named machine identity and a validated process. It pays best on high-volume, low-judgement work: reconciling records against a source for human approval, harmonising incoming metadata against a controlled vocabulary, watching telemetry for drift, drafting documents a person then reviews.

Agentic access is the one nobody markets and buyers should want most. The system exposes a stable, documented interface so your agents can query and act on your data without a vendor-specific toolkit. The intelligence stays yours and portable. The vendor is the execution engine, not the broker.

Against those three, the marketed version is the wrong shape for a regulated operation. It relocates judgement into a platform you can neither validate nor take with you, and it does so at exactly the checkpoints §4 says can never move.

There's a deeper reason, and it's the sharpest argument in the field. Conventional software carries logic written in advance; agentic software has the agent generate logic at runtime.⁹ In a regulated environment you must validate the logic. Logic produced fresh at runtime leaves no artefact to validate. That isn't a tooling gap better tooling closes — it's a property of the design.

The regulator has now said so. On 2 April 2026 the FDA issued its first warning letter concerning AI use in drug manufacturing. A firm had used AI to generate standard operating procedures, product specifications, and master batch records without adequate quality-unit review; staff said they hadn't known certain legal requirements because the AI hadn't told them. The firm stopped producing drugs.¹⁰ Counsel's reading is worth adopting: this establishes no new AI framework, it applies existing accountability to AI-assisted drafting.¹¹

So the rule for any vendor claim here is simple. A system drafts; a qualified person reviews. Nothing in this space can honestly claim to produce compliance documentation on its own.

The question to ask is: whose agent is it, and can I validate and keep how it behaves?

6. The commercial model changes too

The cleanest way to state the shift is as a comparison of what you end up owning.

Off-the-shelf software gives you a product you don't own. A bespoke build gives you ownership without a product. The position now emerging gives you a product whose validated configuration is yours.

Several consequences deserve saying plainly.

The more configurable a platform claims to be, the more it costs to configure. That sounds like a paradox and isn't. Configuration depth gets delivered through billed hours rather than through your own hands, and a vendor whose revenue depends on configuration labour has no reason to make configuring cheap. Reversing that incentive is a commercial change only a particular architecture allows.

The gap isn't a missing product category — it's a missing layer. Mature products exist for laboratory sample management, manufacturing execution, and building management, and have for years; anyone claiming open ground there is not paying attention. What has no product is the operational thread between those systems: the governed, audit-grade chain that runs across a lab's system of record, a courier, a freezer, a partner site, and a plant. That thread is still assembled by hand at nearly every site. And below the enterprise price floor the choice collapses further, to an enterprise platform the operation can't staff or a stack it builds itself — which is why so much of this territory still gets bought as a project rather than a product.

Buyers here are genuinely torn between buying, building in-house, and paying someone to build. A single offer mismatches the decision actually being made; subscription, co-development, buyer-funded-and-buyer-owned, and buy-the-platform-outright-at-a-published-price are all legitimate, and honest vendors will discuss more than one. Domain expertise is likewise worth more as ownership than as billed hours — which is the real difference between co-development and consulting, and it's checkable: look at who carries risk.

Prove one workflow deeply, then expand because the architecture generalises — not by accumulating features. The first deployment's configuration becomes the second's head start, which turns a months-long implementation into a weeks-long one. Resist the inflated version, though: with AI-assisted build, standing up a capability is cheap either way, so reuse doesn't really "compound." What reuse buys is reach. And an escape route is a selling point rather than a concession — regulated procurement scores vendor dependency as an explicit risk, so a supplier who can tell you before you sign exactly what leaving would cost turns its own size into an argument.

Ask who feels the pain and who captures the saving. The question the category avoids. Where data handling is billed to a client, the efficiency gain and the cost sit in different budgets, and the software doesn't get bought. This kills otherwise sound business cases, and it's better raised early.

A vendor that names what it refuses to become is more credible than one promising everything. The durable position is the governed thread through a process. Endpoints commoditise toward free; the middle is well defended by incumbents. Value sits in the thread nobody owns.

Appendix A — Ten questions to ask any vendor

1. Where is my configuration stored, and can my QA team read it without your help?
2. Show me the difference between this month's workflow configuration and last month's.
3. Which data fields does your system master, and which does it subscribe from ours?
4. Where does your product hold us — the data, the workflow engine, or the validation package? Name it.
5. What keeps running if you cease trading tomorrow?
6. Add an integration in front of me. Is it configuration or is it a project?
7. Show me a compliance status computed from real system state, not a static badge.
8. Which human checkpoints are fixed by law and which can move later? Is their placement a setting?
9. Whose agents act on my data, can I inspect how they behave, and do they come with me?
10. What does the second site cost relative to the first, and why?

Appendix B — The three "agentic" models compared

Marketed agentic-as-a-service sits outside all three: the decision logic lives in the vendor's platform, is generated at runtime, and travels nowhere.

Appendix C — Data integrity as an architecture specification

The ten ALCOA++ principles restated as structural properties. The point of the exercise is that each one has a mechanism that is either present in the design or absent from it — which makes this a design review rather than a documentation review. The right-hand column is what to ask a vendor to show you.

Two notes. Traceable is the tenth principle that distinguishes ALCOA++ from ALCOA+, and it is the hardest to retrofit, because it is a property of the whole chain rather than of any one system in it.⁶ And available is where the established systems most often fail in practice — the data is present, but reaching it requires someone else.

21 CFR Part 11, EU GMP Annex 11 (under revision), ISO 20387, and ISBER best practices are referred to in general terms and cited by name only. Cost figures drawn from vendor and consultancy sources are marked as such and should be treated as indicative.