The integration problem in self-driving labs is invisible until you're inside it. I've worked with labs that tried three different paths to close the gap between their HTS throughput and what Bayesian optimization can actually deliver. The first group bought into a platform — Radical AI, Emerald Cloud Lab, Atinary — and found that closing the gap meant moving their optimization logic and synthesis data onto someone else's stack. The second group decided to build from scratch and absorbed years of engineering before anything ran. The third group — the one I keep working with — had excellent instruments, a domain expert who'd read every relevant paper, and no clear path to a closed-loop system they actually owned.
The Autonomous Lab AI architecture we built is for that third group. But the reason they don't have good options isn't what most people assume. It's not that the algorithms are immature. It's that the integration problem is invisible until you're inside it — and by then you're committed.
The LIMS CSV That Had No Failed Rows
The moment that most shaped how I think about autonomous lab compliance was a spreadsheet.
I was reviewing a LIMS export from a mid-size pharma lab — a liquid handler campaign that had run overnight. I looked through the exported rows and asked the lab manager what their synthesis success rate was. She said roughly 70-75%. I counted again. No aborted experiments. No partial runs. No status codes for the events the orchestration software had silently swallowed.
The compliance exposure wasn't that failed experiments produced bad data. It was that failed experiments produced no data at all — and ALCOA+ requires every automated lab action to be attributable, contemporaneous, and traceable, including the aborts. CDER warning letters jumped 50% in FY2025, with data integrity issues accounting for more than 30% of citations. The warning letters to Tyche Industries and Jagsonpal Pharmaceuticals in February 2025 were not about the chemistry. They were about records that looked complete and weren't.
Most SDL orchestration software drops abort events because the platforms were designed by teams optimizing for the happy path. Writing the ALCOA+-compliant audit thread — the one that captures failed experiments as a first-class data type, links them to the reagent lot, the instrument state, and the run timestamp — is custom engineering every time. The FDA and EMA's joint 10 Guiding Principles for Good AI Practice in Drug Development, published in January 2026, formalizes what those warning letters had been signaling for years: lifecycle management, data governance, full documentation. None of it is aspirational at this point.
The Conversation About SVGP That Changed How I Scope Projects
I had a conversation early in one of our engagements with a computational chemist that changed how I qualify scope.
He'd spent months benchmarking Gaussian Process kernels against his alloy composition search. The search space had 60+ parameters — cation ratios, anion combinations, stoichiometry ranges. He'd read the right papers. He knew that standard GP-based BO degrades past roughly 50 dimensions, that Sparse Variational GP approximations (SVGP) or deep kernel learning were the correct approaches. He'd run the benchmarks to confirm which fit his correlation structure.
Then he went to configure the platform his lab had licensed. The UI had a kernel selection dropdown. It did not expose the SVGP settings. He'd been running vanilla BO on a dimensionality problem it was designed to choke on, and the platform's performance graphs looked plausible throughout.
That's why I now ask about dimensionality and kernel validation before anything else. When we build the BO engine, the configuration lives in code the lab owns and can inspect. Cost-Informed Bayesian Optimization (CIBO) — which incorporates per-experiment synthesis cost into the acquisition function and deprioritizes expensive compositions until high-information regions are identified — cuts reagent spend by up to 90% (ChemRxiv, 2024). That reduction requires correct configuration. When the optimizer is behind a black-box UI, there's no reliable way to know if it's running what the paper describes.
SiLA 2 Ends at Nominal. The Error Dictionary Is Yours to Write.
My clearest realization about instrument integration came mid-way through our first SiLA 2 project — a Hamilton VENUS liquid handler and a Tecan Fluent in the same synthesis campaign.
I'd read the SiLA 2 spec carefully before starting. It's well-designed for the nominal case: structured device definitions, standardized command sets, a clean RPC framework. I expected the instrument layer to be the straightforward part.
What the standard doesn't define is exception handling. A Hamilton VENUS encountering a low-reagent warning mid-synthesis completes its current command and returns a status code. What the orchestration layer does next — whether the campaign pauses, whether the experiment gets flagged for training-set exclusion, whether the abort gets logged in the ALCOA+ thread, whether retry logic re-initializes the reagent tracking — is none of those things. That's custom logic, written per instrument, per protocol, per error code.
The SiLA 2 spec defines the conversation. It does not define what to do when the conversation fails. Every instrument has its own error dialect, and the fault-recovery dictionary has to be written by hand.
A lab running Hamilton, Tecan, and Agilent FAST equipment in the same campaign is running three error dialects against one orchestration layer. Each needs its own retry logic, its own definition of "this experiment failed cleanly and the training data is valid" versus "the run aborted uncleanly and should be excluded." The engineering starts exactly where the spec ends — and nobody I've met learned that before they were inside their first integration.
The Benchmark Number That Changes the Conversation
The performance figure I reach for most often in early client conversations is Berkeley A-Lab's 71% synthesis success rate.
A-Lab synthesized 41 novel materials in 17 days, with autonomous recipe correction running throughout. 71% is an extraordinary autonomous-lab benchmark. It's also a number that usually surprises people: even the most capable published autonomous lab system, running on purpose-built hardware with full optimization-to-synthesis integration, fails about 29% of the time. NC State's flow-driven SDL technique collected 10x more data than previous techniques at record speed (Nature Chemical Engineering, July 2025). The Matbench Discovery benchmark's best model achieved a 6.1x discovery acceleration factor.
Those numbers are real and achievable. What they require is that failed experiments be captured and learned from, not discarded. The 29% failure rate at A-Lab is data. In a legacy instrument environment with a GxP requirement, where abort events are being silently dropped, the same 29% is a compliance liability that compounds over every campaign.
Radical AI's Brooklyn Navy Yard facility runs 25+ alloys per day, 100 experiments per day, backed by $55M from RTX Ventures and NVIDIA NVentures and then a $60M Series A. Emerald Cloud Lab brings 200+ instruments at Carnegie Mellon. Those performance envelopes are achievable because the optimization logic runs on purpose-built, owned infrastructure. You can't replicate them by licensing a platform onto equipment the platform wasn't designed around.
When the Optimization Logic Is Code You Own
When we designed the architecture — documented at Autonomous Lab AI: Self-Driving Laboratory Design for Materials Discovery — the constraint I started with was that the optimization engine belongs to the lab.
The GNN surrogate model, pre-trained on DFT-calculated structures from the Materials Project and fine-tuned to your material family, predicts composition properties in milliseconds once the cold-start threshold is reached — typically 500 to 1,000 high-quality structures. The Bayesian optimization engine, with the kernel and CIBO cost-weighting configured for your dimensionality and synthesis economics, runs on infrastructure you control. The SiLA 2 integration layer includes the fault-recovery logic and the ALCOA+-compliant audit thread: aborts captured, attributable, timestamped.
The goal of 80-120 targeted experiments to cover the top 0.1% of a composition space — instead of the hundreds or thousands that intuition-led screening requires — is achievable when the optimization logic actually runs the way the published papers describe it, on your instruments, with failure data treated as data.
The question I keep coming back to when I meet a new lab: when your platform returns an experiment result, do you know what the optimizer decided to do with it? If the answer is "I assume it's doing what the documentation says," that's worth examining before the next campaign.