The Instrument Contract: What a Lab Instrument Must Expose for an AI Agent to Close the Loop

A scientist runs an experiment, waits for the result, and decides what to do next. That loop is the whole of experimental science, and today a human closes it. For an AI agent to close it instead, the burden falls almost entirely on the instrument's interface - not on a platform built above it.

This is the argument most of the market gets backwards. The industry answer to agentic lab automation is a lab operating system: an orchestrator, a scheduler, a middleware layer that unifies everything. That path is slow, expensive, and it does not remove the per-instrument integration work - it relocates it. The cheaper path is to make the instrument itself agent-ready, and then let a smart agent talk to a thin contract.

And here is the part almost nobody realises: most of that contract already exists in SiLA 2. The lab-automation world spent a decade building the standard that agents turn out to need - years before LLM agents existed. The primitives are there. What is missing is a profile that says which of them an agent can rely on, and a semantic layer above them that carries meaning. Neither requires a new standard, and neither requires a platform.

Key Takeaways

• The loop is run → observe → decide. An agent can only close it if the instrument tells it what it can do, when it finished, what came out, and what went wrong - in machine-readable form.
• Ten obligations make up the instrument contract. Six are already solved by SiLA 2, three are partial, one is optional-only.
• SiLA 2 mandates one Feature - SiLAService - and leaves the rest optional. That is correct design for a device standard, and it is why an agent must discover-and-degrade rather than assume. What the ecosystem lacks is an agent profile: a named subset a vendor can declare conformance to.
• The remaining gap is semantics, not plumbing. SiLA 2's Feature Definition Language gives identifiers, types, declared errors and units-as-constraints. It does not give intent, uncertainty, state-dependent safety envelopes, or what a result means - and it was never meant to.
• A novel client class has already consumed an unchanged instrument contract - peer-reviewed, in production, on a real liquid handler.
• A driver is not a landlord. A contract-shaping layer is per-instrument, stateless with respect to the lab, and disposable. A platform is lab-wide, stateful, and owns your workflows.

The Loop Nobody Automates

Watch what actually happens between two experiments. The scientist reads the result, judges it against what they expected, and picks the next move: repeat it, change one variable, escalate to a different instrument, or stop. The instrument sits idle through all of it, because the decision lives in a head.

Automating the run is a solved problem - that is what scheduling software has done for twenty years. Automating the decide is what agents are for. What is missing is the observe in between: the machine-readable channel through which an agent learns what happened, precisely enough to choose what to do next.

We have argued before that the agent-to-instrument edge is its own engineering problem, distinct from the agent-to-tool and agent-to-agent edges. This post is the next question down: given that the edge is real, what exactly does the instrument owe the agent?

That channel is the instrument's obligation. And it decomposes into exactly ten things.

The Instrument Contract: Ten Obligations

For an agent to close the loop against an instrument, that instrument must provide:

1. Machine-readable capability discovery at runtime. The agent must not need hard-coded knowledge of what the box can do.
2. Parameterised execution with typed parameters. Commands with a declared, typed signature.
3. Asynchronous initiation returning a durable handle. A run takes minutes to hours; the call cannot block.
4. A terminal-state notification the agent can subscribe to. How does the agent know it finished?
5. Typed, structured results retrievable after completion. A result the agent can reason about - not a PDF.
6. Exclusivity. One agent, one instrument, for the duration.
7. Progress and estimated remaining time. So the agent can plan, and so a stall is distinguishable from slowness.
8. Actionable, declared errors. "Failed" is not actionable. "InsufficientTips" is.
9. Machine-checkable limits, enforced before actuation. The agent should be told no before the arm moves.
10. Cancellation, pause and resume. Physical processes must be stoppable.

That is the whole contract. Nothing about scheduling, nothing about a database, nothing lab-wide. Ten obligations, all local to the box.

How Much of This Does SiLA 2 Already Give You?

More than the market assumes. This is the counterintuitive finding, and it is checkable against the normative artifacts rather than the marketing.

