A lab an AI can actually read: HEROS, atomiq and AtomiqAI #
Language models are good at reasoning across scattered information. Most labs are made of scattered information. AtomiqAI connects the two.
The problem is not the model #
Walk into most labs and ask how the equipment is reached. You will hear about vendor GUIs, ad-hoc Python scripts, a LabVIEW VI someone wrote years ago, a shell script on one particular PC. The realtime sequence lives in one code base, the slow equipment in another, the data in a third. How any of it fits together exists only in people’s heads and in the lab book.
That fragmentation is usually described as an inconvenience for physicists. It is also the reason an AI assistant cannot help you: there is nothing to connect it to.
Why HEROS is the right foundation #
HEROS was not designed with language models in mind. Still, three of its properties turn out to be exactly what a model needs.
- One access point. Every instrument and service, whether a laser, an ADC, a camera, a vacuum pump, the archiver or the experiment scheduler, is a HERO on a single network and is reached the same way, regardless of vendor or protocol.
- Self-description. A HERO publishes what it is and what it can do: attributes with types and access rights, method signatures with parameter types and defaults, events. Nothing has to be written down for a client to use it. The information a Python proxy builds itself from is available to anything else.
- Vendor-agnostic interfaces. A HERO declares which interfaces it implements, so “every shutter” or “every RF source” is a well-posed question, independent of make and model.
atomiq adds the realtime half. Its component configuration is an explicit graph of how the setup is wired, and its experiment sequences are classes with declared components, blocks and arguments. The archiver adds the third: every shot of every run, keyed by run ID.
The joins between these parts already exist. A configuration entry names a live HERO. A HERO’s tag names the service that started it. A record’s run ID is the scheduler’s ID and the key to a lab-book entry. What was missing was something able to follow them.
AtomiqAI: one server that knows nothing about your lab #
AtomiqAI builds on a Model Context Protocol server that exposes this stack to a language model through a single interface. Its tools, about two dozen, are grouped by the question they answer rather than by subsystem: find and describe instruments; read, write and call them; wait for events and sample the monitoring stream; read the atomiq configuration and follow a component down to the hardware; list, describe and submit experiments; follow a run live and fetch its archived data; search the project documentation.
Two design decisions follow directly from self-description.
- The server is lab-agnostic. It contains no instrument names, no units, no capabilities. Everything it tells a model is read at runtime from the same endpoints a HERO already offers. A different HEROS lab gets the same server and a different answer.
- The atomiq repository is parsed, never imported. Importing would need ARTIQ, a device database and sometimes the hardware, and it would execute repository code. Everything a model needs is static.
It can run in read-only mode, and a deny list keeps selected devices out of reach entirely.
What it adds: reasoning across the whole lab #
The value is not a chat window for instruments. It is a system that can traverse configuration, live state, realtime control (it can submit and follow experiments), archived data and the lab book at once. These examples come from our running beta-tester neutral-atom tweezer lab: Rb-87, about 60 HEROs, over a hundred atomiq components and a few dozen experiments.
It debugs your failed run. The faults that cost a lab time are rarely exotic: a renamed component, a reference to something never defined. When a user’s MOT-search experiment died, we asked our local model, a 27-billion-parameter open-weights model on one workstation GPU, only: “The last MOT search experiment did not work. What is the problem and how can I fix it?” In about two minutes it read the scheduler’s log, found the KeyError in the prepare stage, compared the experiment’s source with the configuration, and saw that the camera the experiment lists had been renamed. It noticed that every camera call in that experiment is commented out, so the fix is deleting one line, and warned that the neighbouring imaging experiment would fail the same way. The same static check finds such dangling references before anything runs: it flagged three RF-source references defined nowhere, and separated them from two dozen false alarms that were really parameters bound later.
It tells you the state of the lab. Asked only “What’s the status of the lab?”, the local model read the live monitoring stream and the scheduler and answered in under three minutes: 64 HEROs up, lasers emitting, vacuum and cooling fine, scheduler idle. It used the lab notes to know which sensors watch the MOT coils, and from cold coils but light on the MOT photodiodes concluded that the laser table is up and the MOT is not running. It flagged the one non-ok reading as probably a misconfigured bound, and said where it was only inferring.
It runs experiments. Existing atomiq experiments can be listed, described, submitted and followed, and their data fetched from the archiver, all through the same interface.
It traces every answer. A reading can arrive with its unit, timestamp, calibration, the bounds it is judged against and the lab-book entry that qualifies it. One photodiode read 0.1 mW while its twin read 13.6 mW, an apparently dark arm; a lab-book entry written months earlier explained that these diodes sit behind a polarising beam splitter on the opposite arm and only indicate deviations. Instrument, configuration and a human note were all needed, and the system reached all three. Given one lab-book entry, a model also mapped 31 archived runs to the scans it describes, found each optimum with an uncertainty, and compared them with the team’s settings, citing the archive record behind every number. Every claim can be checked mechanically, and when one interpretation turned out to be wrong, the citations are what let us see why.
It knows what your lab knows. No HERO knows which way a beam points. AtomiqAI keeps such knowledge in domain modules: geometry for our lab (beams, windows, coils, checked against the live network), their own for other platforms, e.g. a cryostat for superconducting qubits.
Cloud or local: your choice #
AtomiqAI works with cloud models and with models running on your own hardware. We have used Claude, and an agentic-task optimized open-weights 27-billion-parameter model on a single workstation GPU. A local model keeps instrument control and unpublished data inside the lab network with no cloud dependency, which is the deciding factor for some groups.
One piece of deployment advice came out of this. Compact tool output is key with local models: values shared by all records are reported once, large arrays stay out of band as references. Designing a server also for a small model’s limited context is a different job from wrapping an API.
Where this is going #
Two directions follow from this, and both are work in progress, not demonstrations.
From schedules to goals. Today, a person who leaves the lab in the evening schedules a measurement and finds a failed run in the morning. We are strengthening AtomiqAI’s autonomous running of experiments so that the model can close the loop: schedule a run, notice from the logs that it failed, read the sensors and the configuration to find the cause, fix it and rerun, analyse the result from the archiver, and write the analysis into the lab book. The diagnosis is what our local model already does today (see above); the rest is what we are building. The user formulates a goal, and the model takes over. Unattended operation raises the stakes on the limits above, so hard limits that a model cannot talk its way past are part of this work, not an afterthought.
From local knowledge to the literature. Once a lab’s components, existing sequences and domain knowledge are all legible to the model, it starts to grasp the experimental capabilities enabled by the machine and a new kind of request becomes possible: “Here is a recent paper from a group with a similar apparatus. What in it can we build on with our setup?” Relating a published idea to this lab’s beams, components and blocks is a reasoning task over things the model can read.
The point #
In a world with capable AI, the limiting factor for using it on a complex machine is not the model. It is whether the machine can be read.
Instruments that describe themselves, reached through one uniform interface, make a lab legible. Legible machines can be reasoned about, debugged, documented and, step by step, operated. Nothing about this is specific to a tweezer experiment: any complex, heterogeneous machine built from many vendors’ parts faces the same fragmentation, and gains the same thing once it can be traversed.
We think this is where experiments are heading: not a chat box bolted onto old tooling, but machines that describe themselves, and AI that can follow the joins between configuration, live state, data and human notes.
If you already run HEROS and want to try it on your lab, get in touch. If you do not, the first step is the same one we took: make your instruments describe themselves via HEROS and atomiq.