AI Assistants vs AI Agents for Lab Instruments: What Should You Build First?

An operator asks: “Why did this run stop?” A laboratory automation engineer asks: “Can you prepare the next transfer?” Both requests can benefit from AI. They require different access, permissions and evidence.

An AI assistant for a laboratory instrument can help users interpret a fault, understand a procedure or prepare a method. An AI agent for lab instruments can go further: select supported operations, use tools and respond to observations. A fixed workflow can automate a known sequence without handing those decisions to a model.

Start with an assistant when the user needs a correct explanation or a reviewable proposal. Use a fixed workflow when the sequence is known. Consider an agent when choosing the next step from observations adds value and you can bound its actions. The useful first choice depends on the task your users need to complete and the evidence your instrument software can provide.

For instrument manufacturers, that could mean making application knowledge easier to access. For laboratory automation engineers, it could mean preparing a reviewable workflow around existing equipment. Both are useful starting points. Neither requires an autonomous laboratory.

If you are exploring self-driving laboratories, this decision helps define the first capability around your existing instruments. Identify what the system can know, which operations it can use, and how it will establish the outcome. Then choose the level of assistance and autonomy the task needs.

Assistant and agent describe how a task is handled

Product labels overlap. An assistant may call tools, and an agent may require a person to approve every action. For an engineering decision, describe the behavior explicitly.

Tool access and execution permission are separate decisions. A documentation assistant might use a dilution calculator without permission to dispense liquid. An agent might prepare a complete workflow while leaving dispatch to an operator.

That distinction is central to AI agents for laboratory instruments: more autonomy changes the evidence and control the system needs.

One request exposes the difference

Consider a liquid-handling request:

Transfer two samples to the output plate using 20 µL per sample.

The words are short. The engineering questions are more substantial. Which samples? Which plate? Are suitable tips available? Which operations does the instrument support? What is the current state? Who can authorize the transfer?

An assistant helps resolve the request

An assistant could explain the required labware, retrieve the relevant procedure and prepare a proposed transfer. It should identify its sources and ask when sample or destination identities are ambiguous.

This can be a useful product capability without a live control connection. If operators spend time finding the right procedure or interpreting an error, improving that task is a concrete outcome.

Evaluate the assistant against expert-reviewed questions, including missing information and conflicting document versions. Measure whether its answer is correct, whether the source applies to the instrument version, and how much correction the user needs.

A fixed workflow handles an established sequence

If the transfer procedure is already defined and its inputs can be validated, a fixed workflow can collect the parameters, check prerequisites and execute the permitted sequence.

The useful question is whether interpretation or adaptive step selection adds value. If the task has a stable sequence, conventional control logic may already handle it well. An assistant can still help users prepare its inputs.

An agent prepares and revises within a boundary

An agent can interpret the request, inspect available capabilities and prepare a candidate workflow. When a check reports a problem, it can explain the problem or revise the candidate if that revision is permitted.

Missing equipment is an instructive case. If no tip rack is present, silently changing the deck would change the task. The useful response is to identify the missing prerequisite and return control to the user.

Physical execution adds further responsibilities: approval must apply to the actual candidate, the relevant state must still hold, and the system must establish what happened after dispatch. A prepared plan and a completed transfer are different results.

What a refusal test can establish

In QPillars' LiquidBridge reference application, we tested the planner's decision gate with a scripted model and stubbed expansion and validation. The model supplied the same transfer intent repeatedly, allowing the tests to isolate how the application handled the result.

The suite also checks repair-conversation structure and expansion-result handling. This is evidence about the planner gate. It uses a fake model, supplied expansion results and a validator stub. It does not measure whether a language model understands the request, whether a device reports its state accurately, or whether liquid is transferred correctly.

The engineering lesson is useful despite that narrow scope: an application should reject an unusable candidate even when the model keeps proposing it. Evaluation needs ordinary requests and refusal paths.

Our workflow dry-run guide explains how modeled checks fit into a larger execution path. A model can check the constraints it implements; physical performance needs separate evidence.

Is your instrument ready for the capability you want?

Use these questions to define the first delivery.

You do not need every execution answer to build a useful advisory assistant. You do need them when those responsibilities enter the scope.

For example, access to manuals and exported logs may support fault explanation. An API that accepts commands but cannot reveal their outcome leaves a substantial gap for automated execution. A timeout cannot tell you whether repeating a dispense would consume material twice.

The readiness decision should produce a bounded scope: explain a fault, prepare a sequence, or execute a particular approved operation with observable feedback.

Where MCP and simulation fit

MCP tools provide a way for compatible clients to discover and invoke described software capabilities. The device adapter still needs to preserve the instrument's behavior, including units, errors and command lifecycle. Application permissions and approval need implementation beyond a tool description.

An existing vendor API or SDK can remain underneath that interface. SiLA 2 is another possible instrument communication layer. The practical choice depends on the interfaces you have and the operations you need. Our MCP connection guide covers that integration boundary.

Simulation can help inspect a candidate before execution. OpentronsAI's documentation describes creating and modifying protocols and using simulation as part of preparation. It is a concrete example of the broader pattern: generate, inspect and test before running.

Choose checks around the failure you want to detect. A schema check can detect a malformed parameter. A resource model may detect unavailable labware. Neither, on its own, establishes that a physical transfer succeeded.

Choose the first build around its acceptance condition

For an assistant, a useful first acceptance condition could be correct, sourced fault explanations on a declared set of cases, with appropriate clarification when the evidence is insufficient.

For a preparation capability, it could be candidate workflows that preserve the supplied sample identities and procedure rules, flag missing inputs and allow an expert to inspect the result.

For execution, acceptance must also cover permissions, command ownership, current state and observed outcomes. Include failures such as lost connections and ambiguous completion before expanding the scope.

The first capability earns its place by helping a user complete a task. Extend it when the next responsibility solves a real problem and can be evaluated.

Build the connection, assistant and agent yourself

The QPillars Agentic Lab Academy is preparing two-day, in-person workshops in Zurich and Basel for laboratory automation engineers, instrument software and application engineers, and scientists who can adapt basic Python.

The planned learning path follows the same decisions: connect supported instrument capabilities to a compatible copilot, build an instrument assistant, then develop an agent around a defined task. Guided exercises include supervised time on real lab hardware, feedback and troubleshooting, with a starter project and evaluation checklist to continue afterward.

The first cohorts are in preparation. Express interest in a workshop or discuss training for your team.

If your goal is a product capability, QPillars builds custom AI assistants and agents for laboratory instruments. Discuss one instrument workflow with us, including the task, available interface and result your users need.