#	Obligation	SiLA 2 status
1	Capability discovery	Solved. SiLAService exposes ImplementedFeatures and GetFeatureDefinition, returning the Feature Definition Language description.
2	Typed parameterised execution	Solved. Features are Commands with typed Parameters and readable/subscribable Properties.
3	Async handle	Solved. Observable commands return a command instance immediately, carrying a CommandExecutionUUID.
4	Terminal-state notification	Solved. An execution-status stream transitions to finishedSuccessfully or finishedWithError.
5	Typed results after completion	Mechanism solved, content not guaranteed.
6	Exclusivity	Solved. LockController provides LockServer, a LockIdentifier on every protected request, and an auto-unlock timeout.
7	Progress and ETA	Partial. progressInfo and estimatedRemainingTime are ordinary proto3 fields in ExecutionInfo - unset defaults to zero, so an agent cannot distinguish "not reported" from "0%". Rely on the terminal transition, which is dependable.
8	Actionable errors	Partial. SiLAFramework.proto defines a four-way oneof: ValidationError, DefinedExecutionError (declared in the FDL, knowable in advance), UndefinedExecutionError, FrameworkError. The taxonomy is excellent; how much an implementation declares up front is its own choice.
9	Pre-actuation limits	Partial. Constraints.xsd defines 17 constraint types including Unit, MinimalInclusive and Pattern, and the server rejects violations with a ValidationError naming the offending parameter. Constraints are static and per-parameter; dynamic, state-dependent limits need the optional ParameterConstraintsProvider.
10	Cancellation / pause / resume	Optional. Available via ObservableCommandController, but not something an agent can assume.

Six solved, three partial, one optional-only - in a standard finalised before anyone was building LLM agents. That is a remarkable piece of foresight by the SiLA consortium, and it means the plumbing is not the problem.

Verdict: the agentic lab is not blocked by a missing standard. It is blocked by the absence of an agent profile over the standard we already have, and by the semantic layer above it.

What Is Left To Do - And It Is Not a New Standard

One: an agent profile. SiLA 2 mandates a single Feature, SiLAService, and leaves the rest optional. For a device standard that is the right call - it is what lets a barcode reader and a liquid handler both comply. But an agent needs to know, before it acts, whether this server supports cancellation, whether it reports progress honestly, whether limits are declared. So an agent must discover-and-degrade: read what the server actually implements, and refuse to assume the rest.

What would fix that is not a new standard but a profile - a named subset of existing SiLA 2 Features that a vendor can declare conformance to, so an agent knows what it is dealing with on connect. The pieces already exist. Nobody has bundled them and given them a name.

There is a practical wrinkle worth knowing: progressInfo and estimatedRemainingTime live in ExecutionInfo as ordinary proto3 fields. Proto3 has no required fields and an unset numeric defaults to zero - so an agent cannot distinguish "no progress reported" from "0% progress." Treat progress as advisory, and rely on the terminal-state transition, which is dependable.

Two: the semantic layer. This is the important one, and it is not something the standard was ever meant to provide. FDL describes what the instrument does - identifiers, types, declared errors, units-as-constraints. An agent needs to know what a scientist wants, with the safety envelope attached. Intent, uncertainty, cross-parameter and state-dependent limits, and what a result actually means all live above the wire format.

That is the layer between SiLA 2 and MCP, and it is where the work is. Not a platform. A translation - per instrument, and reusable across every agent that will ever talk to it.

It Has Already Been Done Once - And That Is The Proof

The strongest evidence that a thin contract beats a thick platform is peer-reviewed and five years old.

In SLAS Technology (2023), the paper describing Tecan's open-source .NET SiLA 2 SDK reports that LabVoice - a natural-language and voice client, built on an entirely different technology stack - drove Tecan's FluentControl through its published SiLA 2 interface. A radically novel class of client consumed an unchanged instrument contract, and the work happened on the client side.

Two honest corrections, because the sloppy version of this story is easy to attack. It was not "Tecan built a voice agent" - LabVoice integrated against Tecan's SiLA 2 server. And "no new instrument work was needed" is only true because Tecan had already done the instrument work by publishing a SiLA 2 server. That is the work. It is precisely the work this post argues is the one thing worth doing.

Which is the whole point: do the instrument work once, and any client - a script, a voice assistant, an LLM agent, something not yet invented - can close the loop against it. No platform was involved in that story. A contract was.

The Platform Argument, Steelmanned

The canonical opposing position states itself plainly. Artificial, in its own paper, describes its product as "a comprehensive orchestration and scheduling system that unifies lab operations, automates workflows, and integrates AI-driven decision-making." That is the platform thesis in one sentence: put the intelligence in the middleware.

Take it seriously, because parts of it are right. Where our thesis genuinely breaks: when you must schedule scarce resources across many instruments and people, when two agents contend for the same centrifuge, and when a regulated environment demands a lab-wide audit trail that no single instrument can produce. Those are real, and a per-instrument contract does not solve them. If that is your problem, you need something lab-wide - and we would tell you so.

But note what a platform does not do. The peer-reviewed Tecan SDK paper is blunt about the underlying tax: "Many devices in a laboratory only have proprietary interfaces. Integrating them into an automation system usually requires implementing a custom device driver." A platform does not remove that per-device cost. It relocates it - into the platform vendor's integration backlog, on their timeline, with your lock-in. (That comparison is our inference, not the paper's claim; the paper's own remedy is the same instrument-side standardisation we advocate, which is convenient for us and we will say so.)

