Why Your AI Agent Needs a Dry Run: Digital Twins as the Safety Layer for Lab Automation

Answer capsule: An AI agent should never send a command to a laboratory instrument without a dry run first. A digital twin dry run executes the agent's entire proposed protocol against a virtual model of the lab - checking volumes, tip states, labware positions, and cross-instrument dependencies - and refuses any step that would fail physically, before anything on the bench moves. In our own evaluation of an agent-driven liquid handler, a volume-only state model waved through 7 of 8 realistic workflow errors; a twin that also tracks liquid identity and instrument state caught them all. The dry run is not an optimization. It is the difference between an agent you demo and an agent a lab lets run.

The industry has crossed a line in 2026. 71% of organizations report using AI agents, quality control labs are named as the first to move agents from pilots into production, and AstraZeneca is presenting digital-twin-plus-agent manufacturing loops at industry forums. Yet only 11% of agent use cases reached production last year. The gap between the demo and the deployment has a name, and it is safety: nobody can explain what happens when the agent is wrong.

This post describes the architecture that answers that question - drawn from building exactly this layer for agent-driven liquid handling.

The Problem: LLMs Propose Plausible Protocols, Not Valid Ones

A language model driving an instrument through MCP produces syntactically perfect tool calls. That is precisely the danger. The call aspirate(well="A1", volume=150) looks identical whether well A1 holds 200 µL or 20 µL - the difference exists on the bench, not in the text.

Researchers building self-driving laboratories call this the Syntax-to-Safety Gap: current foundation models "exhibit significant safety failures," and the Safe-SDL authors conclude that "architectural safety mechanisms are essential rather than optional." An agent's error modes are not exotic. They are mundane, silent, and expensive:

• Aspirating from a well that a previous step already emptied
• Dispensing into a plate that was moved to the reader two steps ago
• Reusing a tip that touched a reagent, contaminating a patient sample
• Running a thermal cycler on a plate nobody sealed
• Consuming the last tips mid-protocol, stranding a half-processed plate

None of these crash. Nothing raises an exception. You discover them two days later, in a bad curve.

What a Dry Run Actually Checks

A dry run executes the complete proposed protocol against a digital twin - a stateful model of every instrument, every piece of labware, and every liquid in the lab - and returns a verdict before the first physical command is sent. The principle we build on: the LLM proposes, the deterministic layer disposes.

The diagram shows the three-layer architecture: the AI agent converts a scientific goal into a multi-step protocol; the digital twin executes that protocol against a sandboxed copy of the lab state and either validates it or refuses with a specific reason; only validated plans reach the instruments through MCP. The refusal loops back to the agent, which can re-plan - the same pattern sovereign-infrastructure orchestration systems use, where "only validated actions are released to the execution layer."

Four categories of check happen in the twin, in increasing order of subtlety:

1. Conservation and capacity

The obvious physics. A well cannot give up more liquid than it holds, minus the dead volume a tip physically cannot reach. A destination cannot take more than its capacity. A tip has a maximum volume. These checks are table stakes - and still missing from most agent demos, which track no state at all between calls.

2. State that commands leave behind

Every command mutates the world. An aspirate leaves a well emptier and a tip fuller; a plate move leaves a slot vacant; a tip pickup leaves a rack position bare. The twin executes each step's effects on a sandboxed state copy, so step 14 is checked against the world as step 13 left it - not against the world as it was when the protocol started. This is the check that catches "aspirate from the plate you already moved."

3. Liquid identity, not just volume

Here is the finding that changed our architecture. We evaluated an agent-driven liquid handler against a twin that tracked volumes correctly - conservation, capacity, tip presence, all enforced. It still allowed 7 of 8 realistic workflow errors. Re-aspirating from a spent sample well. A reagent-contaminated tip entering a patient sample. Dispensing into the source plate. Three substances mixed in a two-substance assay well.