The line is this: a contract-shaping layer is per-instrument, stateless with respect to the lab, and disposable. A platform is lab-wide, stateful, and owns your workflows. One is a driver. The other is a landlord.

Convergent Evidence: A Different Standards Body Drew the Same Shape

If the instrument contract were an idea we invented to sell drivers, you would expect only us to describe it. Instead, an independent standards body arrived at the same shape from the analytical-instrument side.

OPC UA LADS (OPC 30500-1, released November 2023) models methods as first-class program templates held by a Program Manager, exposes StartProgram, defines two-level state machines - one for the device, one per functional unit - and makes results first-class, addressable, provenance-tagged objects in a ResultSet.

Different consortium, different wire format, same contract: discover, parameterise, start, observe state, retrieve a result object. One honest qualifier: LADS guarantees structure at the envelope level, not the payload - the spec permits a result to carry its data as files in a FileSet. A LADS-compliant device can still hand your agent an opaque file.

Verdict: two independent standards bodies converged on the same instrument-side contract, which is a strong signal it is the right decomposition.

What We Measured: The Contract Is Not Enough On Its Own

Exposing the contract is necessary. It is not sufficient - because how you present it to the agent changes whether the agent succeeds.

We ran our own liquid-handler digital twin, LiquidBridge, against three different MCP tool-surface designs over the same underlying instrument. Same instrument, same model, same tasks - only the shape of the exposed tool surface changed:

Tool surface	Hardest workflow (mix 2 samples with reagents)
Raw - every primitive exposed	Passes, but 134,294 input tokens, 45 tool calls, 69 seconds
Routed - narrow, curated surface	Fails, 0 of 2 runs, zero tool calls - it did not error, it did nothing
Composed - intent-level tools	Passes: 8,441 tokens, 4 calls, 6.1 seconds

Roughly 16× fewer tokens and 11× faster, with no loss of correctness - purely from redesigning the tool surface over an unchanged instrument. And note the middle row, which is the dangerous one: the cheap, narrow surface did not fail loudly. It silently did nothing.

Honest limits: this is a digital twin, not physical hardware; it is one model family; the repeat count is low. We are reporting a direction, not a benchmark. But the direction is the point - the layer between the instrument contract and the agent is where reliability is won or lost, and almost nobody is measuring it.

What To Build, Then

Not a platform. Three things, per instrument, and then you are done:

1. Expose the contract - if the instrument speaks SiLA 2 you already have most of it, and that is the cheapest position to be in; if it speaks REST, generate the driver.
2. Declare what you support - state which optional Features an agent can rely on: cancellation, declared errors, limits. An agent that knows what it is dealing with is a safe agent.
3. Add the semantic layer - intent-level tools with the safety envelope attached, so the agent reasons about the experiment rather than about forty primitives.

Then hand it to any agent. The intelligence is not your problem. The contract is.

Frequently Asked Questions

What does an AI agent need from a lab instrument?

Ten things: runtime capability discovery, typed parameterised execution, an asynchronous handle, a terminal-state notification, structured retrievable results, progress and ETA, declared actionable errors, limits enforced before actuation, cancellation, and exclusivity. Six are already solved by SiLA 2; the rest are optional or missing.

Do I need a lab operating system to run AI agents on instruments?

Not to close the run-observe-decide loop on a single instrument - that is an instrument-contract problem, not a platform problem. You need something lab-wide when you must schedule scarce resources across many instruments, resolve contention between agents, or produce a lab-wide audit trail for a regulated process.

Does SiLA 2 make an instrument agent-ready?

It gets you most of the way, which is remarkable for a standard written before LLM agents existed. Discovery, typed commands, observable execution, a four-way error taxonomy, 17 parameter-constraint types and locking are all specified. Two things remain: an agent profile naming which optional Features an agent may rely on, and a semantic layer above the wire format carrying intent, uncertainty and safety envelopes - which SiLA 2 was never intended to provide.

What is missing between SiLA 2 and MCP?

Meaning. SiLA 2 describes what the instrument does, in types and identifiers - and does it well. An agent needs to know what a scientist wants, with the safety envelope attached. That translation layer - intent-level tools over a validated instrument contract - is what has to be built in between, and our own measurements show it is where agent reliability is won or lost.

Can an AI agent really close the experimental loop today?

On a single instrument with a complete contract, yes - the mechanism exists and a novel client class has already consumed an unchanged instrument contract in production. What is not solved is long-horizon reliability across many steps, which is an engineering problem in the layer above the instrument - the agent-to-instrument edge - not a missing standard.

---

We build that layer. Our SiLA 2 and MCP generators are open source, and we have driven the loop end to end on our own instrument. Point us at one instrument and one workflow, and we will tell you exactly which of the ten obligations it already meets, which it does not, and what it would take to close the loop on it. Get in touch.