Every one of those errors is invisible to a volume-only model, because every volume was legal. What makes them errors is identity: what the liquid is, what the tip has touched, what the well is for. A twin that tracks composition - this well holds 30 µL of sample and 20 µL of buffer, this tip has been in wash buffer - catches all of them, with no knowledge of the specific instrument involved. The distinction between a 1:10 and a 1:2 dilution is not representable in a volume; it requires per-component tracking.

4. Declared state no sensor reports

A thermal cycler cannot detect whether a plate is sealed. A sealer never tells the cycler it sealed one. Whether a chromatography column has runs left in it is written down nowhere the instrument can read. These facts decide whether the next command is safe, and they exist only if the twin models them: a command declares state ("after Seal, this plate is sealed; one seal comes off the roll"), a later command requires it ("RunProgram requires the plate sealed"). When the plate is one object moving through one modeled lab, the declaration travels with it across instruments.

The Refusal Is the Product

A dry run that returns INVALID has told nobody anything. The verdict a scientist can act on names the step, the rule, and the numbers:

// A dry-run verdict, as the agent and the scientist both receive it
interface DryRunVerdict {
  ok: boolean;
  refusedAt?: number;           // which step broke, zero-indexed
  code?: RefusalCode;           // stable - what a planner or retry loop keys on
  message?: string;             // human - what a scientist reads
  state: LabStateSnapshot;      // the lab AS IT STOOD when it refused
}

type RefusalCode =
  | "INSUFFICIENT_VOLUME"       // well holds 20 uL, step asks for 150
  | "WOULD_CONTAMINATE"         // this tip has been in buffer; target holds samples
  | "NOTHING_IN_THE_SLOT"       // the plate this step targets was moved away
  | "STATE_NOT_READY"           // plate must be sealed, and nobody has said it is
  | "INSUFFICIENT_TIPS";        // the rack runs dry at step 41 of 60

// The two-audience rule: `code` is for machines, `message` is for humans.
// "plate_7 has to be sealed, and nobody has said whether it is" beats "invalid"
// in every incident review you will ever run.

Two design rules matter more than they look. First, stop at the first refusal - everything after a failed step is a consequence, and a wall of forty cascading errors hides the one that matters. Second, return the state as it stood at refusal - the picture explains the sentence. When the verdict says the tip is contaminated, the scientist sees which wells it visited.

There is a subtler rule inside STATE_NOT_READY: the twin never assumes. An unset seal is not a broken seal - it is a fact nobody stated, and the refusal says so explicitly. A twin that guesses "probably sealed" is a twin no regulated lab will trust; FDA and EMA's January 2026 Good AI Practice principles demand exactly this kind of documented, risk-based conservatism, and validation practice in 2026 has shifted "from validating static systems to governing learning systems."

Where the Industry Is Converging

Three independent lines of work have arrived at the same architecture in the past year.

Pharma manufacturing. AstraZeneca's process digital twins - "physics-informed, integrated models that evolve with new data" - sit inside an agent loop where the human scientist reviews top solutions and returns feedback. Their reported outcome: 56% productivity gain and 67% shorter development lead times across digital-twin, ML, and robotics initiatives. The twin is the layer that makes agent proposals reviewable.

Self-driving lab research. Safe-SDL formalizes operational design domains and transactional consistency between "digital planning and physical execution." PRISM points out that most lab digital twins today are used for post-hoc documentation and monitoring - and argues the value is in pre-execution validation and refinement. The research frontier is not whether to dry-run; it is how much refinement to do inside the twin before execution.

Regulated QC labs. The first agent deployments are landing in quality control, where audit trails and approval steps are non-negotiable. A dry-run verdict with stable codes and named reasons is precisely the artifact an auditor wants attached to an agent-initiated run - the same architecture we described for keeping LLMs off the GMP critical path.

The common shape: a deterministic validation layer between a probabilistic planner and a physical world. What differs is only how rich the twin's state model is - and as our 7-of-8 finding shows, that richness is exactly where safety lives.

Building It: The Order of Operations That Works

Having built this layer - and rebuilt it once after the evaluation exposed the volume-only model - the sequencing that works:

1. Write the error catalog first. Before any twin code, enumerate the realistic workflow errors your lab can make - spent wells, contaminated tips, unsealed plates, dry racks. This list is your oracle: the twin exists to catch these, and a twin feature that catches none of them is decoration.
2. Model the lab as one world, not one twin per instrument. A plate sealed on the sealer and cycled on the cycler is the same plate. If each instrument owns a separate model, the seal set on one is invisible to the other - and the cross-instrument workflows that matter most become uncheckable.
3. Track liquid identity from day one. Volume-only state is the trap. Composition per well, contact history per tip, role per labware. This is the layer that caught our 7 of 8.
4. Make every refusal carry a stable code and a human sentence. The code is what the agent's retry loop keys on; the sentence is what ends up in the deviation report.
5. Sandbox by construction. The dry run mutates a copy, never the authoritative state. A validation that can touch production state is a production incident with a friendly name.
6. Wire it into the agent loop, not beside it. The verdict goes back to the agent as structured data, so a refused plan becomes a re-plan - with the constraint that failed made explicit.

The twin does not need geometry, collision physics, or photorealistic rendering to deliver this. It needs correct bookkeeping of state, identity, and declared facts - which is a far smaller build than "digital twin" usually implies, and one a team can validate exhaustively because every check is deterministic. Our practical guide to laboratory digital twins covers the broader architecture; this post is the case for the layer that makes agents deployable.

Frequently Asked Questions

What is a digital twin dry run in lab automation?

A dry run executes an AI agent's complete proposed protocol against a digital twin - a stateful virtual model of instruments, labware, and liquids - before any physical command is sent. Each step is checked against the simulated state the previous steps produced, and the run is refused at the first step that would fail physically, with a specific reason. Only validated protocols reach the instruments.

Why isn't schema validation of MCP tool calls enough to make AI agents safe?

Schema validation confirms a call is well-formed, not that it is physically possible. aspirate(well="A1", volume=150) passes any schema whether A1 holds 200 µL or is empty. Safety requires state: what previous steps consumed, where labware currently stands, what each tip has touched. That state lives in the digital twin, not in the tool schema.

What errors does a digital twin dry run catch that volume tracking alone misses?

Identity errors: re-aspirating from a single-use well that was already sampled, a reagent-contaminated tip entering a sample, dispensing into a source plate, exceeding an assay's substance count per well. In our evaluation, a volume-only model allowed 7 of 8 such realistic errors - every volume was legal; what made them errors was what the liquid was, which requires per-component composition and per-tip contact history.

Does a dry run slow the AI agent down?

No. The dry run is deterministic bookkeeping over in-memory state - it completes in milliseconds for protocols of dozens of steps, orders of magnitude faster than the first physical aspirate. The cost of skipping it is measured in ruined plates, lost samples, and the two days it takes to notice a silent contamination.

How does a digital twin dry run help with regulatory compliance in pharma labs?

The verdict is an auditable artifact: which plan was proposed, which checks it passed, and - on refusal - the step, the stable code, and the reason, before anything touched the instrument. This matches the FDA/EMA January 2026 Good AI Practice emphasis on human oversight design and risk-based validation, and gives QC labs the approval-step evidence that agent-initiated runs otherwise lack.

Key Takeaways

• An AI agent driving lab instruments needs a deterministic dry run between planning and execution: the LLM proposes, the twin disposes.
• Volume tracking is not safety. In our evaluation, a volume-correct model allowed 7 of 8 realistic workflow errors; catching them required liquid identity, tip contact history, and labware roles.
• Model the lab as one world. Cross-instrument workflows - seal here, cycle there - are uncheckable when each instrument owns a separate twin.
• The refusal is the product: a stable code for the agent's retry loop, a human sentence for the scientist, and the lab state as it stood when it refused.
• The industry is converging on this layer from three directions at once - pharma manufacturing (AstraZeneca), SDL research (Safe-SDL, PRISM), and regulated QC - with only 11% of agent use cases in production, the dry run is what moves the other 89%.

---

Written by Iacob Marian, Technical Lead & Co-founder at QPillars. Published 2026-08-22.